SAML 2.0: How It Works

SAML is XML based, which makes it extremely flexible. Two federation partners can choose to share whatever identity attributes they want in a SAML assertion (aka message) payload as long as those attributes can be represented in XML. This flexibility led to pieces of the SAML standard, such as the SAML assertion format, being incorporated into other standards including WS-Federation.

Interoperability also gives SAML a huge advantage over proprietary SSO mechanisms. For an enterprise, proprietary SSO means each new connection potentially requires a new and different software implementation or proprietary integration connectors. With SAML, a single implementation can support SSO connections with many different federation partners. Some large organizations, particularly those who have already gone through the pain of supporting multiple proprietary SSO implementations, now require the use of SAML for internet SSO with identity as a service (IDaaS) applications and other external service providers.
 
The Kantara Initiative established a very successful interoperability testing program where SAML vendors prove out-of-the-box interoperability with other SAML implementations. Ping’s own enterprise federation server, PingFederate, has been extensively tested for interoperability against a number of other SAML implementations, both in formal interop testing and through many years of real world usage by some of the world’s largest companies A certified product can mean the difference between a simple two-hour configuration and testing exercise vs. a multi-month distributed debugging nightmare.

There are two common usage scenarios for SAML. The first is IdP-initiated SSO, and the second is SP-initiated SSO.

IdP-initiated SSO with SAML Authentication

IdP-initiated SSO is commonly found in workforce SSO solutions, such as PingOne for Enterprise. In this scenario, users first log in to the system, which presents an application catalog. This catalog will contain visual icons of all the internal and external applications that the company has configured SSO for and that the user has privileges to access.

The most frequently used applications are typically sorted to the top for quick access. Here’s what this looks like in PingOne for Enterprise:

When the user clicks on one of the images, the SAML flow is as follows:    

• The SAML IdP takes the user’s identity, along with any other attributes that the two sides have agreed to communicate.
• It builds an XML-based SAML assertion.
• It signs the assertion with the private key of a public/private keypair that was exchanged between the IdP and SP when the SSO partnership was configured.
• It then either sends the assertion to the SP via the user’s browser or sends a reference to the assertion that the SP can use to securely retrieve the assertion.
   

Once the SP has received the SAML assertion, it validates the signature using the public key in order to ensure the SAML assertion really came from its trusted IdP and that none of the values in the assertion have been modified. The SP can then extract the identity of the user from the SAML assertion along with any other attributes it needs. At this point, the user is on the service provider’s landing page, just as though they had logged into the site manually.

This diagram illustrates the steps in an IdP-initiated SSO flow with SAML:
 

SP-initiated SSO with SAML Authentication

SP-initiated SSO starts when a user tries to access a resource at the service provider, but hasn’t yet authenticated to the SP. A user may have gone directly to the website or may have saved a link to a specific resource at the SP. Once the SP sees that the user doesn’t have an active session, it will redirect them to the IdP to be authenticated. The IdP will authenticate the user, create the assertion and redirect the user back to the SP just as in the IdP-initiated use case, with the addition that it will also send back the URL of the resource that the user was initially trying to access, if it was provided by the SP.

You may be wondering how the SP knows which IdP to redirect the user to if it supports SSO from more than a single IdP. The answer is that it depends. A few common ways the SP can determine which IDP to redirect the user to are:

• The SP may ask the user for their email address and use the domain of the email, such as bill@pingidentity.com, to determine which IdP to use.
• The SP may display a list of IdPs it supports and ask the user to choose the appropriate one.
• The resource URL may be specific to one IdP.
• The SP may have placed a cookie containing IdP information in the user’s browser the first time the user successfully signed on from the IDP and will use this information on subsequent accesses.
   

Once the SP has received the SAML assertion, it validates the signature using the public key in order to ensure the SAML assertion really came from its trusted IdP and that none of the values in the assertion have been modified. The SP can then extract the identity of the user from the SAML assertion along with any other attributes it needs. At this point, the user is on the service provider’s landing page, just as though they had logged into the site manually.


This diagram illustrates the steps in an SP-initiated SSO flow with SAML: