Authentication
The Authentication module is the control panel for all of the authentication policies available within RapidIdentity. Authentication Policies empower administrators to govern the manner in which users gain access. In most cases, users are required to enter a username and password, however, some organizations may require additional input to gain access.
Multi-Factor Authentication (MFA) is the process by which an organization or system can require login input(s) specific to an individual in addition to or instead of a username and password; MFA focuses on access control. During eras prior to computers, MFA included, amongst other measures, "the secret handshake", answering a riddle known only to indoctrinated members, or perhaps a practical demonstration of an organization-specific skill or knowledge base. The benefits of using MFA include ease of use and adding an extra layer of security at a negligible cost to the organization; in some cases, MFA does not cost the organization anything!
Today, however, the most common MFA context is computer access control. This may include, but does not necessarily require, a separate device with an application installed to generate an access code. For example, in order to log into a specific work-related application or to gain restricted access area entry, the organization may require the individual to answer a challenge question or provide biometric data (e.g. fingerprint, iris scan). MFA is a diverse subject and to discuss each MFA "type" is beyond the scope of the RapidIdentity Administrator's Guide.
RapidIdentity makes it possible for administrators to prioritize authentication policies, assign and configure authentication criteria, and also prioritize, assign, and configure authentication methods. The many degrees of freedom allow administrators nearly infinite options to create policies for all users and groups within an organization, regardless of LDAP grouping, time zone location or network subnet.
The following information details how authentication methods can be leveraged in RapidIdentity Authentication Policies.
Authentication Policies
Authentication policies allow administrators to determine how users and user groups authenticate to RapidIdentity. An authentication policy can include criteria to include or exclude users or user groups and methods to require users and user groups to cohere with organization multi-factor authentication standards.
 |
There are three configuration interfaces for Authentication Policies:
General
Create new policies by clicking the plus icon and remove existing policies by clicking the minus icon. Policies can be prioritized using the up and down arrows and copied. The General tab captures initial configuration options for this policy, as defined below.
 |
Field | Description | |
|---|---|---|
Enabled | Once the configuration options have been determined, click this checkbox to enable the policy. A Policy cannot be saved in the Enabled state until at least one of its Authentication Methods has been Enabled as well. | |
Is a Forgot Password Policy? | Enable this to allow the particular policy to be used during the Forgot Password? workflow. This will disable the below authentication methods for that workflow. NoteOnce enabled, the Social, Federation, Kerberos, QR Code, or Password Authentication Methods are then disabled and will no longer be available in the list of authentication methods for that policy because they are not valid for this feature. | |
Name | Name the policy. The policy cannot be saved until it has been named. | |
Description | Enter an optional description for this policy. | |
Always Fail | Clicking this checkbox will ensure that any user who matches this authentication policy will never be able to authenticate successfully. This could be used, for example, in conjunction with the Time of Day or Source Network criteria to disallow authentication on weekends or when someone is coming from outside a trusted network. | |
Insecure QR ID Scans Enabled | When this checkbox is selected, users matching this policy can enter a QR code instead of their username. If the authenticating user's policy requires QR authentication, a valid secure QR code will suffice for the credential and the user will not be prompted for that method later. Insecure QR Codes only provide a username, and the user will then be required to authenticate using another method. RapidIdentity Portal users able to generate QR Codes can determine whether the printed QR Code is secure or insecure. Ultimately, an insecure QR code may only be used for identification purposes, but a secure QR code may be used for identification as well as an authentication credential. NoteIf at least one enabled authentication policy allows insecure QR Code scans or at least one enabled authentication policy requires QR authentication, the "Scan QR Code" will show up on the initial login page. If the user is on a device that does not support QR scanning (e.g. a desktop computer with no camera), the button will be present but disabled.
|
Click Save. New policies will be assigned a fixed, unique ID that will be visible next time the policy is viewed.
Criteria
The Criteria subtab allows administrators to determine when the policy should be presented to a particular user. There are seven types of criteria available for directing this decision.
Note
All enabled criteria for a particular policy must evaluate true for that policy to match an authenticating user. Otherwise, the policy will be rendered inactive for that user.
Criteria | Description | |
|---|---|---|
LDAP Filter | The LDAP Filter criteria evaluates to The Match the Built-in Admin Account checkbox provides the option to evaluate the Backup Administrator account to true, even though it is not an LDAP object. This provides the ability to access the server even when the Administrator is locked out.
| |
Day of Week | The Day of Week criteria evaluates to
| |
Time of Day | The Time of Day criteria evaluates to
| |
Source Network | Whitelist means that the criteria will only evaluate to Checking the Enable HTTP Header Processing box will match the X-Forwarded For HTTP header used by proxies and load balancers.
| |
Kerberos | Administrators can allow users to authenticate with a Kerberos-enabled browser. The Kerberos criteria only evaluates to
| |
QR Code | The QR Code criteria only evaluates to
| |
FIDO | The FIDO criteria only evaluates to
|
Authentication Methods
Users assigned to an Authentication Policy must successfully authenticate using ALL of the Authentication Methods defined in the policy. Administrators can drag each authentication method to specify the user's order with each method.
 |
