High-Level Authentication Flows for Relying Parties

Document created by RSA Information Design and Development on Apr 14, 2017Last modified by RSA Information Design and Development on Oct 20, 2017
Version 6Show Document
  • View in full screen mode
  

The following sections illustrate how the Cloud Authentication Service 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 the Cloud Authentication Service as the Authorization Server or the identity provider (IdP) for managing authentication.

For service providers, the Cloud Authentication Service can manage only additional authentication or both primary authentication (for example, user ID and password) and additional authentication. For Azure Active Directory, the Cloud Authentication Service can manage only additional authentication.

 

Example: Relying Party Primary Authentication and Cloud Authentication Service Additional Authentication

In this example, a SAML service provider manages primary authentication and the Cloud Authentication Service manages additional authentication. The administrator has configured an additional access policy that requires Approve or Authenticate Tokencode.

  
  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 the Cloud Authentication Service.
  3. The Cloud Authentication Service determines the additional authentication policy to use and prompts the user for additional authentication (Approve or Authenticate Tokencode).
  4. The user completes the Approve authentication method.
  5. The Cloud Authentication Service verifies the Approve.
  6. The Cloud Authentication Service notifies the SP that authentication for the user ID succeeded.
  7. The user accesses App A.
 

Example: Cloud Authentication Service Primary and Additional Authentication

 

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

  1. The user tries to access App A (the SP).
  2. The SP sends the user's authentication request to the Cloud Authentication Service.
  3. The Cloud Authentication Service 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 passcode.
  5. The Cloud Authentication Service verifies the primary authentication.
  6. The Cloud Authentication Service prompts the user to complete the Approve authentication method.

    The assurance level requires RSA SecurID Token and Approve but because the user completed RSA SecurID Token authentication as part of primary authentication, the Cloud Authentication Service only prompts the user for Approve for additional authentication.

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

 

 

You are here
Table of Contents > RSA SecurID Access Product Overview > High-Level Authentication Flows for Relying Parties

Attachments

    Outcomes