RapidIdentity Product Guide

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. 

Authentication_Policy_-_Main.jpg

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.

Config_-_Policies_-_General.png
Table 60. Authentication Policies - General

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.

Note

Once 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. If an insecure QR code is used, the authenticating user will be asked to scan a secure QR code for authentication later.

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.

Note

If 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.

Disabled_QR_Code.png


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.

Table 61. Criteria Tabs

Criteria

Description

LDAP Filter

The LDAP Filter criteria evaluates to true if the authenticating user matches the filter. Administrators can click the magnifying glass to use the LDAP criteria builder, or enter the appropriate LDAP filter in the space provided. Once the Enabled box is checked and the criteria are saved, users matching the LDAP filter will match the authentication policy criteria.

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.

Auth_Policies_with_LDAP.png

Day of Week

The Day of Week criteria evaluates to true if the user is authenticating on one of the configured days of the week as defined in the configured time zone. If no time zone is specified, the RapidIdentity server's time zone will be used.

Auth_-_Crit_-_Day_of_Week.jpg

Time of Day

The Time of Day criteria evaluates to true if the user is authenticating during the configured time period as defined in the configured Time Zone. If no time zone is specified, the RapidIdentity server's time zone will be used.

Auth_-_Crit_-_Time_of_Day.jpg

Source Network

Whitelist means that the criteria will only evaluate to true if the authenticating user is communicating with RapidIdentity from one of the networks in the list. Blacklist means that the criteria will only evaluate true if the authenticating user is communicating with RapidIdentity from a network not in the list.

Checking the Enable HTTP Header Processing box will match the X-Forwarded For HTTP header used by proxies and load balancers.

Auth_-_Crit_-_Source_Network.jpg

Kerberos

Administrators can allow users to authenticate with a Kerberos-enabled browser. The Kerberos criteria only evaluates to true if Kerberos authentication was successful.

Auth_-_Crit_-_Kerberos.jpg

QR Code

The QR Code criteria only evaluates to true if the authenticating user successfully initated the authentication flow by scanning a QR code.

Auth_-_Crit_-_QR_Code.jpg

FIDO

The FIDO criteria only evaluates to true if the authenticating user has at least one registered FIDO device. If Inverse Match is checked, then the criteria evaluates to true ONLY if the authenticating user does not have a registered FIDO device.

Auth_-_Crit_-_FIDO.jpg


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.

Authentication_Methods_Cloud.jpg

There are 13 authentication methods described below. Use the links for more detailed information on each method.

Authentication Method

Description

Duo

Users authenticate with a preconfigured Duo account.

EmailEmail

Users authenticate through a RapidIdentity email address

Federation

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.

FIDO

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.

Kerberos

Users authenticate with licensed, browser-provided Kerberos tickets automatically.

Password

Users authenticate with their directory password.

Pictograph

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.

PingMe

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.

HorzRule3-black.png

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.

Portal Challenge (Questions)

Users authenticate with their RapidIdentity Portal Challenge Questions.

QR Code

When enabled, a valid, secure QR code must be scanned. This is a licensed method.

SMS

Users authenticate with a code sent to their mobile device through SMS. This is a licensed method.

Social

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.

TOTP

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

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.

Auth_-_FIDO.jpg
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 (e.g. interns, contractors) 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.

  1. 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.

    Pictograph_Authentication-cr-wdat.png
  2. 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.

    Default_or_Custom_Image_Pool.png
  3. 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.

    Pictograph_Image_Manager.png
  4. Define 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.

  5. Define Number of Images to Challenge as the number of images that will be displayed at once during the pictograph challenge at login. The default number is 9.

  6. 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. 

Pictograph_Setup_1.png

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 Pictograph_Refresh.png at the top right of the image group.

Pictograph_Setup_2.png
Pictograph_Setup_3.png

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.

Pictograph_Setup_4.png

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.