There are 13 authentication methods described below. Use the links for more detailed information on each method.
Authentication Method | Description |
|---|---|
Users authenticate with a preconfigured Duo account. | |
Users authenticate through a RapidIdentity email address | |
The Federation Authentication Method causes RapidIdentity Federation to act as a SAML Relying Party to a remote instance of RapidIdentity Federation. The remote system's account must be uniquely mapped to a local RapidIdentity account by one or more attributes released by the remote IdP, such as email. | |
When enabled, users authenticate with a licensed FIDO U2F security key. Administrators can allow users to defer the FIDO challenge for 30 days. If a user defers this setting, they will not be prompted for FIDO authentication again for 30 days when using the same browser. | |
Users authenticate with licensed, browser-provided Kerberos tickets automatically. | |
Users authenticate with their directory password. | |
Users can authenticate against the default image pool of 36 images or a custom image pool. Administrators can configure the number of images to choose and the number of images to challenge the user. This is a licensed method. When configuring the custom image pool, click Manage Images. The total image pool resides on the left pane, and the user challenge images reside on the right pane. Administrators can select an image and use the arrows to move images. The Pictograph Image Manager supports drag-and-drop. | |
Users authenticate using the RapidIdentity mobile client application. It is necessary to be licensed for the PingMe authentication method to use this authentication method and necessary to configure users on the RapidIdentity Server. Native PingMe: Enable this to use RapidIdentity's built-in PingMe settings, and the rest of the fields will disappear. Leave this unchecked to set up settings for a separate MFA server below.  Server Hostname: The RapidIdentity Server hostname. Server Port: The server port. The default value is 443 if left blank. API Key: The RapidIdentity Server API key. Username attribute: The LDAP attribute that contains the user's RapidIdentity Server username(s). Domain: Optional. If left blank, the default value is the RapidIdentity Server authentication domain if the username attribute value does not contain one. | |
Users authenticate with their RapidIdentity Portal Challenge Questions. | |
When enabled, a valid, secure QR code must be scanned. This is a licensed method. | |
Users authenticate with a code sent to their mobile device through SMS. This is a licensed method. | |
Social authentication allows users to authenticate to RapidIdentity through Facebook, Google+, LinkedIn, or Twitter accounts. Authenticating against any of the enabled social networks is sufficient. This is a licensed method. Social authentication is enabled by clicking the Enabled box, selecting the desired social network, and completing the ID and Secret fields. The ID and Secret field values are both obtained through each of the social network's developers' pages. | |
Users enter a Time-Based One-Time Password (TOTP) code generated by a device or app (e.g. Google Authenticator). Window Size: governs the number of valid codes. A value of 1 indicates only the current code is valid. A value of 3 indicates the current, the two previous, and two future codes are all valid. Issuer: The name displayed alongside the token in the user's device. If blank, the default Issuer will be used. Allow Challenge Deferral: When checked, users can defer challenges for 30 days, meaning they will not be prompted for TOTP authentication when authenticating with the same browser within that time period. Setup Instructions: Necessary instructions for users to view when setting up their device. |
FIDO Authentication Policy
Note
FIDO U2F has been deprecated from Google Chrome as of February 2022. This has been replaced with Web Authn.
The FIDO Authentication Method requires a user to use a supported FIDO U2F authentication token. This is part of a broader FIDO Configuration effort. Administrators can allow users to defer challenges for up to 30 days.
 |
Password
The Password authentication method requires users to enter their password to authenticate.
The password requirements, along with password exclusions, are determined through the Password Policy Manager.
Default Method
When a new authentication policy is created, Password is the only method automatically enabled.
Thus, when multiple authentication policies exist in which more than one method and criteria apply, those policies should be prioritized higher than the authentication policy whose only requirement is Password as a method.
Pictograph
Pictograph as a RapidIdentity authentication method is best for contingent users and other low-risk users (e.g. guests, young students) relative to the global organizational user population.
Users are required to identify pictures. To set the policy up initially, administrators can select either the default image pool or a custom image pool.
Follow these steps to configure Pictograph as an authentication policy method.
Create a new authentication policy and populate the General and Criteria tabs as needed. On the Authentication Methods tab, choose Pictograph as an authentication method. To enable this method, click the box next to Enabled.
Choose whether to use the default image pool of icons or to sort through the default images to create a custom pool for users to choose from when creating their authentication combinations. To select a custom pool, deselect the checkbox next to Use the Default Image Pool (36 Images) and click the magnifying glass in the Custom Image Pool field that appears.
Choose the desired images from the Pictograph Image Manager that appears by clicking the small arrow in the bottom right corner of the icons from the choices in the left pane. To remove images, click the small arrow in the bottom right corner of the chosen icons in the right pane or click Clear All in the menu's action bar. When your library is complete, click Select.
Define the Number of Images to Choose as the number of images that the user will be required to select on initial setup. The default number is 3.
Define the Number of Images to Challenge as the number of images that will be displayed at once during the pictograph challenge at login. The only supported number is 9, required for the Windows Client to work properly.
Prioritize the authentication methods and click Save.
An example of the user pictograph authentication is shown below.
Pictograph Authentication
To authenticate with Pictograph, users are first required to select their image(s) based on the authentication policy configuration. In the example policy shown below, users are required to select three images to authenticate to RapidIdentity.
 |
Each time an image is chosen, the group of images will refresh and the chosen image will show beneath the next group. To see a new group of images without choosing one, click the refresh button 
at the top right of the image group.
 |
 |
After the third image has been chosen, all three will show on screen, along with a password prompt for initial login. Users are reminded to keep track of the images they chose, as they will need to use those images in order to log in.
 |
If users do not remember their pictograph picture(s), administrators can reset a user's pictograph image(s) in the Authentication Options tab by clicking Delete Pictograph Choices for a User.
During each subsequent login, the user will be required to choose their images out of the group of images as defined within the policy. If the user was required to choose three images, all three will have to be identified on as many screens.
 |
PingMe
PingMe authentication requires the RapidIdentity Mobile application.
Follow these steps to configure a policy so that users can authenticate with PingMe. This feature can be used for RapidIdentity setups (Native PingMe) as well as with a configured RapidIdentity MFA server.
Native PingMe
To set up the native PingMe feature for a RapidIdentity server, first navigate to Configuration > Policies > Authentication and create a new policy. Enable it in the General tab and go to the Authentication Methods tab.
In People > Delegations, ensure that the Actions Enroll Mobile Device, Update Mobile Device, and Delete Mobile Device have been added to this policy.
Each user impacted by this policy will need to register their Mobile Device. An SMTP server will need to be configured to deliver the email for registration, and an SMS Gateway will need to be set up if you want to deliver text messages for registration.
Note
To enable email logging for Native PingMe, first Enable Email Branding in the Appearance menu, then Set Primary Account on the mobile application.
Authentication for Native PingMe
Once the policy has been set up, the SMTP server has been configured to send emails, the SMS Gateway configured to send text, and the user has been added to the policy, the user will then need to enroll and authenticate their mobile device. There are two ways to initiate this process.
User selects Enroll Mobile Device from the Self-Service Interface.
Note
This method requires the proper configuration of an SMTP server to send email or SMS Gateway configuration to send texts. Users can register via hyperlink from their mobile device; the link will be sent via text and email as long as all configurations are valid.
RapidIdentity will then send an email to the user with hyperlinks to download the Mobile Application as well as a provisioning URL. Use this information to log in to the application for the first time from the mobile device and move to step 2f.
Note
The Authcode can be used instead of the user's password for the initial login. The information presented in this email is pulled from the Mobile Devices settings in Configuration > Policies, and the content of the email can be edited through Email Templates in Configuration > General > Email Templates.
RapidIdentity will also send a text message to the user with hyperlinks to download the Mobile Application as well as a provisioning URL. Use this information to log into the application for the first time from the mobile device and move to step 2f.
Note
The Authcode can be used instead of the user's password for the initial login. The information presented in this text is pulled from the Mobile Devices settings in Configuration > Policies, and the content of the text can be edited through Edit SMS Text Message on that menu.
Clicking either of these links from the mobile device will send the user directly to a pre-populated screen within the RapidIdentity app. To authenticate, the user enters either their password or the Authcode sent with the notification, and they will be verified on that device.
Users can also download and open the RapidIdentity app from the Google Play or Apple App Store and create an account manually. From the mobile device:
Click the + in the top right of the application's screen.
Click Add Manually.
On the next screen, click Add a Server Account.
Enter the Server URL of the RapidIdentity system the user will be authenticating into and click Submit.
Enter user credentials when requested, and create a 6-digit PIN for further security.
Once this has been completed, the user will now be able to receive a PingMe request from the RapidIdentity app on this mobile device to provide secondary authentication. Each approval will be accompanied by the entry of the user's PIN.
Note
If fingerprint recognition is enabled on an Apple device, that can be used in place of a PIN.
RapidIdentity with MFA Server
For systems where a specific server for Multi-Factor Authentication has been configured, the setup is slightly different. In this case, do not activate the Native PingMe option and simply complete each of the fields as presented with the information for that server. Prioritize methods and configure any additional criteria as needed.
 |
