RapidIdentity Product Guide: Legacy UI


Authentication enables administrators to define and prioritize authentication policies, include policies that incorporate multi-factor authentication. 


Authentication contains six sections:


Policies allow administrators to create and manage existing authentication policies. There are three Policies configuration content areas.

  1. General

  2. Criteria

  3. Authentication Methods

Newly created and existing policies can be configured to specific user groups or roles, each with their own specific criteria and or authentication methods. The value is that administrators have expansive degrees of freedom to manage how users authenticate to RapidIdentity.

Policies - General Tab

Administrators can create new policies by clicking the green plus icon and remove existing policies by clicking the red minus icon.

The policy name and description are both required. To enable the policy, check the Enabled box. Clicking Save assigns the policy a fixed, unique ID.


Administrators can configure whether QR Codes generated are tied to a user's password – secure or insecure QR Code. When this check box is selected, users matching this policy can enter a QR code instead of their username. However, it is advisable to configure an insecure QR Code policy to include at least one additional authentication method or criteria. RapidIdentity Portal users able to generate QR Codes can determine whether the printed QR Code is secure or insecure.

If there are no authentication policies defined, all users are required to authenticate with their username and password to access RapidIdentity.

Multi-Factor Authentication policies existing prior to RapidIdentity 3.5 are imported automatically, and these policies will have the "[Migrated]" label appended to the policy name.

Administrators can configure an authentication policy to always fail by clicking the Always Fail checkbox. When checked, the Authentication Methods tab becomes disabled and administrators can then define criteria (e.g. LDAP filter, Day of Week) to prevent authentication. Users are identified as matching this policy by either entering their username, scanning a QR Code, or through Kerberos. If the Always Fail policy is the highest prioritized authentication policy, a successful match prevents authentication to RapidIdentity. If the Always Fail policy is not the highest prioritized policy, a user matching the Always Fail policy could authenticate successfully if they match a higher priority policy, however, a user matching a lower prioritized policy relative to the Always Fail policy will not be able to authenticate using the lower prioritized policy. Administrators can update the Always Fail error message by navigating to Localization | net.idauto.idp.messages | idp.message.alwaysFail.

Always Fail Use Case

There are three enabled authentication policies, and authentication policy choices are configured to allow users to determine how they authenticate to RapidIdentity. The three policy choices are prioritized as follows:

  1. Policy 1

  2. Always Fail Policy

  3. Policy 3

If a user matches all three policies, the user can authenticate to RapidIdentity successfully using the method(s) defined in Policy 1 only. If the user attempts to authenticate to RapidIdentity using the method(s) defined in Policy 3, the user will not be able to authenticate to RapidIdentity.

The Authentication Options section contains allows administrators to delete four different user settings and toggle Authentication Policy Choices.

  1. TOTP keys

  2. Social IDs

  3. Pictograph Choices

  4. FIDO device registrations

Policies | Criteria

The Criteria subtab allows administrators to determine when the policy should be active. There are seven criteria.

  1. LDAP filter

  2. Day of Week

  3. Time of Day

  4. Source Network

  5. Kerberos

  6. QR Code

  7. FIDO

Table 197. Policies Criteria



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

If the Match the Built-in Admin Account checkbox is selected, the Backup Administrator account will match this policy and be required to adhere to any additional Criteria and Methods with this policy. Thus, the Backup Administrator account authentication is not limited to only username and password, and this account can match organization multi-factor authentication requirements.

Day of Week

Administrators can choose any or all weekdays, and choose the appropriate time zone.

Time of Day

Administrators can choose any time of day range, and choose the appropriate time zone.

Source Network

Administrators can assign specific networks or subnets to an authentication policy and can either Whitelist or Blacklist as the Match Type. Whitelist will allows sessions from networks in the list and Blacklist allows sessions from networks 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.

Clicking Save allows clients whose IP addresses match the criteria.


Administrators can allow users to authenticate with a Kerberos-enabled browser.

Users that do not have a Kerberos-enabled browser could be required to match other criteria or methods (e.g. password then TOTP). To include all users in this use case, the Kerberos policy must be ranked higher than the password then TOTP policy.

QR Code

Users can authenticate with their QR Code. 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.


When enabled, FIDO U2F applies to users with at least one registered FIDO device.

Inverse Match applies to users who do not have a registered FIDO device and requires administrators to select both Enabled and Inverse Match.

Policies | Authentication Methods

Administrators can click the green up or down arrows to prioritize authentication methods.

The ten authentication methods are:

  1. Password

  2. TOTP

  3. RapidIdentity Portal Challenge (Questions)

  4. SMS

  5. Kerberos

  6. Social

  7. QR Code

  8. Pictograph

  9. PingMe

  10. FIDO

