Relying Parties

Document created by RSA Information Design and Development on Apr 14, 2017Last modified by RSA Information Design and Development on Sep 15, 2017
Version 4Show Document
  • View in full screen mode

A relying party is a service provider (a third-party SSO solution or web application) that uses SAML 2.0.

The service provider can manage primary authentication (for example, user ID and password) and use the Cloud Authentication Service for additional authentication, or the service provider can use the Cloud Authentication Service for both primary and 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.

 

 

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

Attachments

    Outcomes