Introduction to SAML 2.0
| You configure and set up SAML 2.0 under Native Consoles > Access Management. |
SAML 2.0 helps organizations share, or federate identities and services, without having to manage the identities or credentials themselves. The credentials are managed by a single entity, known as the identity provider (IdP). The services are provided by service providers (SP). Both providers are configured to trust one another.
Advanced Identity Cloud can serve as the IdP for an SP or it can be the SP for an external IdP (such as Azure AD).
Advanced Identity Cloud uses the concept of the circle of trust to manage the relationship between IdPs and SPs.
SAML 2.0 concepts
Security Assertion Markup Language (SAML) 2.0 is a standard that lets users access multiple services using only a single set of credentials. The services can be provided by different organizations, using multiple domains. In summary, SAML 2.0 provides cross-domain single sign-on (CDSSO).
| Term | Description |
|---|---|
End user |
The person who is attempting to access the resource or application. In SAML 2.0, the end user is often referred to as the subject. The end user uses a user-agent, usually a web-browser, when performing a SAML 2.0 flow. |
Single sign-on (SSO) |
The ability for an end user to authenticate once but gain access to multiple applications, without having to authenticate separately to each one. |
Single log out (SLO) |
The ability for an end user to log out once but terminate sessions in multiple applications, without having to log out separately from each one. |
Assertions |
An assertion is a set of statements about an authenticated user that let services make authorization decisions, that is, whether to allow that user to access the service and what functionality they can use. SAML assertions are XML-formatted tokens. Assertions issued by Advanced Identity Cloud can contain the following information about an end user:
|
Identity provider (IdP) |
The IdP is responsible for authenticating end users, managing their account, and issuing SAML assertions about them. |
Service provider (SP) |
The provider of the service or application that the end user is trying to access. The SP has a trust relationship with the IdP, which enables the SP to rely on the assertions it receives from the IdP. |
Circle of trust (CoT) |
A circle of trust is an Advanced Identity Cloud concept that groups at least one IdP and at least one SP who agree to share authentication information. |
Metadata |
Providers in SAML 2.0 share metadata, which represents the configuration of the provider, as well as the mechanisms it can use to communicate with other providers. For example, the metadata may contain necessary certificates for signing verification, as well as which of the SAML 2.0 bindings are supported. Sharing metadata greatly simplifies the creation of SAML 2.0 providers in a circle of trust. Advanced Identity Cloud can import the XML-formatted metadata provided by other providers, which are referred to as remote providers. You can also export the metadata from providers created in your tenant, referred to as hosted providers. For more information about metadata, refer to Metadata for the OASIS Security Assertion Markup Language (SAML) V2.0 in the SAML 2.0 Standard. |
For more information, refer to Security Assertion Markup Language (SAML) 2.0.
SAML 2.0 depends on standards for describing how the providers interact and exchange information. The SAML 2.0 standards describe the messages sent between providers, how they are relayed, how they are exchanged, and common use cases.
When configuring Advanced Identity Cloud to provide single sign-on using SAML 2.0, you can:
-
Map accounts from the IdP to accounts in the SP, including mapping to an anonymous user.
-
Make assertions as the IdP to the SP, for example, to attest that the end user has authenticated with the IdP.
The SP then consumes assertions from the IdP to make authorization decisions, for example to let an authenticated user complete a purchase that gets charged to the user’s account at the IdP.
SAML 2.0 example flow
-
An unauthenticated user attempts to access a SAML 2.0 SP.
-
The SP determines the IdP associated with the end user, and redirects the user’s browser to the IdP, using an HTTP 302 Redirect message. A SAML 2.0 authentication request is included in the query string.
This is an example of HTTP-Redirect binding, and is the default when requesting SAML authentication by Advanced Identity Cloud. Advanced Identity Cloud also supports the HTTP-POST binding for processing SAML 2.0 authentication requests.
Advanced Identity Cloud provides two deployment models to support single sign-on (SSO) when contacting the SP initially. For details, refer to Implement SSO and SLO.
-
The IdP validates the request, determines the authentication method that should be used, and authenticates the user.
The SP can include particular authentication requirements in the request, for example, to require the user to use multi-factor authentication.
-
The IdP creates a SAML Artifact, which contains a unique artifact ID for the SAML 2.0 response.
The IdP redirects the end user’s browser to the SP, and includes the SAML Artifact in the query parameters.
The browser only has access to the artifact ID rather than the SAML response itself, reducing risk of malicious interference. -
The SP communicates directly with the IdP, using the SOAP protocol, to retrieve the SAML response relating to the artifact ID.
The IdP returns the SAML response, including the assertion, using the SOAP protocol, directly to the SP.
The information in the SAML response is not shared with the user agent. This is an example of HTTP-Artifact binding, and is the default when Advanced Identity Cloud is returning SAML assertions. Advanced Identity Cloud also supports the HTTP-POST binding for transmitting SAML 2.0 assertions.
-
The SP validates the SAML response and that the signature matches the public key it holds for the IdP.
Optionally, the SP can choose to create a new account locally for the user, or associate an identifier in the assertion with a user account it already has locally. Linked accounts are often referred to as a federated identity. For more information, refer to Federate identities.
To link to an existing account, the SP might also need the end user to authenticate to the SP itself, to determine the matching local account. When the accounts are linked, the user only needs to authenticate to the IdP when requesting access. -
The SP can now use the information provided in the assertion, and any details in the local federated identity, to authorize the user, and decide whether to provide its services to the end user.
Use case: Let staff access Google Workspace
A common use case for SAML 2.0 is to let your internal staff access and use the applications provided by Google Workspace, such as Google Docs and Google Sheets. This section highlights how Advanced Identity Cloud provides the solution.
In this scenario, Google acts as the SP, and Advanced Identity Cloud acts as the IdP for a hypothetical organization, Example.com.
High-level steps to let staff access Google Workspace applications
-
An administrative user configures Advanced Identity Cloud as the IdP as a custom application.
-
The administrative user configures Google Workspace as a remote SP and provides the values that Google needs to use Advanced Identity Cloud as its IdP. For example, the login, logout, and profile management URLs, and the validation certificate.
-
The Google Workspace administrator enters the provided URLs and certificate into the Google Workspace Admin console for the domain being configured.
-
When the configuration is complete, users attempting to access a Google Workspace service are asked for their corporate email address:
-
Based on the domain of the email address, Google redirects the user to sign in to Advanced Identity Cloud, acting as the IdP:
-
After successfully authenticating with Advanced Identity Cloud the user is redirected back to the Google Workspace application, for example, Google Docs.
Google, acting as the SP, creates a federated identity in its systems to manage local account options, such as privacy settings. The user can now access any of the Google Workspace apps, by authenticating to Advanced Identity Cloud using their corporate Example.com account:
