Relying Parties
a month ago

Relying Parties

Relying party is an entity that relies upon the user’s credentials, typically to process a transaction or grant access to information or a system. A relying party is one of the following third-party SSO solutions or web applications:

  • A service provider, using SAML 2.0

  • Microsoft Entra ID

  • Generic OIDC

  • Epic Hyperdrive

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

For service providers and generic OIDC applications, CAS can manage only additional authentication or both primary authentication (for example, user ID and password) and additional authentication. For Microsoft Entra ID, CAS 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 supports the following applications as service providers:

  • Applications with a configuration guide in RSA Link in Integrations in the Cloud Identity Provider category.

  • An application that meets the required SAML 2.0 criteria identified in SAML 2.0 Requirements for Service Providers

    For information on adding these types of applications, provide the following information to your application administrators:

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 CAS, 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.

SP-Initiated Authentication Workflow

CAS supports the SP-initiated workflow. This workflow conforms to the SAML 2.0 Web Browser SSO Profile. The SAML IdP for CAS 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.

ngx_g_saml_cloud_idp

  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 CAS.
  3. CAS receives the SAML request.
  4. CAS 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 CAS.
  8. CAS 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 CAS.
  12. CAS verifies additional authentication.
  13. CAS 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 Entra ID

RSA supports Microsoft Entra ID with the Conditional Access Extensibility feature as a relying party. Download the configuration guide in RSA Ready Integrations in the SSO Agents category.

Metadata and Keys

Microsoft Entra ID and CAS use metadata to exchange configuration information and establish two-way trust. Microsoft Entra ID and CAS automatically discover configuration information. For example, Microsoft Entra ID gets CAS configuration metadata and keys at runtime using the Authorization Server Issuer URL.

Authentication Workflow

CAS supports the OpenID Connect (OIDC) Implicit flow for Microsoft Entra ID.

The following example workflow describes how the authentication process works with Microsoft Entra ID and CAS.

ngx_g_flow_entraid_ad

  1. The user tries to access an application protected by Microsoft Entra ID.
  2. Microsoft Entra ID prompts the user for primary authentication (user ID and password).
  3. The user enters credentials for primary authentication.
  4. Microsoft Entra ID verifies the primary authentication credentials.
  5. Based on an Microsoft Entra ID conditional access policy, Microsoft Entra ID sends an authentication request to CAS (the Authorization Server) for additional authentication.
  6. CAS receives the request.
  7. CAS determines the CAS 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 CAS.
  11. CAS verifies additional authentication.
  12. CAS sends the ID Token to Microsoft Entra ID.
  13. Microsoft Entra ID validates the ID Token.
  14. The user can access the protected application.

OIDC Relying Party

CAS can act as the authorization server for a generic OpenID Connect (OIDC) relying party application.

Authentication Workflow

CAS supports the generic OIDC flow.

The following example workflow describes how the authentication process works with generic OIDC relying party and CAS.

ngx_g_generic_oidc_flow

  1. User loads relying party website/GET.

  2. User tries to log in to the relying party.

  3. The relying party redirects the user to CAS.

  4. CAS verifies relying party settings.

  5. CAS redirects the user to authentication based on the defined policy.

  6. User performs the primary/secondary authentication.

  7. CAS redirects the user to the relying party with the authentication code.

  8. The relying party fetches accessToken, idToken, and then userInfo, if required.

  9. The relying party redirects user to the browser with the relying party session.

  10. User is logged in to the relying party.

Epic Hyperdrive

CAS can act as the authorization server for the Epic Hyperdrive relying party. RSA has developed a new standard Agent to secure the new Epic Hyperdrive login and workflows. RSA Authentication Agent for Epic Hyperdrive, built on REST based protocol, provides stronger multi-factor authentication options to Epic Hyperdrive users. You need to deploy this new Agent for the Epic Hyperdrive to secure login and/or workflow that requires step-up authentication. When users try to log in or approve a workflow in the Epic Hyperdrive, the Authentication Agent communicates with the Authentication Manager to manage the authentication. For the Agent to communicate with CAS, you need to Add Epic Hyperdrive Relying Party .

For information on the installation and administration of the RSA Authentication Agent for Epic Hyperdrive, see Authentication Agent for Epic Hyperdrive Documentation.

Don't see what you're looking for?