SAML Explained: Exchanging Authentication and Authorization Data Between Security Domains

One of the topics I am repeatedly asked about is SAML or Security Assertion Markup Language. Specifically, people want to know  what it is and how it works and what the benefits are. I’ll tackle the first part here (what it is and how it works), and then follow-up in a second post on what the benefits are.

SAML is an open standard for exchanging credentials for the purpose of authentication and authorization. In practice the typical SAML flow involves no password exchanging. Rather, there is a system of trust where only the user’s identity is passed around. A typical use case for this is that instead of a user typing out their username and password for a multitude of SaaS products, you only have to sign in once and you immediately have access to any number of additional services without entering in any other credentials. In the industry this is often simply referred to as SSO (Single Sign-On).

What you sign-in to, in this case, is often referred to as the Identity Provider (IdP). The IdP in turn, has a trust relationship with one or more SaaS products, or a little more generic is the term Service Providers. So we have one IdP, and it has a trust relationship with several SPs. The “trust” is facilitated with a certificate. This certificate is generated by the IdP, and if a Service Provider has a copy of it, it allows for a trusted relationship between the IdP and the Service Provider.

Here is a simple IdP initiated SSO request:

Exchanging Authentication and Authorization Data Between Security Domains:

1. A trust relationship is established between the IdP and the Service Provider. Essentially, the Service Provider has a certificate that the IdP has generated and any communication from the IdP to the Service Provider has to be ‘signed’ with this certificate. It’s extremely hard to fake signing without the certificate.
2. A user signs into the IdP with their credentials.
3. The user selects a service, or Service Provider / SaaS application.
4. The IdP returns a SAML response (that is digitally signed by the IdP with its certificate)
5. The browser takes this SAML response and posts it to the Service Provider. The Service Provider confirms that the SAML response is properly signed, and if so, gives the user access to the resource – typically the welcome page of the SaaS application.

This is a very secure and scalable approach to security for organizations that need access to a variety of resources across the internet.

Part two of this series on SAML explains the benefits you’ll receive from implementation.  If you have any questions or comments, please post below – or contact us  here

About Gavin Gaudet

Gavin is Product Architect, Cloud Services at Softchoice. He's a technology enthusiast who has spent the last 12 years creating and building things.

• 
•