Authentication for MFA Server PingMe
After configuring any necessary criteria and prioritizing any additional methods, authenticate to RapidIdentity with your user credentials. If the authentication policy requires the user to use the PingMe method, then a 'pinging' screen displays to let users know that RapidIdentity and RapidIdentity Server are contacting the user's device on which the RapidIdentity Mobile app is installed.
 |
The RapidIdentity Mobile app posts a notification on the mobile device and when users access the app they will be able to deny the request or approve after entering their PIN.
Note
If fingerprint recognition is enabled on an Apple device, that can be used in place of a PIN.
 |
A successful approval subsequently directs users to the configured RapidIdentity landing module, or in the context of RapidIdentity MFA to the user's workstation or the RapidIdentity Server interface.
Portal Challenge
The Portal Challenge authentication method requires users to answer one or more of their challenge questions to authenticate.
To enable Portal Challenge questions as an authentication method, create a new policy, fill out the General and Criteria fields as needed, and enable Portal Challenge.
In the Portal Base URL field, enter the URL that RapidIdentity will be pulling the challenge questions from. Generally, this will be the same as the URL that the user is logging into with /portal appended.
 |
These challenge questions are the same ones the user set up during the Claim My Account process. Once this policy has been applied, the user will be prompted to answer at least 2 challenge questions before moving on to the landing page.
QR Code
QR Codes within RapidIdentity are best for contingent users (e.g. interns, contractors) and other low-risk users (e.g. guests, young students) relative to the global organizational user population.
RapidIdentity QR Codes can serve two purposes: an Authentication Policy Criterium or an Authentication Policy Method. Whether the QR Code should apply as a criterium or method depends on the specific Authentication Policy use case requirements relative to the overall organizational security and business policy.
Administrators can allow users to print their own QR Code, or allow other users to print user QR Codes, through the RapidIdentity Portal Profiles module. The option to allow QR Code printing is configured in the RapidIdentity Portal Configuration module, in the Profiles Delegation Definition Manager Action tab. The default QR Code width and height are 2.3125 and 3.5 inches, respectively.
A new, Secure QR code must be printed every time a user's password changes since the Secure QR Code is related to the user's password.
Administrators must install and ensure the RapidIdentity Connect password filter and ensure that both RapidIdentity Portal and RapidIdentity Federation are configured to be able to pull passwords from the directory service.
It is beyond the scope of the RapidIdentity Product Guides to address all possible Authentication Policy use cases with their requirements through the lens of security and business policy. The exploration and possible solution approaches to these use cases and their requirements occur during various stages in the context of how Identity Automation Professionals engage the Customer.
SMS
SMS messages can be used as an authentication method.
SMS messages can be sent with Amazon Web Services SNS using either Identity Automation or Customer credentials.
To leverage SMS messages, it is necessary to have a License including the RapidFederationSMSAuth module and, if you want to use Identity Automation credentials, the license must also include the SMSGateway module.
 |
If you have not yet defined a Mobile Number Attribute in Configuration > Systems > LDAP > User Settings, you will see this message and a link to configure this attribute before you can Enable this feature. RapidIdentity will also need global SMS configuration information populated in Configuration > Systems > SMS.
 |
