Policies
Policies allow administrators to create and manage existing authentication policies. There are three Policies configurations content areas.
General
Criteria
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
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.
Policies | Criteria
The Criteria subtab allows administrators to determine when the policy should be active. There are seven criteria.
LDAP filter
Day of Week
Time of Day
Source Network
Kerberos
QR Code
FIDO
 |
 |
 |
 |
 |
 |
 |
Criteria | Description |
|---|---|
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 idauto::admin account will match this policy and be required to adhere to any additional Criteria and Methods with this policy. Thus, the idauto::admin 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. |
Kerberos | 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. |
FIDO | 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:
Password
TOTP
RapidIdentity Portal Challenge (Questions)
SMS
Kerberos
Social
QR Code
Pictograph
PingMe
FIDO
Each of the hyperlinked methods in the table below direct to a RapidIdentity Appliance page describing configuration details.
Authentication Method | Description |
|---|---|
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. | |
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. | |
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.
 |