Evaluating Assurance Levels and Primary Authentication Status to Return Authentication Methods

After the Cloud Authentication Service receives an Initialize request from an authentication client, the server determines which authentication methods to return to the client by evaluating the following factors:

  • Assurance level (specified in a policy or by itself). See Assurance Level Evaluation for a description of this process.

  • Verification of the primary authentication method. Users are challenged for primary authentication (for example, username and password) when they initially attempt to access the application. After primary authentication, the assurance level determines if additional authentication is required using SecurID, SecurID Authenticate OTP, Approve, Device Biometrics, SMS OTP, Voice OTP, or Emergency Access Code.

    The client might not require primary authentication. If it is required, the server might return different results depending on whether primary verification succeeds.

  • If the client's required assurance level or higher contains the primary authentication method in the list of methods required for additional authentication, and if that method is satisfied during primary authentication, the server does not return that method to the client.

For examples of server behavior, see Scenario: Assurance level does not include the primary authentication method and Scenario: Assurance level includes the primary authentication method.

Assurance Level Evaluation

When the Cloud Authentication Service receives an authentication request, it evaluates the client's assurance level to determine which challenge (authentication) methods to return to the client. Clients that are configured as relying parties in the Cloud Administration Console are assigned an access policy in the relying party settings. If an Initialize request specifies the assurance level or an access policy, that request overrides the configuration specified in the Cloud Administration Console.

Assurance levels define the authentication methods required to access applications. SecurID provides three assurance levels: High, Medium, and Low. Each level indicates the relative strength and security of the authentication methods within that level. The Super Admin configures authentication options for each assurance level. An option can be a standalone authentication method such as Device Biometrics, or it can combine two methods connected by AND operators, such as SecurID OTP and Approve.

The first option listed for an assurance level on the Assurance Levels page is presented as the default for each new user when he or she authenticates to an application or client assigned to that assurance level for the first time. A user can select another option at any time, as long as the assigned assurance level or a higher assurance level contains additional options that the user can complete. When a user successfully authenticates with an option, that option becomes the user's default for future authentications for that assurance level.

For more information on assurance levels, see "Assurance Levels" on RSA Link at https://community.rsa.com/t5/securid-cloud-authentication/assurance-levels/ta-p/650973

Assurance Level Evaluation Steps

When the Cloud Authentication Service receive an authentication request, it performs the following evaluation:

  1. The server checks the assurance level assigned to the client.
  2. The server creates a list containing the challenge methods for the assurance level and the methods for all higher assurance levels.
  3. The server orders the challenge methods according to the assurance level configuration in the Cloud Administration Console, from lowest to highest, and moves the default method to the top if available.
  4. If any duplicate methods exist, the server eliminates the duplicates.
  5. If primary authentication is not required, the server returns the remaining methods to the client. If primary authentication is required, the server verifies the primary authentication method, then determines which methods to return to the client as shown in the following scenarios.

Assurance Level Evaluation Examples

The following table provides examples of expected server behavior during authentication when the default option is available in the assigned assurance level or a higher level. The default option is moved to the top of the returned list of challenge methods.

Assurance Level Methods Defined for That Level Default
(Last Successful Authentication Method)		 Methods Returned to the Client Plus Higher Levels
HIGH

(SECURID OTP AND APPROVE) OR (SECURID OTP AND DEVICE BIOMETRICS)

(SECURID OTP AND DEVICE BIOMETRICS)

(SECURID OTP AND DEVICE BIOMETRICS) OR (SECURID OTP AND APPROVE)
MEDIUM

(DEVICE BIOMETRICS) OR (SMS OTP)

(SMS OTP)

(SMS OTP) OR (DEVICE BIOMETRICS) OR (SECURID OTP AND APPROVE)
MEDIUM

(DEVICE BIOMETRICS) OR (SMS OTP)

 (SECURID OTP AND APPROVE)

(SECURID OTP AND APPROVE) OR (DEVICE BIOMETRICS) OR (SMS OTP)

LOW (APPROVE) OR (AUTHENTICATE OTP) (AUTHENTICATE OTP)

(AUTHENTICATE OTP) OR (APPROVE) OR (DEVICE BIOMETRICS) OR (SMS OTP)