Each of the hyperlinked methods in the table below direct to a RapidIdentity Appliance page describing configuration details.

Table 198. Authentication Methods

Authentication Method



Users authenticate with their password.


Users have a finite time window to enter a third-party (e.g. Google Authenticator) generated code to authenticate.

Window Size: vgoverns 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.

Setup Instructions: Necessary instructions for users to view when setting up their device.

Portal Challenge (Questions)

Users authenticate with their RapidIdentity Portal Challenge Questions.


Users authenticate with a code sent to their mobile device through SMS.


Users authenticate with browser-provided Kerberos tickets automatically.


Social authentication allows users to authenticate to RapidIdentity through their Facebook, Google+, LinkedIn, or Twitter account. Authenticating against any of the enabled social networks is sufficient.

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.

To learn how to obtain the ID and Secret field values, navigate to Social.

QR Code

When enabled, the QR code is a required authentication method.


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.

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. Once the user verifies their pin on the mobile application the user is automatically directed to the configured RapidIdentity landing module. 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.

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.

Service Description: Optional. A friendly description that will display on the user's authentication device with the authentication request. If left blank, the default description is 'RapidIdentity Federation'.


When enabled, users authenticate with a FIDO U2F security key. Currently, FIDO is supported with the Google Chrome and Opera browsers only. Administrators can allow users to defer the FIDO challenge for 30 days.

Integrating with Google 2-Step Verification

If the environment federates with Google through SAML SSO and Google's 2-Step Verification is configured, users will not be prompted to enter the corresponding Google TOTP code when logging in through the RapidIdentity Federation login page. If a user attempts to access Google first (e.g. desktop browser or mobile device), they will be redirected to the RapidIdentity Federation login page and be required to authenticate based on the enabled authentication policies.

Google Super Administrators are required to enter the Google TOTP code if the authentication attempt begins with Google. Google Super Administrators are not required to enter the Google 2-Step TOTP code if the authentication attempt begins with the environment RapidIdentity Federation login page. To learn more, visit the G Suite Administrator 2-Step Help article.

Unsupported Authentication Method

RapidIdentity 4.3 deprecates the LaunchKey authentication method. Existing authentication policies incorporating the LaunchKey authentication method can render the authentication policy ineffective, therefore users or groups matching this policy cannot authenticate to RapidIdentity.

Current policies incorporating a deprecated or unsupported authentication method display a message to users after the authentication attempt informing them that need to contact their support team.


Users in the System Admin role receive user interface notification stating that an authentication method is not supported and that the authentication policy should be disabled and reconfigured. 

Kerberos Configuration

The Kerberos Configuration settings are global with respect to RapidIdentity.  

Table 199. Kerberos Fields

Field Name



Click this checkbox to enable this feature.

Enable Automatic Processing

If enabled, Kerberos processing is attempted during authentication. If disabled, users must click a button called "Log in with Windows Credentials" to attempt Kerberos authentication. This configuration option allows admin to configure Kerberos and selectively turn off Kerberos processing as desired. Only an HTTP response of 200 is allowed. Successful Kerberos authentication always results in proceeding to the next authentication policy step (i.e. authentication method or redirect to the configured RapidIdentity component or module).


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.

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.  


The FIDO App ID Host is the fully qualified domain name of RapidIdentity Federation. For use cases in which RapidIdentity Federation and Portal are enabled in the same server, the FQDN is that of RapidIdentity. Uses 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., https://auth.organization.com) . Once the FQDN is entered the FIDO App ID displays automatically.  

The FIDO App ID Port is the optional Federation port (i.e. 8443).

FIDO Facets are the allowed domains in which FIDO U2F devices are permissible. Use cases in which Federation and Portal are not on the same server require each domain to be entered as a Facet, otherwise only the RapidIdentity domain is necessary. 

SMS Configuration

The settings in the SMS configuration screen give administrators control over how RapidIdentity will act when it needs to send an SMS. This is used for SMS authentication and in some Connect features.

Navigate to Configuration > Core Configuration > Authentication > SMS Configuration.

  1. The Dial Prefix should be anything the service needs to dial before the user's phone number to send an SMS - this includes country and area codes as needed. More rules are listed in Configuring the Phone Number below.

  2. There are two usable SMS Providers available for selection: Amazon Web Services Simple Notification Service (AWS SNS) and RapidIdentity SMS Gateway.


AWS SNS allows RapidIdentity to send SMS messages by making API requests to the AWS SNS service. In order to do that, RapidIdentity needs AWS credentials.


The Use Instance IAM Role option instructs RapidIdentity to pull credentials directly from the EC2 instance it is running on provided the instance was configured with an IAM Role.

