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 Joyce Cohen on Nov 17, 2017
Version 8Show 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 in the access policy. 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 access policy determines if additional authentication is required using RSA SecurID, RSA SecurID Authenticate Tokencode, Approve, Device Biometrics, Eyeprint ID, or 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 access policy 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. The SP configuration in the Cloud Administration Console specifies the client's access policy.

 

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

 

Assurance Level Evaluation

 

When the Cloud Authentication Service receives an authentication request, it evaluates the client's access policy 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. Clients that are not configured as relying parties use the assurancePolicyId to identify the access policy.

 

Access policies contain assurance levels, which 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 in the access policy assigned to the client.
  2. The server creates a list containing the challenge methods for the assurance level specified in the policy 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 in Client Access PolicyMethods 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 (EYEPRINT)

(EYEPRINT)

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

MEDIUM

(DEVICE BIOMETRICS) OR (EYEPRINT)

(SECURID AND APPROVE)

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

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

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

LOW(APPROVE) OR (AUTHENTICATE TOKENCODE)

(DEVICE BIOMETRICS)

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

 

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

                            

Assurance Level in Client Access PolicyMethods 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 (EYEPRINT)

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

LOW(APPROVE)

(APPROVE) OR (DEVICE BIOMETRICS) OR (EYEPRINT)

 

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 EYEPRINT) OR (TOKEN)(SECURID AND EYEPRINT) 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: Access policy does not include the primary authentication method

 

When the client's access policy 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 access policy. 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 access policy and returns all methods to the client.

 

The following examples illustrate this behavior. In the following table, the assurance level in the access policy 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 policy.
Password is successfully verified as primary method.

(DEVICE BIOMETRICS) OR (SECURID AND APPROVE)

Returns only methods from the policy.
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 policy.

 

Scenario: Access policy includes the primary authentication method

 

When the client's access policy 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 policy 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 policy.
  3. The server eliminates any redundant methods and returns the remaining methods to the client, which are required to satisfy the policy.

 

The following example illustrates this behavior. In the following table, the assurance level in the access policy specifies (SECURID AND APPROVE) OR (EYEPRINTID).

                             

Server ActionServer Returns These Access Policy Methods to ClientExplanation
No primary authentication.(SECURID AND APPROVE) OR (EYEPRINTID)Returns only methods from the policy.
Successful verification of SECURID as primary method(APPROVE) OR (EYEPRINTID)SECURID is counted as being completed and is removed from the list of methods from the policy and the remaining methods are sent to the client.
Unsuccessful verification of SECURID as primary method(SECURID AND APPROVE) OR (SECURID AND EYEPRINTID)SECURID is added to the list of methods from the policy 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