Pictograph_Login_1.png
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
  1. 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.

    PingMe_Authentication_Options.png
  2. In People > Delegations, ensure that the Actions Enroll Mobile Device, Update Mobile Device, and Delete Mobile Device have been added to this policy.

  3. 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.

  1. User selects Enroll Mobile Device from the Self-Service Interface.

    Enroll_Mobile_Device.jpg

    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.

    1. 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.

      Updated_Email.jpg
    2. 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.

      PingMe_Text_Notification.jpg
    3. 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.

  2. 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:

    1. Click the + in the top right of the application's screen.

      Add_Account___Symbol.jpg
    2. Click Add Manually.

      Add_Manually.jpg
    3. On the next screen, click Add a Server Account.

      Manual_Account_Add.jpg
    4. Enter the Server URL of the RapidIdentity system the user will be authenticating into and click Submit.

    5. Enter user credentials when requested, and create a 6-digit PIN for further security.

    6. 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.

      PingMe_Approve_or_Deny.jpg
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.

NonNative_PingMe_Auth_Options.png
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.

PingMe_Pinging.png

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.

PingMe_Login.png

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.

Portal_Challenge_-_cr.png

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. 

Auth_-_SMS.jpg

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.

SMS_Authentication_pre-LDAP.png

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.

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.

Social_Auth_Main.png

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.

Facebook

Follow these steps to configure Facebook social authentication:

  1. Navigate to Facebook for Developers and, if necessary, create an account.

  2. 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=facebook

  3. Once the app is created, navigate to Settings > Basic to capture the App ID and App Secret.

    Facebook_App_ID___App_Secret-obs.png
  4. Return to RapidIdentity.

  5. 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.

    Facebook_Authentication_-_obsc.png
  6. 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.

  7. When the user logs in, they will be prompted to Login with Facebook.

    Facebook_Auth_Login.png
  8. 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.

    Finish_Facebook_Auth.png
Google

Follow these steps to configure Google social authentication:

  1. 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 would need to be added in the Google Admin Console.

  2. Follow the Google API directions to Create a project. This will be a web application.

    Note

    Ensure the Organizational Site URL is always presented in the following format in the Consent Screen and Web application details:

    https://<RF_HOST>:<RF_PORT>

    Enter the redirect URI as follows:

    https://<RF_HOST>:<RF_PORT>/idp/socialCallback?n=googleplus

  3. Once the app is created, navigate to the Client ID for Web Application page to capture the client ID and client Secret.

    Google_-_WebApp_-_wBlur.png
  4. 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.

    Google_Auth_Options-obs.png
  5. 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.

  6. When the user logs in, they will be prompted to log in with their Google credentials.

    Google_Auth.png
  7. 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.

    Finish_Google_Auth.png
LinkedIn

Follow these steps to configure LinkedIn social authentication:

  1. Navigate to the LinkedIn Developers' page and, if necessary, create an account.  

  2. 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=linkedin

  3. Once the app is created, navigate to Authentication to capture the Client ID and Client Secret.

    LinkedIn_Keys-obs.png
  4. 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.

    LinkedIn_Authentication-obs.png
  5. 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.

  6. When the user logs in, they will be prompted to Login with LinkedIn.

    LinkedIn_Auth_Login.png
  7. 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.

    Finish_LinkedIn_Auth.png
Twitter

Follow these steps to configure Twitter social authentication.

  1. Navigate to the Twitter Developer page, and, if necessary, create an account.

  2. 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/twitter

  3. Once the app is created, navigate to Keys and tokens to capture the Consumer API key and API secret key.

  4. Click Keys and Access Tokens to access the Consumer Key and Consumer Secret.

    Twitter_-_API_Keys.jpg
  5. 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.

    Twitter_Keys_in_RI.jpg
  6. 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.

    Choose_Twitter.jpg
  7. 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.

    Authorize_RI_in_Twitter.jpg
  8. Once the user has signed into their Twitter account, they can return to RapidIdentity to continue logging in.

    Finish_Twitter_Auth.jpg
  9. 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.

TOTP_Auth_New_UI.png

Follow these steps to create an Authentication Policy using TOTP code integrating the RapidIdentity Mobile Application:

  1. Access RapidIdentity and then select Configuration > Policies > Authentication > Authentication Policies.

  2. Click New Authentication Policy.

  3. Fill out the General and Criteria fields as needed, and enable TOTP.

  4. 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:

    1. Value of 1 means that only the current code is valid.

    2. Value of 2 means the previous, current, and next codes are valid.

    3. Value of 3 means the previous two, current, and next two codes will be considered valid.

  5. 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.).

  6. 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.

  7. 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.

  8. When complete, click Save.