If Use Instance IAM Role is not selected, then static AWS keys must be entered. This option also allows RapidIdentity to send SMS messages via SNS when it is not running in AWS.


The EC2 instance must be configured with an IAM Role for this to function properly. Those settings are in the AWS UI.

RapidIdentity SMS Gateway

With a valid RapidIdentity SMS Gateway license installed and this option chosen, RapidIdentity will perform the necessary operations without the user needing to do any further AWS configuration.

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.

Trusted IdPs

In the Federation Authentication Method, RapidIdentity Federation acts as a SAML 2.0 Relying Party to a RapidIdentity Identity Provider or a third-party SAML Identity Provider.

When configuring the Federation Authentication Method for an Authentication Policy, you must choose a previously configured Trusted Identity Provider. Therefore, a Trusted Identity Provider contains all of the configuration necessary to facilitate SAML 2.0 SSO between RapidIdentity Federation and a third-party SAML 2.0 Identity Provider.

SAML 2.0 Trusted IdPs are configured similarly to RapidIdentity Trusted IdPs, but instead of having the fields host and port, they require the fields loginUrl and binding.

To add a new IdP, click the green Add (Legacy_Add_Button.png) button.


In the fields that activate, fill out the information as provided by the identity provider.





Required field - give the IdP a meaningful name


Optional description if desired

Entity ID

The SAML 2.0 Entity ID of the third-party Identity Provider

Signing Certificate

Cut and paste the provider's certificate into this box

Configuration Type

The Identity Provider to be used when composing SAML responses. RapidIdentity makes it simple to point to an external RapidIdentity Identity Provider, and SAML2 provides specific settings for third-party IdPs


The hostname of the remote RapidIdentity Identity Provider - for RapidIdentity IdPs only


The port the Identity Provider is to use with requests. This defaults to 443 - for RapidIdentity IdPs only


This mechanism defines how to do the SAML authentication. This field defaults to HTTP-Redirect, but HTTP-POST is also an option for this field - for SAML2 IdPs only


The URL to which the SAML 2.0 authentication request will be sent - for SAML2 IdPs only

Attribute Mappings

See explanation below

The Attribute Mappings table allows administrators to map attributes from the local Identity Provider to the remote Identity Provider. To match the same user in both systems, both systems must have a uniquely identifying attribute for each user. For example, if email address is the unique identifier, configure the Local field with the attribute name for email (e.g., "mail"), and the Remote field with the same attribute as it is named in the other system (e.g., "emailAddress"). To add a new attribute mapping, click the green Add button (Legacy_Add_Button.png) below the Attribute Mappings table.


Attribute Mapping supports a special remote attribute value: @NameID. This indicates that the NameID attribute returned from the Remote Identity Provider should be mapped to the specified Local attribute.


Options allow administrators to determine whether users can select the authentication method(s) to authenticate to RapidIdentity and to delete four different configurations bound to their digital identity.

  1. TOTP Keys

  2. Social IDs

  3. Pictograph Choices

  4. FIDO device registrations


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

Authentication Policy Choices

The Enable Authentication Policy Choices checkbox enables administrators to allow users to select what authentication method(s) to use to authenticate to RapidIdentity. When this box is checked, RapidFederation "collects" all matching policies associated with the user. Users matching more than one policy are presented with a drop-down box to select an authentication method after entering their username.

In order for users to select an authentication method (e.g. PingMe or Password with Challenge Questions), at least two authentication Policies must exist and the user attempting to authenticate must match both policies. If a user only matches one policy, authentication proceeds in accord with how that policy is configured.

Use Case

If a user upgrades or misplaces a required mobile device or a required QR Code, they are unable to authenticate to RapidIdentity until that device or code is reconfigured, found, replaced, or until an administrator can temporarily adjust the authentication policy. The elapsed time affects productivity for the user, associated team members, and anyone else involved to remedy this situation.

The advantage of providing users with a choice during the authentication process is that it does not require users to be dependent on a device or token during the authentication process and it saves time in the event an instance occurs when a user cannot authenticate with a policy-dependent device or token. If the policies are configured to include multi-factor authentication, users can still authenticate to RapidIdentity securely through all policies.

For example, an organization may have these three ordered policies.

  1. PingMe

  2. QR & Challenge

  3. Password & Challenge (default)

PingMe requires a mobile device with the RapidIdentity Mobile application installed. The QR Code must be printed and on hand to present to the QR Code reader. If either the mobile device or QR Code is absent, the user cannot authenticate to RapidIdentity. With the Enable Authentication Policy Choices checkbox selected, a user matching either of the first two policies could then select option 3 to authenticate successfully.