Let’s take a dive into the shallows of SAML

First of all, to get things up and running, you might be wondering what SAML stands for?

SAML stands for Security Assertion Markup Language which is an XML-based markup language for security assertions and one of the standards at Organization for the Advancement of Structured Information Standards (OASIS).

Before moving to the concepts of SAML, let me explain the skeleton embedded in SAML in clear and simple terms with definitions.

Single Sign-On (SSO)

In any of the organizations which currently exist there are several applications to perform specific day-to-day tasks. These applications contain a common user store (Centralized Access Control) to authenticate the employees working in the organization.

The workflow of a Centralized Access Control

To access any of these applications, they perform the following process flow:

1. Prompt and acquire user credentials.
2. The application communicates with the user store and authenticates the user.
3. And finally, the application will manage the session for the user.

Graphical Overview of a Centralized Access Control

Let’s say that the user accessed Human Resource Application. What do you think would happen when the user tries to log in to the Accounts Application?

If your answer is, Follow the steps as mentioned above again, then your answer is correct.

From the answer itself there are concerns in this method, such as:

1. Low Productivity.
2. Cost of Development.
3. Low Agility.
4. Poor User Experience.

The remedy for these concerns is SSO with an Identity Provider System.

The workflow of SSO with an Identity Provider System

The identity provider connects to the organization’s user store and authenticates the user on behalf of the applications. The process flow is as follows:

1. The user accesses the HR Application, which then redirects the request to the Identity Provider System.
2. Identity Provider authenticates the user by requesting the credentials as the browser does not have a session created for that user and sends the response back to the HR Application.
3. The user is provided access to the HR Application.
4. Now, if the user accesses the Accounts Application, it will redirect the request to the Identity Provider System.
5. Identity Provider authenticates the user but does not prompt for credentials as the user already has a session created.
6. The user is provided access to the Accounts Application without entering his/her credentials again.

Graphical Overview of Single Sign-On

Now, this is Single Sign-On.

In simple terms Single Sign-On is, log in once to an application of the organization and access any other application belonging to the organization without logging in again. This provides a smooth user experience which is one of the highest priorities in any organization.

Open Standards

But then again there is a concern in SSO with IDP that this results in a huge developer effort when new applications are amended to the organization. This is because either the application or the identity provider should be configured to adhere to communication protocols.

This is where Open Standards come into the play, Open Standards are a set of standard protocols used for communication. Some well-defined standards used for SSO include:

1. OpenID Connect.
2. SAML.
3. WS Federation.

The protocols mentioned above have accepted message formats and standardized specifications. Both the IDP and the applications should implement these specifications, by doing so the application will have a pre-defined set of messages which are used to communicate with the IDP and the IDP would be aware of the messages sent by the application.

Now, amending applications which are using Open Standards to the organization is just a matter of configuring it inside the IDP.

I won’t be talking about OpenID Connect and WS Federation since it is off the scope of this article. Now that the skeleton/prerequisite concepts of SAML are done and dusted let’s move onto SAML.

SAML (Security Assertion Markup Language)

At the start, I’ve given a brief detail about SAML including what it stands for, what type of language it is based on and which organization implemented the standard. So, I’ll be continuing from that point onwards. And, I will be talking about version 2.0 of SAML.

SAML is an Open Standard that is used to pass:

• User credentials (The username and password),
• User accessible content,
• Additional user attributes.

SAML 2.0 Participants

SAML 2.0 has three types of participants:

1. User/Subject/Principle- The user who holds an account and owns certain resources within the application (Service Provider).
2. Service Provider/Client Application/Relying Party- Any kind of application that accesses resources on the user’s behalf.
3. Identity Provider/Asserting Party- Provides authentication to the resource owners given the user credentials.

The relationship between the three participants is based on trust.

Before talking about the relationship let’s first look into how the process is executed.

Flow Diagram representing SAML workflow

Explanation of the steps marked on the diagram above:

User = James, Service Provider = Medium, Identity Provider = Google

1. James accesses the Medium website with the help of the web browser and selects the method to log in (in this scenario it’s Google).
2. Medium sends an authorization request to Google.
3. Google authenticates the user using the credentials provided by the user.
4. If the authentication on step 3 is successful then, Google sends back the response to Medium. This response is known as a SAML assertion and contains the service provider requested user attributes (these may be encrypted if sensitive information is passed). Medium verifies Google as the correct identity provider by comparing Google’s private key and Medium’s public key.

Sample SAML Assertion

James is now logged into Medium using his credentials of Google.

Important aspects embedded in the relationship

• User credentials provided to the identity provider will not be passed onto the service provider, only the requested user attributes will be provided.
• The service provider does not need a separate user store to store the details about the user. (Beneficial for Software as a Service (Saas) vendors)
• The identity provider creates a browser session and authenticates the user on behalf of the service provider, all the security concerns are handled by the identity provider and a SAML Assertion will be sent as a response back to the service provider.
• Once the user authenticates into a specific application of the organization, then it’s a matter of checking whether there is a session created for the user when the user accesses another application.

SAML Specifications

For more information on SAML specifications, you are free to refer to the links mentioned below.

• SAML 2.0 Core
• SAML 2.0 Profiles
• SAML 2.0 Bindings
• SAML 2.0 Metadata
• SAML 2.0 Conformance

I hope that you understood the basic idea behind SAML and that I’ve answered what, why and how questions of SAML. I’m open for any clarifications or suggestions about the content.

More on SAML concepts and implementations to be released later so, till then it’s a goodbye from me!!

References:

1. WSO2 Documentation
2. SAML Documentation