Evaluating Assurance Levels and Primary Authentication Status to Return Authentication Methods

After CAS 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 Levels 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.

  The client might not require primary authentication. If it is required, the server might return different results depending on whether primary verification succeeds. If a 2.0 access policy is used, the server will return the primary authentication methods defined in that policy on Initialize request.

• 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 CAS 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.

If a 2.0 access policy is used, first primary authentication methods are evaluated, and then a user needs to use a method from that list. After successful primary authentication, an assurance level can then be determined and a user can proceed with step-up authentication methods.

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, see Assurance Levels.

Assurance Level Evaluation Steps

When CAS receive an authentication request, it performs the following evaluation:

1. The server checks the assurance level assigned to the client. For 2.0 access policies, the server first checks if a policy requires a primary authentication method and then sets an assurance level. An assurance level is not established until primary authentication is completed.
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 and 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.

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

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

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.
  If a 2.0 access policy is used, then only primary authentication methods are returned. If the client supplied credentials as part of Initialize request, they will be evaluated. If successful, step-up authentication methods will be returned. Otherwise, only primary authentication methods will be returned. For 2.0 access policies, if PASSWORD credentials are sent in the request, the method will be evaluated only if it is one of the primary authentication methods. If PASSWORD method fails, you will return back to the list of primary authentication methods to retry. If PASSWORD method is not part of a 2.0 access policy, then it will not be evaluated, and the caller will get a list of available primary authentication methods to choose a different one. After successful authentication with primary authentication methods, step-up or additional authentication methods will be returned.

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

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. With 1.0 access policies, if validation fails, the server adds the primary method to the list of methods in the assurance level. However, for 2.0 access policies, if validation fails, the server does not add the primary method to the list of methods, and the client will return back a list of primary authentication methods.
   
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).

Scenario: Primary authentication without a user

QR Code authentication method does not require credentials to be provided, and a user can be identified later in the authentication process. For example, scanning the QR code on a device will start the authentication process without the need to manually enter credentials. When any of these methods are initiated, only 'methodId' is sent in the request with no 'subjectCredentials'. The subjectName is optional. The subjectName can be sent, and the value will be validated when the QR Code is validated.