Javascript is actually
a good thing!
Make sure it's turned on
so that pingidentity.com can work properly.
SAML and SAML 2.0 [Tutorial] - How a SAML Assertion Works | Ping Identity

- ARTICLE -

SAML 2.0: How It Works

What is SAML?

Security Assertion Markup Language (SAML) is an open standard that enables single sign-on (SSO). By making a range of resources accessible with just one set of login credentials, you can provide seamless access to resources and eliminate insecure password proliferation.

 

SAML specifically enables identity federation, making it possible for identity providers (IdPs) to seamlessly and securely pass authenticated identities and their attributes to service providers (SPs). SAML holds the dominant position in terms of industry acceptance for federated identity deployments. Not only has it been deployed in hundreds of thousands of cloud SSO connections, but thousands of large enterprises, government agencies and service providers have also selected SAML as their standard protocol for communicating identities across the internet.
SAML, SAML tutorial

Benefits of SAML Authentication


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.

How SAML Authentication Works


Enterprise SAML identity federation use cases generally revolve around sharing identity between an existing identity and access management (IAM) system and web applications. There are two actors in the SAML scenario, the Identity Provider (IdP) who “asserts” the identity of the user and the Service Provider (SP) who consumes the “assertion” and passes the identity information to the application. The interaction between the IAM system and the federation server is called “first mile” integration, while the interaction between the federation server and the application is called “last mile” integration.

SAML Tutorial


For a helpful overview of how SAML works, watch this short SAML tutorial:

 

SAML Examples


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:
 

Learn More about SAML and How it Works

Standards like SAML are necessary for implementing scalable, secure federated identity across organizations. To learn more about identity federation, typical SAML use cases, and how SAML integrates with other federation protocols, get the white paper.

 Get the White Paper
  • The Essential OAuth Primer

    Get an introduction to OAuth 2.0 and learn about tokens, standards and use cases.

    Get the White Paper
  • Open Standard Protocols

    Learn how the Ping Intelligent Identity platform supports identity federation using open standards.

    Learn More
  • SAML 101

    Learn what you need to know about Security Assertion Markup Language (SAML) in the tutorial video.

    Watch the Video

Is SAML outdated?

SAML 2.0 (2005) is still alive and well in many enterprises across the globe. SAML is typically compared with two newer alternatives, OAuth 2.0 (2012) and OpenID Connect (2014). Typically, newer solutions will start with OIDC and OAuth 2.0 and move to SAML if needed.

How does SAML SSO work?

SAML SSO works by passing "assertions", or xml messages, between two trusted parties, the IdP (identity provider) and SP (service provider).

Is SAML a protocol?

SAML (Security Assertion Markup Language) is an open identity security standard. SAML 2.0 arrived in 2005. It's popularly used to enable SSO (single sign-on).

How do I integrate with SAML?

SAML is an XML-based open standard that works via assertions. If you're integrating your app with an IdP that supports SAML, you just have to support accepting the assertion and checking its signature.

Does OAuth replace SAML?

OAuth 2.0 itself is an authorization standard. It's often paired with OIDC (OpenID Connect) to use as an alternative to SAML 2.0 for SSO, but they provide different implementations and have a few feature differences.

Is ADFS the same as SAML?

It is not the same as SAML. ADFS (Active Directory Federation Services) is a software solution that was born out of Microsoft's Active Directory product to enable SSO. ADFS is supposed to be an all-encompassing solution for SSO. It supports SAML and a few other standards, but it can be hard to setup, with a lot of manual preparation.

What is the difference between LDAP and SAML?

LDAP (Lightweight Directory Access protocol) is a protocol or standard for communicating with a particular kind of database. SAML is a standard used for identity federation services like SSO.

How do I find SAML attributes?

SAML attributes can be found in the SAML assertion, or token, that is passed between the IdP and SP. Decode the SAML assertion and the attributes will be shown in the XML text.

Is OIDC better than SAML?

OIDC (OpenID Connect) does a better job of spelling out the exact flows your users will go through, and its token (a JWT) is a little simpler to deal with. It's also compact and url-safe. A SAML assertion is in XML, so it can consume more space and may add a little complexity (you have to understand XML). Most organizations are trending towards OIDC if they don't have any SAML apps they need to integrate with. However, PingOne can handle both.