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 7Show Document
  • View in full screen mode

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.

The provider that manages primary authentication method is responsible for checking for disabled user accounts and expired credentials.

Service Providers

RSA SecurID Access supports the following applications as service providers:

SAML Metadata

SAML metadata is one of the standard means by which SAML-enabled SPs and IdPs exchange configuration information and establish two-way trust. When configuring a connection between the SAML-enabled application and the Cloud Authentication Service, you can import SAML metadata from the SP to prepopulate SP-related fields in the configuration wizard, if the SP supports metadata export. After saving a service provider configuration, you can export the SAML IdP metadata from the Service Providers page, and send it to the SP administrator.

Certificates and Keys

You can use public key certificates and private keys to help secure transactions carried out between the SP and the IdP. You use the Cloud Administration Console to manage certificates between the IdP and SP.

The SP can sign the SAML requests that it sends to the IdP, but the signature is not required. If the SP signs the requests, when you configure the SP in the Cloud Administration Console, you upload the certificate that the IdP uses to validate the request signature. The SP certificate does not need to be signed by a Certificate Authority.

The SAML IdP for the Cloud Authentication Service has its own certificate and always signs the SAML assertions. The IdP uses the same private key and certificate for all SPs. You can download the IdP certificate to validate the signature when you configure the SP or when you view the metadata. You cannot download the private key.

SP-Initiated Authentication Workflow

The Cloud Authentication Service supports the SP-initiated workflow. This workflow conforms to the SAML 2.0 Web Browser SSO Profile. The SAML IdP for Cloud Authentication Service does not support SSO within or across service providers. For example, if an administrator adds a third-party application portal as a service provider, when a user authenticates to that application portal the user still needs to authenticate to applications within the portal.

This example workflow assumes that the IdP is managing both primary and additional authentication.

  1. The user tries to access the protected, SAML-enabled application (the SP).
  2. The SP generates a SAML request and sends it, through the browser, to the Cloud Authentication Service.
  3. The Cloud Authentication Service receives the SAML request.
  4. The Cloud Authentication Service determines that both primary and additional authentication are required, determines the access policy for additional authentication, and sends a response to the browser to start authentication.
  5. The browser prompts the user for user ID and password.

    Depending on the SP requirements, the user can enter either a user ID or email address.

  6. The user enters primary authentication, for example, user ID and password.
  7. The browser sends the credentials to the Cloud Authentication Service.
  8. The Cloud Authentication Service verifies the primary authentication credentials and sends a response to browser prompt the user for additional authentication.
  9. The browser prompts the user for additional authentication, for example, Approve.
  10. The user completes additional authentication.
  11. The browser or device sends the additional authentication credentials to the Cloud Authentication Service.
  12. The Cloud Authentication Service verifies additional authentication.
  13. The Cloud Authentication Service generates a response that contains the SAML assertion and redirects the user’s browser to the SP’s ACS URL along with the SAML response.
  14. The SP validates the assertion in the SAML response.
  15. The user can access the protected application.

Microsoft Azure Active Directory

RSA SecurID Access supports Azure Active Directory with the Conditional Access Extensibility feature as a relying party. Download the configuration guide in RSA SecurID Access Integrations (https://community.rsa.com/community/products/securid/securid-access/integrations) in the SSO Agents category.

Metadata and Keys

Azure Active Directory and the Cloud Authentication Service use metadata to exchange configuration information and establish two-way trust. Azure Active Directory and the Cloud Authentication Service automatically discover configuration information. For example, Azure Active Directory gets the Cloud Authentication Service configuration metadata and keys at runtime using the Authorization Server Issuer URL.

Authentication Workflow

The Cloud Authentication Service supports the OpenID Connect (OIDC) Implicit flow for Azure Active Directory.

The following example workflow describes how the authentication process works with Azure Active Directory and the Cloud Authentication Service.

  1. The user tries to access an application protected by Azure Active Directory.
  2. Azure Active Directory prompts the user for primary authentication (user ID and password).
  3. The user enters credentials for primary authentication.
  4. Azure Active Directory verifies the primary authentication credentials.
  5. Based on an Azure Active Directory conditional access policy, Azure Active Directory sends an authentication request to the Cloud Authentication Service (the Authorization Server) for additional authentication.
  6. The Cloud Authentication Service receives the request.
  7. The Cloud Authentication Service determines the Cloud Authentication Service access policy for additional authentication and sends a response to the browser to prompt the user for additional authentication.
  8. The browser prompts the user for additional authentication, for example, Approve.
  9. The user completes additional authentication.
  10. The browser or device sends the additional authentication credentials to the Cloud Authentication Service.
  11. The Cloud Authentication Service verifies additional authentication.
  12. The Cloud Authentication Service sends the ID Token to Azure Active Directory.
  13. Azure Active Directory validates the ID Token.
  14. The user can access the protected application.

 

 

Previous Topic:Manage Access Policies
You are here
Table of Contents > Relying Parties > Relying Parties

Attachments

    Outcomes