Exploring SAML

SAML — Security Assertion Markup Language

SAML is a technology standard used and well documented in IAM space.

The most popular use case of SAML is SSO (Single Sign On).

In SSO a particular user is authenticated into several applications via a single account. So it makes the life of users very easy as they will not have to face “password fatigue” by remembering different passwords for different applications. Having one set of credentials is enough to access multiple applications.

In SAML SSO, user’s identity and other details about the authenticated session are exchanged from IDP(identity provider) to SP(service provider/application) in the form of digitally signed XML messages(SAML assertions).

What are some benefits of this standard?

  • It provides more secure authentication. Before SAML came into the picture, the normal way of authentication was to type username and password to log into an application. And most of the time each app stored those credentials with them, paving the way to many security breaches. With SAML, the user is authenticated via a trusted IDP and that IDP stores the credentials. The applications no longer need to store the user credentials individually.
  • SAML can be implemented on top of any system regardless of the underlying implementation
  • With SSO one set of credentials to access many apps.
  • Better user experience

Is SAML powerful?

  • We can say its powerful, as it is one of the popular ways to implement SSO in a system
  • But…. now there is OAuth2 which is the front runner in SSO domain. So, SAML is kind of losing its charm. Since SAML is using XML as the message format, it is not much flexible opposed to Oauth2 which uses JSON format.
  • SAML is not good with mobile applications, as opposed to OAuth2.

Key SAML terms

IDP

IDP (Identity Provider) is the server that authenticates the users and stores their credentials. Once IDP authenticates a user, it provides “authentication assertion” (authentication details ) for that user.

SP

SP (Service Provider) is the application that a user wants to log in. SP will not do authentication from their side. It will delegate that task to IDP.

Client

User that send requests to SP

SSO Service

SSO service endpoint is in IDP. This service in IDP handles the SAML SSO requests and also handles sending SSO responses.

SSO Serivce at IDP

SAML SSO

There are 2 types of SSO use cases in SAML SSO.

  1. SP initiated SSO
  2. IDP initiated SSO
High level view of SP init SSO and IDP init SSO .

As depicted in the above image, in SP initiated SSO flow, the SP sends a SAML request to IDP and IDP responds with a SAML response. In IDP initiated SSO flow, SP does not send any request. IDP initiates the flow by sending a SAML response to a SP.

In both these flows, the IDP sends a digitally signed XML as authentication response. Then SP verifies the signed XML for any tampering and provides access to the user. (When signing digitally, a hash value of the XML response is encrypted using the private key of the sending party. In this case IDP. When the receiving party(SP) receives the signed XML, it first decrypts it using the public key of sending party and then compare the hash value after decryption with the actual hash value of the received message. If both are same it means the message was not tampered by a third party.)

SP initiated SSO

In SP init SSO, there can be two scenarios.

  1. User visits SP. User is not authenticated. Therefore the user is redirected to IDP and authenticated. Here user needs to provide login credentials in the login screen.
  2. User is already authenticated with IDP. User visits SP. The user gets access without again authenticating with IDP. (Here SP contacts IDP, to check whether the user is already authenticated. Since the user is already authenticated a login page will not be displayed for the user.)

What is SAML metadata?

SAML metadata are information, endpoints, capabilities, details of parties involved in SAML use cases.

SP has its own metadata and IDP has its own metadata.

SP and IDP can use each other's metadata to configure and communicate with each other. For example, an admin of a SP can import IDP SAML metadata into SP and vice versa. IDP metadata contains endpoint for SSO service.

SP and IDP contains each others metadata to gather relevant information about both parties

How does the SP redirects to IDP to login in SAML?

In SAML, SP has prior knowledge/metadata on the IDP. Therefore, when sending a SAML request to IDP, SP find the IDP SSO service endpoint URL via IDP metadata and re-direct to correct IDP endpoint. So, when implementing a SP we should think about configuring IDP redirect URL in SP side as well as having IDP public certificate too.

In a case where SP has more than one trusted IDPs there should be a way to identify which IDP to use when a client sends a request. Some ways to determine IDP are

  • If request URL has IDP ex:spdomain/tenant/{IDP}
  • Prompt a dialog box for users to enter their corporate email id. Then SP can determine the IDP according to the email domain

SAML Token

SAML response contains SAML token. Some attributes defined in SAML token are,

  • SAML token issuer (IDP)
  • user’s email
  • SAML token expiry time/validity period
  • The time user got authenticated

Once the SP receives the SAML response with a SAML token, SP uses that token to continuously verify the user’s session. It is up to SP to save it in a browser cookie or some mechanism to track user’s session. Then until the SAML token validity period ends, the SP can use that cookie to keep the user continuously authenticated to SP site. Once the SAML token becomes invalid, SP can send a new SAML authentication request to IDP to authenticate the user again.

Cookies are name-value pairs that are set against host domains. Whenever a browser makes a request to a particular domain, all the cookies belonging to that domain will go along with the request. In SAML, both SP and IDP can define cookies for their domains.

Let’s take a sample scenario of an IDP cookie.

Let’s say a user has enabled SSO with two apps/SPs with a trusted IDP. When the user opens his browser and tries to authenticate with SP1, that SP1 sends an authentication request to the trusted IDP. The IDP authenticates the user and sets a browser cookie against the domain name of the IDP (ex:commonAuthID cookie in WSO2 IS). The user uses that same browser and tries to visit SP2. SP2 also re-directs the user to IDP with an authentication request. When this authenticate request goes to IDP, the cookie set against the IDP domain also sent along with that request. IDP reads that cookie and determines the user is already authenticated and let the user to be logged in to SP2 without prompting any login pages.

IDP cookie

Multiple SP Behavior

One misconception some people have on SSO between multiple SPs is that SPs talk to each other to have SSO between them. The correct approach is each SP should talk to the trusted IDP to make sure a user is authenticated. There is no communication between each SP.

What is IDP initiated SSO?

Since SP init SSO is a very common use case I will try to explain IDP init SSO which is not discussed as much as SP init SSO.

Let’s get a sample use case as follows to describe IDP init SSO.

  1. You are logged in to your corporate IDP.
  2. And this IDP has a user portal of different external/internal partner service providers(ex: Expense report app) which trust this IDP.
  3. Let’s say you want to create an expense report for your OPD claims. You click the link related to the expenses report service in the portal of your IDP. (When you click the link it will call the SSO service at IDP to send a SAML response to the corresponding partner SP)
  4. Then the IDP creates a SAML response and sends it to the partner expenses report service.
  5. Since that expenses report service has registered your corporate IDP as a trusted source, it will create a session for you and you will be already logged in to that app. You don’t have to authenticate separately.

Is SAML IDP an “authorization authority”?

Normally SAML is used for authentication. Authorization is about providing access control according to some rules/policies/attributes. In a SAML response, there can be attributes that can be used to make authorization decisions. So SP can use those attributes in the SAML response and decide whether to provide access or not to the user.

In this post, I mainly explored on SAML SSO. In upcoming posts, I will discuss other aspects of SAML

To Be Continued …

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Denuwanthi Hasanthika

Denuwanthi Hasanthika

Graduate of University of Moratuwa, Department of Computer Science and Engineering. Associate Technical Lead at WSO2 Identity Server team.