Evaluating Assurance Levels and Primary Authentication Status to Return Authentication Methods

Document created by RSA Information Design and Development on Apr 14, 2017Last modified by RSA Information Design and Development on Nov 16, 2018
Version 18Show Document
  • View in full screen mode

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 RSA SecurID, RSA SecurID Authenticate Tokencode, Approve, Device Biometrics, SMS Tokencode, or Voice Tokencode.

    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. RSA SecurID Access 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 Token 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/docs/DOC-53965.

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 LevelMethods Defined for That LevelDefault
(Last Successful Authentication Method)
Methods Returned to the Client Plus Higher Levels
HIGH

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

(SECURID AND DEVICE BIOMETRICS)

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

MEDIUM

(DEVICE BIOMETRICS) OR (SMS TOKENCODE)

(SMS TOKENCODE)

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

MEDIUM

(DEVICE BIOMETRICS) OR (SMS TOKENCODE)

(SECURID AND APPROVE)

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

LOW(APPROVE) OR (AUTHENTICATE TOKENCODE)(AUTHENTICATE TOKENCODE)

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

LOW(APPROVE) OR (AUTHENTICATE TOKENCODE)

(DEVICE BIOMETRICS)

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

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

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

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

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

MEDIUM

(DEVICE BIOMETRICS) OR (SMS TOKENCODE)

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

LOW(APPROVE)

(APPROVE) OR (DEVICE BIOMETRICS) OR (SMS TOKENCODE)

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

                   
Original Methods List Containing DuplicatesMethods List After Duplicate Removal

(SECURID AND TOKEN) OR (SECURID AND SMS TOKENCODE) OR (TOKEN)

(SECURID AND SMS TOKENCODE) OR (TOKEN)

(SECURID AND APPROVE) OR (SECURID 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 AND APPROVE).

                            
Server ActionServer Returns These Access Policy Methods to ClientExplanation
No primary authentication.

(DEVICE BIOMETRICS) OR (SECURID AND APPROVE)

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

(DEVICE BIOMETRICS) OR (SECURID 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 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 AND APPROVE) OR (SMS TOKENCODE).

                             
Server ActionServer Returns These Access Policy Methods to ClientExplanation
No primary authentication.

(SECURID AND APPROVE) OR (SMS TOKENCODE)

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

(APPROVE) OR (SMS TOKENCODE)

SECURID 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 as primary method

(SECURID AND APPROVE) OR (SECURID AND SMS TOKENCODE)

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

 

 

You are here
Table of Contents > Assurance Levels > Evaluating Assurance Levels and Primary Authentication Status for Returning Authentication Methods

Attachments

    Outcomes