LOW (APPROVE) OR (AUTHENTICATE OTP)

(DEVICE BIOMETRICS)

(DEVICE BIOMETRICS) OR (APPROVE) OR (AUTHENTICATE OTP) OR (SMS OTP)

The following table provides examples of expected server behavior during authentication when the default option is not available.

Assurance Level Methods Defined for That Level Methods Returned to the Client Plus Higher Levels
HIGH

(SECURID OTP AND APPROVE) OR (SECURID OTP AND DEVICE BIOMETRICS)

(SECURID OTP AND APPROVE) OR (SECURID OTP AND DEVICE BIOMETRICS)
MEDIUM

(DEVICE BIOMETRICS) OR (SMS OTP)

(DEVICE BIOMETRICS) OR (SMS OTP) OR (SECURID OTP AND APPROVE)

LOW (APPROVE)

(APPROVE) OR (DEVICE BIOMETRICS) OR (SMS OTP)

If the method list contains duplicates, the server removes the duplicate sets, as shown in the following example.

Original Methods List Containing Duplicates Methods List After Duplicate Removal

(SECURID OTP AND APPROVE) OR (SECURID OTP AND SMS OTP) OR (APPROVE)

(SECURID OTP AND SMS OTP) OR (APPROVE)

(SECURID OTP AND APPROVE) OR (SECURID OTP AND DEVICE BIOMETRICS) OR (APPROVE) OR (DEVICE BIOMETRICS)

(APPROVE) OR (DEVICE BIOMETRICS)

If a method requires a device and the user has not registered a device, the method is included in the methods list marked with the METHOD_NOT_APPLICABLE attribute and the value DEVICE_NOT_REGISTERED. The user must register a device before using this method.

Scenario: Assurance level does not include the primary authentication method

When the client's assurance level does not include the primary authentication method in the list of methods used for additional authentication, the following behavior occurs:

  • If primary method verification is not required, or if it is required and authentication succeeds, the server returns only the methods from the required assurance level or higher. It does not return the primary method.
  • If primary method verification is required and fails, the server adds the primary method to the list of methods in the assurance level and returns all methods to the client.

The following examples illustrate this behavior. In the following table, the assurance level specifies (DEVICE BIOMETRICS) OR (SECURID OTP AND APPROVE).

Server Action Server Returns These Access Policy Methods to Client Explanation
No primary authentication.

(DEVICE BIOMETRICS) OR (SECURID OTP AND APPROVE)

 Returns only methods from the required assurance level or higher.
Password is successfully verified as primary method.

(DEVICE BIOMETRICS) OR (SECURID OTP AND APPROVE)

 Returns only methods from the required assurance level or higher.
Unsuccessful verification of Password as primary method.

(PASSWORD AND DEVICE BIOMETRICS) OR (PASSWORD AND SECURID OTP AND APPROVE)

 The server adds Password to the list of methods from the required assurance level.

Scenario: Assurance level includes the primary authentication method

When the client's assurance level includes the primary authentication method in the list of methods required for additional authentication, the following behavior occurs:

  1. The server attempts to validate the credential received from the client for primary authentication.
  2. If validation succeeds, the server removes the primary authentication method from the list of methods in the required assurance level or higher and does not return that method to the client. If validation fails, the server adds the primary method to the list of methods in the assurance level.
  3. The server eliminates any redundant methods and returns the remaining methods to the client, which are required to satisfy the assurance level.

The following example illustrates this behavior. In the following table, the assurance level specifies (SECURID OTP AND APPROVE) OR (SMS OTP).

Server Action Server Returns These Access Policy Methods to Client Explanation
No primary authentication.

(SECURID OTP AND APPROVE) OR (SMS OTP)

Returns only methods from the required assurance level or higher.
Successful verification of SECURID OTP as primary method

(APPROVE) OR (SMS OTP)

 SECURID OTP is counted as being completed and is removed from the list of methods from the required assurance level or higher and the remaining methods are sent to the client.
Unsuccessful verification of SECURID OTP as primary method

(SECURID OTP AND APPROVE) OR (SECURID OTP AND SMS OTP)

 SECURID OTP is added to the list of methods from the required assurance level or higher and that list is returned to the client.