High-Level Authentication Flows for Cloud Access Service
a month ago

High-Level Authentication Flows for Cloud Access Service

This topic describes:

High-Level Authentication Flows for Relying Parties

The following sections illustrate how Cloud Access Service (CAS) authenticates a user for a relying party. A relying party is one of the following third-party SSO solutions or web applications:

  • A service provider, using SAML 2.0
  • Microsoft Azure Active Directory, using OpenID Connect (OIDC)

Relying parties use CAS as the Authorization Server or the identity provider (IdP) for managing authentication.

For service providers, CAS can manage only additional (step-up) authentication or both primary authentication (for example, user ID and password) and additional authentication. For Azure Active Directory, CAS can manage only additional authentication.

Example: Relying Party Primary Authentication and CAS Additional Authentication

ngx_c_relyingparty_primary_auth_750x450

In this example, a SAML service provider manages primary authentication and CAS manages additional authentication. The administrator has configured an additional access policy that requires Approve or Authenticate OTP.

  1. The user enters sign-in credentials (for example, user ID and password) to access App A (the SP).
  2. The SP confirms the user's credentials and sends an additional authentication request to CAS.
  3. CAS sends just-in-time (JIT) synchronization request to the identity router.
  4. The just-in-time (JIT) update/create request is processed to synchronize the users from LDAP to the Cloud database.
  5. The identity router sends the user response to CAS.
  6. CAS determines the additional authentication policy to use and prompts the user for additional authentication (Approve or Authenticate OTP).
  7. The user completes the Approve authentication method.
  8. CAS verifies the Approve.
  9. CAS notifies the SP that authentication for the user ID succeeded.
  10. The user accesses App A.

Example: CAS Primary and Additional Authentication

Primary_and_ Additional_Authentication_750x450

In this example, CAS manages both primary and additional authentication for Apps A and B. For both applications, the administrator has configured SecurID OTP as the primary authentication method and has selected an access policy for additional authentication with a Medium assurance level of SecurID OTP and Approve.

  1. The user tries to access App A (the SP).
  2. The SP sends the user's authentication request to CAS.
  3. CAS determines that both primary and additional authentication are required, determines the configured primary authentication method and the access policy for additional authentication, and prompts the user for primary authentication.
  4. The user enters user ID and SecurID OTP.
  5. CAS sends just-in-time (JIT) synchronization request to the identity router.
  6. The just-in-time (JIT) update/create request is processed to synchronize the users from LDAP to the Cloud database.
  7. The identity router sends the user response to CAS.
  8. CAS verifies the primary authentication.

  9. CAS prompts the user to complete the Approve authentication method.

    The assurance level requires SecurID OTP and Approve but because the user completed SecurID OTP authentication as part of primary authentication, CAS only prompts the user for Approve for additional authentication.

  10. The user completes the Approve authentication method.
  11. CAS verifies the additional authentication.
  12. CAS notifies the SP that authentication for the user ID succeeded.
  13. The user accesses App A.
  14. The user tries to access App B (another SP).
  15. Steps 2- 9 are repeated.
  16. The user accesses App B.

High-Level Authentication Flow for RADIUS for CAS

Note:  All identity router platforms support RADIUS authentication, except when the identity router is embedded in Authentication Manager 8.5 or later.

When you protect your network with RADIUS for CAS, the authentication process works as follows:

  1. The user provides authentication information to a RADIUS client, such as a VPN server or firewall.
  2. The RADIUS client sends an Access-Request message to a RADIUS server hosted on an identity router in your deployment. The request provides information about the client and the user, such as:
    • User ID
    • User password (encrypted)
    • Client ID
    • Port ID
  3. The RADIUS server validates the client using a password shared between the client and server, known as a shared secret. If the client does not provide the correct shared secret, authentication is not possible.
  4. The RADIUS server checks requirements (known as checklist attributes) that must be met for the user to access the resource. Checklist attributes may include:
    • Password
    • Clients through which the user can access a resource
    • Ports on which the user can access
  5. The RADIUS server forwards the request to CAS.
  6. CAS sends the just-in-time (JIT) user synchronization request to the identity router to ensure that the user is active.
  7. The RADIUS server sends one of three responses to the client:
    • Access-Accept. The RADIUS server allows access and returns a set of attributes (known as return list attributes) to the client for session control.
    • Access-Challenge. The RADIUS server returns the additional (step-up) authentication methods the user must satisfy, such as Approve, Authenticate OTP, or SecurID OTP.
    • Access-Reject. Authentication methods or policy conditions are not satisfied, so access is denied.
  8. When authentication succeeds, the RADIUS server sends return list attributes to the client to manage the user session.