Configure and enable an authentication policy with SMS as a method. Be sure the mobile phone number attribute is configured in the attributes tab and link that attribute to the SMS method.
Configuring the Phone Number
The SMS function requires the mobile number to be stored in the format <countrycode><areacode><number> and follows these basic rules:
If the mobile number starts with a
+, nothing will be added to it when dialing.If the mobile number does not start with a
+and the dialPrefix is defined, the dialPrefix will be prepended to the number before dialing.If the mobile number does not start with a
+and the dialPrefix is not defined, a+will be prepended to the number before dialing.All other non-numeric characters will be stripped per SMS requirements.
Example
Dial prefix: +1 Stored mobile number: +1-(123)-456-7890 Sent to mobile number: +11234567890 Dial prefix: +1 Stored mobile number: (123)-456-7890 Sent to mobile number: +11234567890 Dial prefix: +1 Stored mobile number: +44-(123)-456-7890 Sent to mobile number: +441234567890 No Dial prefix Stored mobile number: 1-(123)-456-7890 Error, not sent... missing '+'
Social
To allow users to authenticate to RapidIdentity through any of the supported social networks, administrators must access the corresponding social network's developer's page.
Administrators will need the organization's redirect URI, which, in most cases, will take the following format for Facebook, Google, and LInkedIn.
Note
The callback is formatted differently for Twitter.
https://<RF_HOST>:<RF_PORT>/idp/socialCallback?n=social_network
Once the process is complete, administrators can enable the social network authentication method and input the corresponding ID and Secret field values.
 |
The configuration sequences listed below for each social network are the simplest and most recommended setups possible that will return a viable social network authentication. Some of the social network methods allow for more configuration options beyond what is listed in the sequences below. Administrators developing authentication policies should use caution when selecting social network configuration options beyond what is listed below.
The social networks may update their development pages periodically, thus the screenshots listed below may vary slightly. If a discrepancy is observed, please contact Support and the documentation will be updated as soon as possible.
Follow these steps to configure Facebook social authentication:
Navigate to Facebook for Developers and, if necessary, create an account.
Follow the Facebook instructions to Create A New App. This will be a web app.
Note
Ensure the Organizational Site URL is always presented in the following format in the Domain Manager and in the Website details:
https://<RF_HOST>:<RF_PORT>Ensure the Valid Oath redirect URI for your organization is presented in the following format:
https://<RF_HOST>:<RF_PORT>/idp/socialCallback?n=facebookOnce the app is created, navigate to Settings > Basic to capture the App ID and App Secret.
Return to RapidIdentity.
Back in Configuration > Authentication Policies > [Authentication Policy] > Social > Facebook, Click the checkboxes next to Enabled and Enable Facebook. Enter the App ID and the App Secret from the Facebook developer's page in the fields that appear.
Ensure the LDAP filter and other Criteria are set and that the policy has an accurate name and is Enabled on the General tab. Click Save.
When the user logs in, they will be prompted to Login with Facebook.
The user will be taken to Facebook where they will enter their credentials. If successful, they will be returned back to RapidIdentity to finish the login process.
Follow these steps to configure Google social authentication:
Navigate to the Google Developers' site and, if necessary, create an account.
Note
This account needs to have the Google Super Admin Role within Google. This role is added in the Google Admin Console.
Follow the Google API directions to Create a project. This will be a web application.
Once the app is created, navigate to the Client ID for Web Application page to capture the Client ID and Client Secret. Also, note the Authorized Redirect URIs. This must be entered as
https://[Host Name]/idp/socialCallback?n=googleplus.
Click the checkbox next to Enable Google. Copy and paste the Client ID and the Client Secret into Configuration > Authentication Policies > [Authentication Policy] > Authentication Methods > Social. Click the checkbox next to Enabled to enable the policy.
Ensure the LDAP filter and other Criteria are set and that the policy has an accurate name and is Enabled on the General tab. Click Save.
When the user logs in, they will be prompted to log in with their Google credentials.
The user will be taken to Google, where they will enter their credentials. If successful, they will be returned back to RapidIdentity to finish the login process.
Follow these steps to configure LinkedIn social authentication:
Navigate to the LinkedIn Developers' page and, if necessary, create an account.
Follow the LinkedIn instructions to Create an app. This will be a web app.
Note
Ensure the Organizational Site URL is always presented in the following format:
https://<RF_HOST>:<RF_PORT>Ensure the Valid Oath redirect URI for your organization is presented in the following format:
https://<RF_HOST>:RF_PORT>/idp/socialCallback?n=linkedinOnce the app is created, navigate to Authentication to capture the Client ID and Client Secret.
Back in RapidIdentity, navigate to Configuration > Authentication Policies > [Authentication Policy] > Social > LinkedIn.Enter the Client ID and the Client Secret from the Authentication developer's page in the fields that appear. Click the checkboxes next to Enable LinkedIn and Enabled.
Ensure the LDAP filter and other Criteria are set and that the policy has an accurate name and is Enabled on the General tab. Click Save.
When the user logs in, they will be prompted to Login with LinkedIn.
The user will be taken to LinkedIn where they will enter their credentials. If successful, they will be returned back to RapidIdentity to finish the login process.
Follow these steps to configure Twitter social authentication.
Navigate to the Twitter Developer page, and, if necessary, create an account.
Follow the Twitter instructions to Create An App. This will be a web app.
Note
Ensure the Organizational Site URL is always presented in the following format:
https://<RF_HOST>:<RF_PORT>Ensure the Valid Oath redirect URI for your organization is presented in the following format:
https://<RF_HOST>:<RF_PORT>/idp/socialCallback/twitterOnce the app is created, navigate to Keys and tokens to capture the Consumer API key and API secret key.
Click Keys and Access Tokens to access the Consumer Key and Consumer Secret.
Back in RapidIdentity, navigate to Configuration > Authentication Policies > [Authentication Policy] > Social > Twitter. Enter the Consumer ID and Consumer Secret from Methods fields. Click the checkboxes next to Enabled and Enable Twitter. Click Save.
Once the user tries to lock back in, they will be prompted to authenticate their Twitter account to their RapidIdentity account. After entering their username, the user will be prompted to use Twitter Authentication.
The first time the user logs in, they will be redirected to the Twitter authentication website to confirm their credentials. At this point, they need to enter their Twitter credentials into the authorization window to authorize RapidIdentity.
Once the user has signed into their Twitter account, they can return to RapidIdentity to continue logging in.
RapidIdentity will now allow login to complete.
Subsequent Logins
Note
Each time an existing user logs in using Twitter Social Media Authentication, they must be logged in to Twitter before they attempt to log in to RapidIdentity; otherwise, they will be sent through the Twitter authentication loop again.
TOTP
Time-based One-Time Password (TOTP) Authentication allows users to authenticate using a trusted third-party authentication factor that uses uniqueness from the current time to authenticate the user.
 |
