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.

The user tries to access the protected, SAML-enabled application (the SP).

The SP generates a SAML request and sends it, through the browser, to the Cloud Authentication Service.

The Cloud Authentication Service receives the SAML request.

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.

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.

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.

The Cloud Authentication Service receives the request.

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.

The browser prompts the user for additional authentication, for example, Approve.

The user completes additional authentication.

The browser or device sends the additional authentication credentials to the Cloud Authentication Service.

The Cloud Authentication Service verifies additional authentication.

The Cloud Authentication Service sends the ID Token to Azure Active Directory.