RADIUS clients control user access at the network perimeter. The following figure shows how a RADIUS server runs as a service on an identity router and connects to RADIUS clients and other components in a typical deployment.

securid_radiussystem (1)

High-Level Authentication Flows for the IDR SSO Agent

The following sections illustrate how RSA authenticates a user for applications in a deployment with an IDR SSO Agent. The process flow depends on the following factors:

  • If the application requires additional (step-up) authentication after the user accesses the application portal.
  • If the user has recently authenticated to another application with similar authentication requirements.

In these examples, the user accesses the applications through the RSA Application Portal. Depending on your configuration, users can also access the applications through a custom portal or other methods (for example, a bookmark or using the application URL).

Note:  All identity router platforms support the IDR SSO Agent, except when the identity router is embedded in Authentication Manager 8.5 or later.

Authentication Flow without Additional Authentication Example

ngx_g_flow_nostepup_577x381

In this example, the company is using the RSA Application Portal. The administrator has assigned an access policy to App A that does not require additional (step-up) authentication.

  1. The user enters sign-in credentials to access the RSA Application Portal. Or, if the administrator has configured Integrated Windows Authentication (IWA), the user navigates to the portal URL and is automatically signed into the portal.
  2. The identity router checks the identity source to confirm the user's credentials and checks the access policies for all applications available to the user.
  3. The user is signed into the portal.
  4. The user clicks the App A icon to open an app.
  5. The identity router enforces the access policy for the application, which does not require the user to complete additional authentication.
  6. The identity router sends the access request to App A.
  7. The identity router opens App A in a new browser tab.
  8. The user accesses App A.

Authentication Flow with Additional Authentication and Single Sign-On Example

ngx_g_flow_stepup_573x458

In this example, the company is using the RSA Application Portal. The administrator has assigned an access policy that uses the Low assurance level to App B and App C. (An assurance level defines the authentication methods required to access applications during additional authentication.)

  1. The user enters sign-in credentials to access the RSA Application Portal. Or, if the administrator has configured IWA, the user navigates to the portal URL and is automatically signed in to the portal.
  2. The identity router checks with the identity source to confirm the user's credentials and checks the access policies for all applications available to the user.
  3. The user is signed into the portal.
  4. The user clicks the App B icon to open the app.
  5. The identity router enforces the access policy for App B. App B requires additional authentication using the Low assurance level (Approve authentication method).
  6. Because additional authentication is required, the identity router sends the request to CAS.
  7. In a new browser tab, SecurID provides instructions in the browser for the user to follow and sends a notification to the SecurID Authenticate.
  8. The user taps Approve in the Authenticator to complete authentication.
  9. The Authenticator sends the response to CAS.
  10. CAS sends the authentication status to the identity router.
  11. The identity router sends the access request to App B.
  12. The identity router opens App B.
  13. The user accesses App B.
  14. In the application portal, the user clicks the App C icon to open the app.
  15. The identity router enforces the access policy for App C. App C also uses the Low assurance level. Because the user's session is still active from authenticating to App B (which uses the same assurance level as App C), the user does not need to provide the additional authentication required by App C.
  16. The identity router sends the access request to App C.
  17. In a new browser tab, SecurID opens App C.
  18. The user accesses App C.

 

Related Articles

Trending Articles

Don't see what you're looking for?