Follow these steps to create an Authentication Policy using TOTP code integrating the RapidIdentity Mobile Application:
Access RapidIdentity and then select Configuration > Policies > Authentication > Authentication Policies.
Click New Authentication Policy.
Fill out the General and Criteria fields as needed, and enable TOTP.
Enter a Windows Size. This setting governs the number of previous and future codes that will be accepted. Valid values are in the range of 1-3 regarding the codes entered by the user:
Value of 1 means that only the current code is valid.
Value of 2 means the previous, current, and next codes are valid.
Value of 3 means the previous two, current, and next two codes will be considered valid.
Optionally, enter a label for the Issuer. If an associated user is prompted to set up a new TOTP key, this is the issuer name to use in the label on their device (Google Authenticator, etc.).
Allow Challenge Question Deferral enables administrators to allows users to "defer" or bypass the requirement to enter a login authentication code for up to 30 days, within the same browser. To enable deferment, check the box.
Finally, Set Up Instructions is any text visible to the user when the MFA setup screen appears. Administrators can customize this text to suit the organization's policies or culture by clicking the arrow icon.
When complete, click Save.
On subsequent visits, the TOTP code will be requested after the Username and Password are used to log in.
Federation Authentication Method
The Federation Authentication Method allows users to authenticate against a remote SAML 2.0 Identity Provider, including a separate instance of RapidIdentity Federation.
Two optional properties have been added to the Federation Authentication Method configuration.
postAuthRedirectUrl- An alternate URL to which the browser should be redirected after the Trusted Identity Provider returns control to RapidIdentity. This must be a valid HTTPS URL.exposeAttributes- Whether to expose attributes released by the Trusted Identity Provider. If enabled, the attributes will be included in the "complete" API response. This may only be useful if the authentication APIs are being used directly.
To configure the Federation Authentication method for the most common use case -- a RapidIdentity to RapidIdentity connection -- it is necessary to establish a trust between the Local RapidIdentity instance and the Remote RapidIdentity instance.
Follow these steps to configure the Federation Authentication method.
Obtain the local RapidIdentity instance metadata by entering the following into the browser location bar: https://<hostname>/idp/sp-metadata.xml.
Capture the metadata and save it to a local text file.
Navigate to the remote RapidIdentity instance and register a new Relying Party using this metadata.
On the remote RapidIdentity instance, it is necessary to permit the release of at least one attribute to uniquely identify the user in the local identity provider. For example, if the user's idautoID in the remote RapidIdentity instance matches the idautoID in the local RapidIdentity instance, then the idautoID attribute is sufficient. Otherwise, additional attributes must be released and verified to match in both instances to uniquely identify the authenticating user. This is done by using Attribute Mappings.
On the local RapidIdentity instance, set up the remote instance as a Trusted Identity Provider.
On the local RapidIdentity Instance with an existing or new authentication policy, add the Federation Authentication method. Enable the method and select the Trusted Identity Provider you just configured from the Trusted Identity Provider drop-down box.
To forward the specified forward username attribute value to the Trusted IdP during authentication, click the checkbox next to Forward Username and fill out the next two form items. This results in bypassing the initial username entry and sends the username directly to the next method with text at the bottom that verifies that the user is correct before proceeding.
Forward Username Attribute - Select the GAL item that corresponds to the attribute containing the username for the remote IdP.
Forward Username Name ID Format - Determine the SAML Name ID format for the forwarded username subject for the remote IdP.
Note
Usually,
Unspecifiedwould be the best choice;Emailis appropriate for Email attributes.Other options may be appropriate if the username value corresponds to what those formats are used for in SAML.
Save the authentication policy.
Create a Duo Authentication Policy
Once the Duo authentication has been configured, set up a policy with Duo as the authentication method.
From the Authentication Methods menu, choose Duo and select the preferred Duo Configuration from the provided dropdown box.
Note
Multiple Duo policies can be configured in order to provide different user groups with Duo authentication method options (mobile, email, etc. as preferred).
When users are assigned to this authentication policy, they will encounter a Duo menu after entering a username. If the Duo account is configured for enrollment, then the first time a user logs in they will need to set up their mobile application to associate with this method.
Subsequent logins will give users a choice of how they would like to receive their authorization request, depending on how Duo is configured.
Authentication Options
If "Enable authentication policy choices" is checked, then it means that if an authenticating user, at authentication time, matches against multiple authentication policies, they will be given the choice to try a different policy if for some reason they cannot meet the requirements of one of their policies.
Without this option checked, an authenticating user will only be given the opportunity to attempt to authenticate to the first policy they match, going down the list in prioritized order. This menu provides administrators the option to enable this for users, as well as to modify four different ID elements for a user if needed.
TOTP Keys
Social IDs
Pictograph Choices
FIDO device registrations
 |
