Demystifying SAML

In the rapidly evolving landscape of digital security, robust authentication & authorisation mechanisms are paramount. With the proliferation of online services and the need for seamless user experiences, the significance of secure, scalable, and user-friendly authentication & authorisation protocols cannot be overstated. SAML (Security Assertion Markup Language) has turned out to be one of the most popular and robust authentication & authorization protocol. Specially for SSO use case SAML is widely used. Today we’ll deep dive in to this protocol.

But before deep dive, as usual, I’d like to explain Authorisation and Authentication.

Authentication

Authentication is the process of verifying the identity of a user, device, or entity. It ensures that the entity is who or what it claims to be. Authentication is typically the first step in any security protocol. For example, username & password can be used as authentication. Now a days it’s common to use another secondary authentication (Multi Factor Authentication) using phone or email for security reason. AuthN is a common term used for authentication.

Authorization

Authorization is the process of determining whether a user, device, or entity has the right to access specific resources or perform certain actions. It occurs after authentication and defines what an authenticated entity is allowed to do. It mainly determines what operations are allowed for the Authenticated User. AuthZ is a common term used for authorisation.

In short Authentication is proving who you are and Authorization is the permission that you have. If you are NOT clear with Authentication and Authorization, I’d request NOT to proceed further. Do google and have clear understanding of this. Rest of the discussion assumes you have clear understanding of both.

Before we go further in discussion, let me introduce you to some common terminologies which will be referred later on.

SP — Service Provider

As the name suggests, Service Provider is referred to some service, external facing or internal. While majority of the user interaction happens with external facing service (e.g. gmail, tweeter etc.) , however now a days, for improved security there is service to service authentication. Specially, in a micro-service architecture one service has to authenticate and need to have authorisation for reaching out to another service. In a nutshell we can see SP as any service that validates Authentication and Authorization.

IDP — Identity Provider

This is the entity that does the authentication and also maintains information about authorisation. Azure B2C, Okta, Auth0 etc. are example of enterprise grade IDP. Facebook, Google, tweeter etc. are also IDPs and you must have use those login credential to log in to some other system. In short this where your credentials and few other information about you are stored and IDP can validate who you are based on some credentials e.g. username/password along with MFA (Multi Factor Authentication).

Principal/subject

This is the user who is trying to consume some service from the SP. For example, you are trying to access gmail. Your are the Principal/Subject here.

One important point to be noted here is the responsibility segregation. IDP is responsible to authenticate a user and maintain authorisation information of that user for multiple systems. Think of an office scenario where you may have admin permission on some system where as in another system you may have read-only permission. IDP maintains those information. Here Service Providers are those system where you have admin access or read-only access.

SAML — Security Assertion Markup Language

SAML (Security Assertion Markup Language) is an XML-based open standard for exchanging authentication and authorization data between parties, specifically between an IDP and SP. But before we go to the user flow, we must see how trust build up between IDP & SP happens.

Trust Build up

There are two way trust between IDP and SP can be established. One is manually login to both the portal and uploading each other’s certificate. Or doing metadata exchange between them. IDP & SP consumes each one’s metadata to build trust and other data format.

IDP metadata:

Below are the few important metadata that are exchanged between IDP & SP as part of trust buildup.

• Certificate: SP meta contains SP Certificate that IDP should use for signature validation and decryption of data. There can be different or same certificate both signature and decryption. Similarly IDP meta contains IDP certificates that SP should use for signature validation and decryption.
• Endpoints: SP meta contains SP end point where IDP will do SAML assertion. Similarly IDP meta contains endpoints for SAML requests. SP will send SAML requests to that endpoints of IDP. There are few binding options how to send the assertion.
  * urn:oasis:names:tc:SAML:2.0:bindings:HTTPPOST
* urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect
* urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST-SimpleSign
* urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact
* urn:oasis:names:tc:SAML:2.0:bindings:PAOS
• NameIDFormat : SP and IdP usually communicate each other about a subject. That subject should be identified through a common NAME-IDentifier so that either party uses same format. There are few options available for the same.
  1.urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified [default]
2.urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress
3.urn:oasis:names:tc:SAML:2.0:nameid-format:persistent
4.urn:oasis:names:tc:SAML:2.0:nameid-format:transient

SP metadata Example:

IDP metadat Example:

Detail Specifications.

Now that trust between IDP and SP is established, we can go to the SAML Requests and Response flow.

SAML Request Response Flow:

Diagram is self explanatory. Above flow is for SP initiated flow. It it possible that IDP lists all applications that has user’s authorisation and when user completed login and tries to access any of the SP from the IDP, IDP directly sends the SAML assertion to SP. In such cases step 1,2,3 is omitted.

SAML Request Format

During SAML requests with the details you see in the image. ID is used to match with the response. Same ID will be carried over by response. Also you can see that it is sending Assertion URL, Protocol Binding etc. information. IDP validates those and presents login page only if validation is fine. Also request has many flavour like-

• Simple AuthnRequest
• AuthnRequest with IdP scoping
• AuthnRequest with Requested AuthnContext

Here is an article that has all kinds of sample requests.

SAML Assertion Format

The SAML assertion is nothing but a signed XML file where the information about Authentication and Authorisation are present. IDP does directory query to find the authorisation and sends those in the SAML response .Both SAML requests and responses are signed and during metadata exchange certificates are exchanged. Those certificate are used to sign and validate signature.

Here is an article that has many sample request & response examples.

Conclusion

SAML stands as a robust and effective standard for federated identity management and single sign-on (SSO) solutions. Almost all, if NOT all, IDP supports SAML. However there are concerns related to XML processing .

References

Acknowledgments

SAMLv2 Identity Provider Customization (Sun OpenSSO Enterprise 8.0 Administration Reference)

SAML Examples | Developer Pages