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 Azure Active Directory, using OpenID Connect (OIDC)
  • Generic OIDC
  • Epic Hyperdrive

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

For service providers and generic OIDC applications, 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

SecurID 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.

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.

securid_ngx_g_saml_cloud_idp.png

  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

SecurID supports Azure Active Directory with the Conditional Access Extensibility feature as a relying party. Download the configuration guide in SecurID 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.

securid_ngx_g_flow_azure_ad.png

  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.

OIDC Relying Party

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

Authentication Workflow

The Cloud Authentication Service supports the generic OIDC flow.

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

securid_ngx_g_generic_oidc_flow.png

  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 Cloud Authentication Service.

  4. Cloud Authentication Service verifies relying party settings.

  5. Cloud Authentication Service redirects the user to authentication based on the defined policy.

  6. User performs the primary/secondary authentication.

  7. Cloud Authentication Service 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

The Cloud Authentication Service 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 the Cloud Authentication Service, 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.