Clicking the Delete button opens a window to search users by first name, last name, or email address.
 |
FIDO Configuration
Note
FIDO U2F has been deprecated from Google Chrome as of February 2022. This has been replaced with Web Authn.
FIDO U2F devices can function in multiple domains, which enables a FIDO U2F devices to work in use cases in which RapidIdentity Federation and Portal are not on the same server.
 |
The FIDO App ID Host is the fully qualified domain name (FQDN) of RapidIdentity Federation. For use cases in which RapidIdentity Federation and Portal are enabled in the same server, the FQDN is that of RapidIdentity. Use cases in which RapidIdentity Federation and Portal are enabled in different servers require the FIDO App ID Host to be the Federation Server (i.e., auth.organization.com). Once the FQDN is entered the FIDO App ID displays automatically.
Note
The https:// prefix is added to anything entered in FIDO App ID Host for the FIDO App ID field. Do not type https:// in the FIDO App ID Host field, as it may affect functionality.
IP Addresses will not work in this field; it must be populated with an FQDN.
 |
The FIDO App ID Port is the optional Federation port (i.e. 8443). This can be left blank if there is not a special port needed to access the appliance.
FIDO Facets are the allowed FQDNs in which FIDO U2F devices are permissible. Use cases in which Federation and Portal are not on the same server require each FQDN to be entered as a Facet; otherwise, only one facet is required.
Note
This field follows the same rules as FIDO App ID Host, in that it must be a fully qualified domain name without https:// and not an IP address.
In this example, authentication is managed by the server at auth.example.com, but FIDO is being managed on a server at portal.example.com. Adding the server managing FIDO as a facet allows that server to communicate with the FIDO device.
Note
App IDs and Facets must have a public suffix in order to function correctly.
For some examples, domain.com, domain.org, and domain.net are acceptable suffixes, while domain.local, domain.test, and domain.beta will not perform as expected.
 |
