8.1 Understanding SAML

SAML 2.0 is an open-source industry-standard XML-based protocol that allows you to create a federated, secure connection between two providers to enable web-based, single sign-on for your users. Enabling single sign-on for the users of your organization reduces the administrative overhead of distributing multiple authentication tokens to the users.

SAML supports two different flows for authentication: identity provider (IdP)-initiated and service provider (SP)-initiated authentications. Single Sign-on support both authentication flows.

8.1.1 SAML Components

SAML 2.0 is an open-source industry-standard XML-based protocol that allows you to create a federated, secure connection between two providers to enable web-based, single sign-on for your users. Federation is a practice that allows user identities to be stored across discrete services and organizations. SAML allows these federated services and organizations to communicate with and trust one another’s users.

SAML uses security tokens containing assertions to pass information about a principal (usually an end user) between an identity provider and a service provider. SAML is a two-way communication channel. You must configure both security domains to trust each other and allow single sign-on to occur. The following graphic and information provide more details about SAML 2.0.

Figure 8-1 SAML Components

The graphic lists the different components involved in permitting the transfer of identity, authentication, attribute, and authorization information between autonomous organizations that have an established trust relationship.

Principal

A principal is an entity that a computer system or network can authenticate. A principal is usually a user, but it can also be a group, computers, services, computational entities such as processes and threads, or any group of such things.

Identity Provider

An identity provider (IdP) is a service that creates, manages, and maintains the identity information about the principals and provides authentication services to services within a federation or a distributed network that rely on that identity information.

Service Provider

A service provider (SP) is an organization that provides services to your organization. It can be a separate division in an organization, a software-as-a-service provider, a third-party organization, or any such entity. The service providers either host or provide the applications and services to different organizations.

Security Domain

A security domain is a separate network of computers. Each security domain uses firewalls and other such tools to separate the information and resources on the network separate from other networks for security reasons.

SAML Core Components

The following items are the core components that allow SAML to provide secure, single sign-on between two different security domains.

Metadata

Metadata defines a way to express and share configuration information between two security domains. For example, the metadata could contain the identity provider information, the service provider information, supporting identity attributes, and key information for encryption and signing. You configure the metadata between two security domains to allow a secure, web-based, single sign-on experience for the users. SAML Metadata is defined by its XML schema. You must configure each security domain with the metadata information for each identity provider and service provider.

Profiles

SAML profiles exist to satisfy a particular business use case, such as the Web Browser SSO profile. Profiles typically define constraints on the contents of SAML assertions, protocols, and bindings to solve the business use case in an interoperable fashion. There are also Attribute Profiles, which do not refer to any protocol messages and bindings, that define how to exchange attribute information using assertions in ways that align with several common usage environments such as X.500/LDAP directories or DCE.

Bindings

SAML bindings transport SAML protocol messages between the participants through lower-level communication or messaging protocols (such as HTTP or SOAP).

Protocols

SAML protocol messages make the SAML-defined requests and return appropriate responses. The SAML-defined protocol XML schema defines the structure and contents of these messages.

Assertions

SAML assertions carry statements about a principal that an asserting party claims to be true. The SAML assertion XML schema defines the valid structure and contents of an assertion. An asserting party usually creates assertions based on a request of some sort from a relying party, although, under certain circumstances, the asserting party delivers the assertions in an unsolicited manner to the party that relies on them.

8.1.2 Example of an IdP-Initiated Authentication with Single Sign-on

Figure 8-2 is an example of the single sign-on IdP-initiated authentication process for a user named Maria Belafonte to Google Mail. Maria’s company is named Extremely Focused. Maria starts the authentication process by selecting an appmark in the Application Portal for Google Mail.

There are configuration steps that you must perform to create a federation between Single Sign-on and Google Mail. Federation is a practice that allows user identities to be stored across discrete services and organizations. SAML allows these federated services and organizations to communicate with and trust one another’s users. You must create the federation between Single Sign-on and Google Mail before the SAML single sign-on authentication process functions. The configuration steps for the federation are the same for IdP-initiated and SP-initiated authentications. The required configuration steps are:

  • Share metadata: You must add the metadata for Google Mail to Single Sign-on and you must add the metadata for Single Sign-on to Google Mail. This step allows each domain to know about and trust the other domain to allow authentications. The metadata can include certificates to create a secure trust between the two security domains.

  • Create an account in the identity repository: Create an account for Maria Belafonte in the identity repository for Single Sign-on. You must add the users to whom you want to provide a single sign-on experience in the identity repository. This step allows Single Sign-on to know about and obtain the required information to create the single sign-on experience.

  • Create an account in Google Mail: Create an account for Maria Belafonte in Google Mail. Not all security domains that use SAML require that the entity accounts exist in their system but Google Mail does.

