Mobile Login Requests (Push Notifications) registration method for multi-factor authentication
Updated December 17, 2019
Use this guide to configure and enroll the SecureAuth Authenticate app on mobile devices to use Push Notifications as a multi-factor authentication registration method.
SecureAuth IdP supports four types of Push options for multi-factor authentication: Push Notification (alert), Push-to-Accept, Symbol-to-Accept, and Biometric.
The Push Notification alert message is sent directly to the app on a mobile device and includes a one-time passcode (OTP) to use during the multi-factor authentication workflow.
Push-to-Accept and Symbol-to-Accept send a login request to the app on a mobile device that prompts the end user to Accept or Deny access.
Biometric sends a login request to the app on a mobile device that prompts the end user to authenticate with a fingerprint or their face (iOS only) by using their mobile device.
To use any of these Push options, the Push Notifications functionality must be enabled in all realms designated to offer the option, and end users must enroll the Authenticate app on mobile devices to receive notifications before using the multi-factor authentication registration method during login.
When end user Push Notification requests are submitted, SecureAuth IdP builds a tunnel using Apple APN and Google GCM services to distribute custom messages to the app enrolled on mobile devices.
The following image depicts the Push-to-Accept architecture.
 |
Prerequisites
Download the SecureAuth IdP Mobile OTP App from the Google Play Store or Apple App Store.
Android: https://play.google.com/store/apps/details?id=secureauth.android.token
iOS: https://itunes.apple.com/us/app/secureauth-otp/id615536686
See SecureAuth compatibility guide for a list of supported, compatible mobile devices
Configure the SecureAuth App Enrollment Realm where end users can enroll the app on their device for Push Notification.
Create a new realm or access existing realms on the SecureAuth IdP Web Admin where the Push Notification will be applied. (Realm A in the SecureAuth IdP Configuration Steps.)
Optional: Create a new realm or access an existing realm on the SecureAuth IdP Web Admin that is configured for the Account Management page (help desk) to let an administrator revoke the usage of a device on which the app was enrolled for Push Notifications (Realm B in the SecureAuth IdP Configuration Steps)
Optional: Create a new realm or access an existing realm on the SecureAuth IdP Web Admin that is configured for the Self-service Account Update (end-user self service) to enable end users to self-revoke their device on which the app was enrolled for Push Notifications (Realm C in the SecureAuth IdP Configuration Steps)
Configure the following tabs on the Web Admin before configuring Push Notifications (and Account Management Page and Self-service Account Update):
Overview – Define the description of the realm and SMTP connections.
Data – Integrate an enterprise directory with SecureAuth IdP.
Workflow – Define how users will access the target.
Multi-Factor Methods – Define the multi-factor authentication methods that will be used to access the target, if any.
Post Authentication – Define the target resource or post authentication action. See "Realm B configuration steps" and "Realm C configuration steps" below for specific post-authentication configurations for the Account Management Page and Self-service Account Update.
Logs – Define the logs that will be enabled or disabled for this realm.
SecureAuth IdP configuration steps
Realm A configuration steps
Important
These steps are for LDAP data stores only, including Active Directory (AD) and others.
If using a different directory (e.g., SQL), the Property must be configured as a stored procedure in the data store.
Note
SQL, ASP.net, and Oracle data stores support only the Plain Binary Data Format, which are configured in the Data tab. Push is not supported for Open Database Connectivity (ODBC) data stores.
Open the Data tab.
In the Profile Fields section, map a directory field to the Push Notification Tokens Property.
In typical AD deployments, the Data Format is Plain Binary and the jpegPhoto directory field is used.
Select the Writable check box.
Push Notification Tokens
This property can be stored as plain binary or in JSON format. The tokens have distinct requirements for the LDAP directory attribute mapped to the Property based on the Data Format selection.
For plain binary, map this property to a directory field that contains the Push Notification Token and meets the following requirements:
Length: 4096 minimum
Data Type: Octet string (bytes)
Multi-valued
For JSON, map this property to a directory field that contains the Push Notification Token and meets the following requirements:
Length: 4096 minimum
Data Type: DirectoryString
Multi-valued
Save your changes.
Open the Multi-Factor Methods tab.
In the Registration Configuration section, under Mobile Login Requests (Push Notifications), select Passcode (OTP), Accept / Deny, Passcode (OTP) + Accept / Deny, Biometric, Accept / Deny + Biometric, Passcode (OTP) + Accept / Deny + Biometric from the Request Type dropdown.
Passcode (OTP)
Enable Push Notifications to enrolled apps on mobile devices to authenticate with the one-time passcode
Accept / Deny
Enable Push-to-Accept / Symbol-to-Accept requests to enrolled apps on mobile devices
Passcode (OTP) + Accept / Deny
Enable Push Notifications and Push-to-Accept / Symbol-to-Accept requests to enrolled apps on mobile devices (both options are displayed on client-side login page)
Biometric
Enable Push Notifications to enrolled apps on mobile devices to authenticate with fingerprint or face (iOS only)
Passcode (OTP) + Biometric
Enable Push Notifications to authenticate with the one-time passcode, and Push-to-Accept requests to enrolled apps on mobile devices to submit fingerprint or face (iOS only)
Accept/Deny + Biometric
Enable Push Notifications to authenticate with the one-time passcode, and Push-to-Accept requests to enrolled apps on mobile devices to submit fingerprint or face (iOS only)
Passcode (OTP) + Accept/Deny + Biometric
Enable Push Notifications to authenticate with the one-time passcode, and Push-to-Accept requests to enrolled apps on mobile devices to submit fingerprint or face (iOS only)
If Accept / Deny or Passcode (OTP) + Accept / Deny or Accept/Deny + Biometric is selected in step 3, then complete the following steps.
a. Select the Accept Method for end users to use when the login request notification is displayed. The end user taps the "Accept" button or taps the displayed symbol.
b. Set the Login Request Timeout to determine the number of minutes end users have to accept Push-to-Accept, Symbol-to-Accept, or Biometric requests.
c. Set the Company Name, which appears on the Push-to-Accept, Symbol-to-Accept, or Biometric request.
d. Set the Application Name to a descriptive name or phrase, which appears on the Push-to-Accept, Symbol-to-Accept, or Biometric request.
Set the Device Max Count to -1 if there is no limit to the number of devices that can have the app enrolled for Push Notifications.
To establish a limit, set the maximum number of devices with the app enrolled for Push Notifications.
If a max count is set, select Allow to replace from the When exceeding max count dropdown if end users can replace existing devices with the enrolled app with newer devices.
If a max count is set and Allow to replace is selected in step 6, select Created Time from the Replace in order by dropdown to replace the oldest device with the enrolled app with the newest one.
Select Last Access Time to replace the least recently used device with the enrolled app with the newest one
Click Save.
Realm B configuration steps
Note
The following are optional configuration steps. Use them to enable administrator (help desk) to revoke devices on which the app is enrolled for Push Notifications.
This realm must be set up for the Account Management page post authentication action.
Refer to Account Management (Help Desk) Page Configuration Guide for more information.
Follow steps 1 and 2 in the Data tab section for Realm A.
Important
The directory attribute used for Push Notification Tokens (e.g., jpegPhoto) must be the same across all SecureAuth IdP realms using Push Notifications / Push-to-Accept or Symbol-to-Accept, or Biometric Login Requests to ensure consistency.
In the Post Authentication section, select Account Management from the Authenticated User Redirect dropdown.
Click Save to avoid losing changes.
In the Identity Management section, click Configure help desk page to enable or disable help desk functions.
In the Help Desk section, select Show Enabled from the Push Notification Devices dropdown to show this function on the help desk page and enable administrative revocation of devices with the app enrolled for Push Notifications.
Click Save.
Realm C configuration steps
Note
These are optional configuration steps to enable end-user self-service revocation of devices that have the app enrolled for Push Notifications.
This realm must be set up for the Self-service Account Update post-authentication action.
See Self-service Account Update page configuration for more information.
Follow steps 1 and 2 in the Data tab section for Realm A.
Important
The directory attribute used for Push Notification Tokens (e.g., jpegPhoto) must be the same across all SecureAuth IdP realms using Push Notifications, Push-to-Accept, Symbol-to-Accept, or Biometric Login Requests to ensure consistency.
In the Post Authentication section, select Self Service Account Update from the Authenticated User Redirect dropdown.
Click Save to avoid losing changes.
In the Identity Management section, click Configure self service page to enable or disable self-service functions.
In the Help Desk section, select Show Enabled from the Push Notification Devices dropdown to show this function on the help desk page and enable self-revocation of devices on which the app is enrolled for Push Notifications.
Click Save.
End user experience
End users must enroll the SecureAuth Authenticate app on their mobile devices in the Multi-Factor App Enrollment Realm to use Push Notification, Push-to-Accept, Symbol-to-Accept, or Biometric as multi-factor authentication methods.
iOS end users who start the SecureAuth Authenticate app for the first time will see the Allow notifications screen and must allow the app to send notifications. See Login Requests from Push Notifications for details.
When the end user sees the page of multi-factor authentication methods to choose from, the multi-factor authentication method that was last selected and successfully used to log in remains the default method for the next login for each device or browser.
Passcode (OTP) Request Type (Push notification)
When logging on a SecureAuth IdP realm where the Passcode (OTP) Push Notification login request type is enabled, the Push Notification choice appears in the multi-factor authentication methods list.
Select Send passcode and click Submit.
A passcode Push Notification is delivered to the app on the enrolled device, and is displayed on the home screen with the OTP, as shown in the following image:
Accept / Deny Request Type (Push-to-Accept)
When logging on a SecureAuth IdP realm where the Accept / Deny Push Notification login request type is enabled, the Push-to-Accept choice is displayed in the multi-factor authentication methods list.
Select Send login request and click Submit.
A Push-to-Accept request is delivered to the enrolled app on the device, ready for the end user's approval or denial response on the app.
If the end user does not respond to the request within the configured time period, the following message is displayed:
"The request has expired" message appears on the app.
"The login request is no longer valid" message appears on the realm page along with the link "Please click here to use an alternate verification method."
The notification is sent to the Authenticate app and end users can respond as follows:
If the Authenticate app is closed, swipe down on the login request notification. Tap Accept to receive notifications that allow end users to securely authenticate.
If the Authenticate app is open, tap Accept or Approve to receive notifications that allow end users to securely authenticate.
 |
Accept / Deny Request Type (Symbol-to-Accept)
When logging on a SecureAuth IdP realm where the Accept / Deny Push Notification login request type is enabled, the Symbol-to-Accept choice is displayed in the multi-factor authentication methods list.
Select Send login request and click Submit.
A symbol is displayed on the next page, and the login request is simultaneously delivered to the enrolled app on the mobile device, ready for the end user's approval or denial response on the app.
If the end user does not respond to the request within the configured time period, the following message is displayed:
"The request has expired" message appears on the app.
"The login request is no longer valid" message appears on the realm page along with the link "Please click here to use an alternate verification method."
Tap the matching symbol to securely authenticate.
Accept / Deny Request Type (Biometric)
Biometric authentication is available in the SecureAuth® Identity Platform version 19.07 and later.
When logging on a SecureAuth IdP realm where the Accept / Deny Push Notification login request type is enabled, the fingerprint or face (iOS only) choice is displayed in the multi-factor authentication methods list.
Select Use fingerprint recognition and click Submit.
A login request is delivered to the enrolled app on the mobile device. Tap the request to view the Authenticate app. In the app, tap Use Touch ID(iOS) or Use Fingerprint (Android).
If you have paired an Apple Watch to your mobile device, you will receive a Biometric Request on the watch. Click OK.
The following message is displayed on the computer until the end user authenticates:
If the end user does not respond to the request within the configured time period, the following message is displayed:
"The request has expired" message appears on the app.
"The login request is no longer valid" message appears on the realm page along with the link "Please click here to use an alternate verification method."
End user enters a valid fingerprint on the mobile device to securely authenticate.