Note
This is only required if multiple servers are being used.
Decision Process
To determine whether and how a FIDO device applies to an Authentication Policy, follow this stepwise process.
Does the use case require FIDO?
No: Choose different Authentication Methods, Criteria, or both.
Yes: Proceed to Question #2.
Does the use case require FIDO to differentiate the user population?
No: Use FIDO as an Authentication Method.
If more than one Authentication Method is in the Authentication Policy, prioritize the Methods using the up and down arrows.
Optionally allow users to defer the challenge for up to 30 days.
Yes: Use FIDO as an Authentication Criterion.
If the criterion applies to users with a registered device, select Enabled only.
If the criterion applies to users without a registered device, select Enabled and Inverse Match.
Does the use case require FIDO devices in more than one domain?
No: Configure the FIDO App ID Host and Facet to be the RapidIdentity FQDN.
Yes: Configure the FIDO App ID Host to match the RapidIdentity FQDN and the FIDO Facets to include the Federation and Portal FQDNs.
FIDO Configuration - Security Key Setup
The FIDO authentication method requires users to insert their U2F security key into their computer to authenticate to RapidIdentity. It first has to be set up as an authentication method associated with the user.
From the User drop-down menu, click Manage FIDO.
Note
The Manage FIDO action will not work if the Federation Integration settings are not configured properly. If those settings are left at default values, the user will see a 500 server error and will be unable to manage FIDO devices.
If there are no FIDO keys currently set for this user, one will have to be created. Click Add Device.
Ensure there is a recognized Security Key inserted into the computer. Give the key a name that is easily recognizable and click Continue.
Touch the sensor on the key to add biometric credentials.
The key is now set up and can be used as an authentication method.
Note
If you receive
FIDO registration error 2during this process, check the FIDO configuration. This implies a misconfiguration among servers.
FIDO Authentication
When users match an authentication policy criteria in which FIDO is a required method, RapidIdentity prompts users to insert their token into the device, even if the device is already inserted.
 |
To complete this authentication step, press the FIDO touch interface on the security token.
When users match an authentication policy criteria in which FIDO is a required method, RapidIdentity prompts users to insert their token into the device, even if the device is already inserted.
Users have approximately two minutes to press the touch interface before this authentication step times out. If this event occurs, users must start over from the beginning, which in this example would mean re-entering their username and password.
In this particular example, since FIDO is a second factor necessary to authenticate, users are directed to the configured landing component once touch interface is pressed.
FIDO Token
This authentication example used a Yubikey NEO token.
If the token is inserted prior to authentication, the Wi-Fi symbol appears green.
Once users arrive at the authentication step requiring FIDO, the Wi-Fi symbol flashes green.
After the authentication is complete the Wi-Fi symbol appears green.
Other U2F vendor keys may appear and function differently.
Key Security and Storage
Once authentication is complete, the FIDO token can be safely removed from the device without concern for a user being automatically logged out of RapidIdentity.
If a user's FIDO token needs to be replaced or unbound to their digital identity, the FIDO device registration bound to their identity can be deleted using either of two methods:
Pressing the Delete FIDO device registrations for a User action button as shown in Configuration.
Pressing the Reset FIDO action button in a configured RapidIdentity Portal delegation. This action button is made available through Delegations.
Duo
Using this authentication method requires creating or having an existing Duo account, and can be used to verify users through this system.
Navigate to the Duo menu in Configuration > Policies > Authentication, and click Add Duo Config +.
Give the configuration a name and a description, then enter the Integration Key, Secret Key, and API hostname provided by Duo.
RapidIdentity uses the username attribute to authenticate with Duo. To use a different LDAP attribute, make that selection here.
Once the Duo policy has been configured, set up an Authentication method to feature it.
Duo Registration
RapidIdentity can authenticate with Duo, a multi-factor authentication service. To configure RapidIdentity within Duo, first you will need to set up a Duo account.
Login or Register for a Duo account at https://duo.com/.
Select Protect an Application from the left navigation bar.
Scroll through the list of Applications for Web SDK, or use the filter to find Web SDK and click Protect.
Make note of the Integration Key, Secret Key, and API Hostname in the Details section.
Note
You will need this information to configure Duo in RapidIdentity.
You are now ready to configure Duo as an Authentication Method in RapidIdentity. If you wish to tailor the Duo configuration, you can refer to the Helpful Links from the left side navigation bar for additional information.
Kerberos Configuration
The Kerberos Configuration settings are global with respect to RapidIdentity. Click the Enabled checkbox to show the fields to be populated.
 |
Field Name | Description |
|---|---|
Enable Automatic Processing | When selected, RapidIdentity will always attempt to do a Kerberos authentication behind the scenes. When properly configured in some environments, this can allow seamless authentication with no user input required. In environments where different types of machines and browsers are in use, however, it can lead to a poor user experience. Disabling this option makes it so that a Kerberos attempt only happens when the authenticating user clicks the "Log in with Windows Credentials" button. |
Domain | The Kerberos domain. |
KDC Address | The Kerberos Key Distribution Center address. |
Service Principal | The service principal name. |
Service Principal Password | The service principal account password. |
Enable Debugging | It is necessary to restart RapidIdentity Appliance to enable Kerberos server-side debugging. |