Figure 8-2 and the steps explain the IdP-initiated authentication process that occurs after you have configured Single Sign-on and Google Mail to allow single sign-on authentication. Maria's experience as a user is simply to log in to her company's website and select the appmark for Google Mail. Single Sign-on does not expose the steps required to perform the SAML IdP-initiated authentication to Google Mail to any users.

Figure 8-2 SAML IdP-InitiatedAuthentication with Single Sign-on to Google Mail

Single Sign-on IdP-initiated authentication to Google Mail using SAML 2.0:

  1. Maria Belafonte logs in to her company’s website www.extremelyfocused.com.

  2. Maria selects the link in a browser for her company’s Google Mail and the browser sends the authentication request to Single Sign-on.

  3. Single Sign-on performs a lookup of Maria’s information for the SAML attributes defined for her account.

  4. Single Sign-on creates a SAML artifact that contains Maria’s information.

  5. Single Sign-on sends the SAML artifact that contains Maria’s information and an HTTP Redirect back to the browser.

  6. When the HTTP Redirect reaches the browser, it sends the authentication request to Google Mail.

  7. Google Mail sends a request to Single Sign-on for the SAML assertion to validate that Maria has the proper permissions to authenticate to Google Mail.

  8. Single Sign-on generates a SAML assertion for Maria with the artifact and Maria’s information, then Single Sign-on sends the assertion back to Google Mail for Maria.

  9. Google Mail sees that Maria’s information in the SAML assertion allows her access to Google Mail for her company. Google Mail establishes an authentication session for Maria.

8.1.3 Example of an SP-Initiated Authentication with Single Sign-on

Figure 8-3 is an example of the single sign-on SP-initiated authentication process for a user named Maria Belafonte to Google Mail. Maria’s company is named Extremely Focused. Maria starts the SP-initiated authentication process by selecting a link for the URL to Google Mail in her browser.

There are configuration steps that you must perform to create a federation between Single Sign-on and Google Mail. Federation is a practice that allows user identities to be stored across discrete services and organizations. SAML allows these federated services and organizations to communicate with and trust one another’s users. You must create the federation between Single Sign-on and Google Mail before the SAML single sign-on authentication process functions. The configuration steps for the federation are the same for IdP-initiated and SP-initiated authentications. The required configuration steps are:

  • Share metadata: You must add the metadata for Google Mail to Single Sign-on and you must add the metadata for Single Sign-on to Google Mail. This step allows each domain to know about and trust the other domain to allow authentications. The metadata can include certificates to create a secure trust between the two security domains.

  • Create an account in the identity repository: Create an account for Maria Belafonte in the identity repository for Single Sign-on. You must add the users to whom you want to provide a single sign-on experience in the identity repository. This step allows Single Sign-on to know about and obtain the required information to create the single sign-on experience.

  • Create an account in Google Mail: Create an account for Maria Belafonte in Google Mail. Not all security domains that use SAML require that the entity accounts exist in their system but Google Mail does.

Figure 8-3 and the steps explain the SP-initiated authentication process that occurs after you have configured Single Sign-on and Google Mail to allow single sign-on authentication. Maria Belafonte’s experience as a user is simply to select a link or bookmark for Google Mail. Single Sign-on does not expose the steps required to perform the SAML SP-initiated authentication from Google Mail to Single Sign-on to any users.

Figure 8-3 SAML SP-Initiated Authentication to Google Mail through Single Sign-on

  1. Maria Belafonte enters the URL for Google Mail of www.mail.google.com or selects a bookmark for the URL.

  2. The select in the browser Google workspace initiates login by sending a SAML authentication request to Single Sign-on.

  3. Single Sign-on sends Maria to a login page and she enters her credentials.

  4. Single Sign-on authenticates the Maria searching in the identity repository

  5. Single Sign-on sends cryptographically signed SAML response to Google workspace. The SAML response contains a SAML assertion that tells the service provider who the user is.

  6. The Google workspace validates the signature in the SAML response and identifies the user Maria

  7. Google logs Maria into the Google workspace and she can access her Google mail.