RapidIdentity will direct the user to configured landing module. When the user logs in after the policy is set, they will put in their Username and Password as before. If the user has not configured TOTP yet, they will then be shown a page to set up this feature on their device. The user will need to follow the setup wizard and enter a valid code to continue.

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.

  1. Obtain the local RapidIdentity instance metadata by entering the following into the browser location bar: https://<hostname>/idp/sp-metadata.xml.

  2. Capture the metadata and save it to a local text file.

  3. Navigate to the remote RapidIdentity instance and register a new Relying Party using this metadata.

  4. 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.

  5. On the local RapidIdentity instance, set up the remote instance as a Trusted Identity Provider.

  6. 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.

  7. 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.

    1. Forward Username Attribute - Select the GAL item that corresponds to the attribute containing the username for the remote IdP.

    2. Forward Username Name ID Format - Determine the SAML Name ID format for the forwarded username subject for the remote IdP.

      Note

      Usually, Unspecified would be the best choice; Email is appropriate for Email attributes.

      Other options may be appropriate if the username value corresponds to what those formats are used for in SAML.

  8. 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.

  1. From the Authentication Methods menu, choose Duo and select the preferred Duo Configuration from the provided dropdown box.

    Duo_Auth_Method.png

    Note

    Multiple Duo policies can be configured in order to provide different user groups with Duo authentication method options (mobile, email, etc. as preferred).

  2. 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.

    Duo_First_Time_Setup.png
    Duo_First_Time_Setup_Choose_Type.png
  3. Subsequent logins will give users a choice of how they would like to receive their authorization request, depending on how Duo is configured.

    Duo_Auth_1.png
    Duo_Auth_2.png
    Duo_Login_with_Text.png
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.

  1. TOTP Keys

  2. Social IDs

  3. Pictograph Choices

  4. FIDO device registrations

Authentication_Options_Menu.jpg

Clicking the Delete button opens a window to search users by first name, last name, or email address.  

Delete_Configurations_for_User.jpg
FIDO Configuration

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.  

FIDO_Configuration_via_Auth.jpg

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.

FIDO_App_ID_Host_Example.jpg

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.

Facet Example

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.

FIDO_Facet_Example.jpg

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.

  1. Does the use case require FIDO?

    1. No: Choose different Authentication Methods, Criteria, or both.

    2. Yes: Proceed to Question #2.

  2. Does the use case require FIDO to differentiate the user population?

    1. No: Use FIDO as an Authentication Method.

      1. If more than one Authentication Method is in the Authentication Policy, prioritize the Methods using the up and down arrows.

      2. Optionally allow users to defer the challenge for up to 30 days.

    2. Yes: Use FIDO as an Authentication Criterion.

      1. If the criterion applies to users with a registered device, select Enabled only.

      2. If the criterion applies to users without a registered device, select Enabled and Inverse Match.

  3. Does the use case require FIDO devices in more than one domain?

    1. No: Configure the FIDO App ID Host and Facet to be the RapidIdentity FQDN.

    2. 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.

  1. From the User drop-down menu, click Manage FIDO.

    Manage_FIDO-sm.png

    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.

  2. If there are no FIDO keys currently set for this user, one will have to be created. Click Add Device.

  3. Ensure there is a recognized Security Key inserted into the computer. Give the key a name that is easily recognizable and click Continue.

  4. Touch the sensor on the key to add biometric credentials.

  5. The key is now set up and can be used as an authentication method.

    Note

    If you receive FIDO registration error 2 during 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. 

Fido_Registration.png

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:

  1. Pressing the Delete FIDO device registrations for a User action button as shown in Configuration.

  2. 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.

  1. Navigate to the Duo menu in Configuration > Policies > Authentication, and click Add Duo Config +.

  2. 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.

    Duo_Initial_Setup.png
  3. 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.

  1. Login or Register for a Duo account at https://duo.com/.

  2. Select Protect an Application from the left navigation bar.

    Duo_Left_Side_Bar_Navigation.PNG
  3. Scroll through the list of Applications for Web SDK, or use the filter to find Web SDK and click Protect.

    Duo_Web_SDK.PNG
  4. 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.

    Duo_Integration_Details.PNG
  5. 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.

    Duo_Helpful_Links.PNG
Kerberos Configuration

The Kerberos Configuration settings are global with respect to RapidIdentity.  Click the Enabled checkbox to show the fields to be populated.

Kerberos_Config.png

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.