IdP initiated SSO and SP Initiated SSO with SAML

Today I am going to talk about SAML based SSO. If you are not much familiar with IAM concepts, the first thing that pops into your mind is SAML. Is it really XML? Yes you are right. In a nutshell SAML is sharing user identity related data.

The SAML acronym belongs to the Security Assertion Markup Language which is a XML based markup language for sharing security assertions. It is also an open standard of exchanging authentication and authorization between trusted parties. SAML is mainly Used to implement federated authentication and SSO. If you are not familiar with SSO, read the article linked here. In the upcoming blogs I’ll dive into federated authentication. The following figure shows how SSO is going to work with the IdP.

Oops!!! What are Open-Standards there? Even if there is only an IdP, there are some issues that arise in Single-Sign-On.

When installing a new application into the organization domain and toward the IdP, developers should consider communication protocols on both the IdP side and the application side. As a result, some Open-Standard protocols have been introduced. The common Open-Standards are as follows.

1. OIDC (Open ID Connect)
2. SAML
3. WS-Federation

The latest version of SAML is SAML 2.0. It has 03 participants.

Subject / Principal — The user who is having an account in Identity Provider and the person who is trying to access Service Provider application.

Service Provider / Relying Party / Client Application — Web or a Mobile Application which can be accessible for the end user. The same particular service provider should be registered at the Identity Provider as well. Prior to sharing security information, there should be a trust relationship established between the Service Provider and Identity Provider. The trust relationship is based on public key cryptography.

Identity Provider / Asserting Party — Manage the user accounts and responsible for handing the user’s authenticity.

There are 03 different types of SAML Assertion

Authentication Assertions

• Identify the user.
• Provide the time that user have logged in
• State the Authentication type that has been used

Attribute Assertions

• User’s information (username,email,mobile etc.)

Authorization Assertions

• Decide if the user is authorized for the service or if IdP denies the request due to lack of rights to the service.

Hope you all got a little understanding about what SAML is and where it is used.

In the message flow of SAML based SSO, we can divide into two sections

1. SP (Service Provider) initiated SAML SSO
2. IdP (Identity Provider) initiated SAML SSO

WSO2 Identity Server and AAD (Azure Active Directory) support both IdP initiated flow and SP initiated flows.

SP (Service Provider) initiated SAML SSO

1. End users access the service provider through the browser.
2. By itself the service provider generates an Authentication request to the IDP by requesting the identity information. This is a SAML request, which contains the Service Provider’s information and SAML Request is expecting to collect some additional information from the Service Provider.
3. IDP validates the received request and prompts a login screen for the end user to enter credentials. Once a user enters those IDP will validate the entered credentials against the user stored credentials.
4. After successful authentication is done, IDP creates a session and generates a SAML Response (SAML Assertion) and passes it back to the service provider. This SAML message contains the name of the authenticated user and requested attributes if any.

In order to ensure the integrity of the SAML message, before sending it back to the Service Provider, IDP signs it with IDP’ s private key. Then the received response can be validated by the Service Provider using the IDP’ s public key. Since the response message contains sensitive data, it can be encrypted.Or else can be kept as it is.

AWS console supports the IdP initiated SAML SSO while Google apps supports over the SP initiated SAML SSO. However, Salesforce supports both SP initiated flow and IdP initiated flow.

IdP (Identity Provider) initiated SAML SSO

One of the most important facts in IdP initiated SAML SSO is there is no longer having a SAML request there. Just only a SAML Response.

1. End users access the IdP through the web browser.
2. IDP validates the received request and prompts a login screen for the end user to enter credentials. Once a user enters those IDP will validate the entered credentials against the user stored credentials.
3. If user credentials are valid IdP redirect a SAML response toward the SP.

Again, if you look at in both two diagrams, in SP initiated SAML SSO, there is a SAML request. But there was no SAML request in the IdP initiated SAML SSO.

How can users select one over the other? It depends on the Service Provider and the IdP that you are using. However, most of the time SaaS applications encourage the use of IdP flow. The reason for that is that within a minimal number of steps, the minimal effort authentication process is going to be completed.

Note — — — — — — — — — — — — — — — — — — — — — — — — — — — -

Salesforce is a SaaS (Software as a Service) product which has multiple user tenants. Once a user logged into the Salesforce, a couple of years ago the way that Salesforce identified the logged user tenant by identifying credentials. Each user tenant has separate IdP s as well. As an example WSO2 Salesforce tenant may have their IdP as WSO2 Identity Server.Microsoft’ s Salesforce account may have their IdP as Azure AD.

In such a case, if a multi-tenant SaaS app uses IdP initiated flow, there is no correct way to identify the corresponding tenant. How salesforce was doing that, just after getting credentials, get back with the user store and identify the user tenant and redirect the authentication SAML request to the IdP.

However around 2013–2104 Salesforce introduced a feature called MyDomain. SImply a subdomain feature for each user tanant. Unlike previously, salesforce can identify the particular user tenant just looking at the URL despite having user credentials. After introducing the MyDomain feature, Salesforce supports IdP initiated SAML SSO as well. If you want to learn more about the Salesforce MyDomain feature click here.

Following part shows how SP initiated SSO with WSO2 Identity Server.

Pre requirements

• Download WSO2 Identity Server,Install and run it
• Download Tomcat9 Server,Install and run it
• Download sample application (Pickup dispatch & Pickup Manager)
• Enable SAML Tracer extension in your browser

Moreover you can go through the following documentation, if you are struggling to configure the above resources.

• Install and run Tomcat
• Configure samples

Once you configured successfully, this is how you will get.

The following diagram shows how SP initiated SAML flow is going to work on your demonstration. This is something that I have included in an abstract way in the 1st diagram but specifically a use case oriented.

“Index.jsp” page initial front view that you may get on behalf of a service provider for the very first time. Once the user clicks the login option, a SAML request is going to trigger. Service Provider redirects to the IdP. Carefully look at how your URL is now. Obviously it is not from the Service Provider’s domain. It is entirely on the IdP host domain. There are some alternative terminologies to redirect this SAML request from Service Providers domain. Their URL’s domain will not be changed. IdP s login screen will pass via a query string attached with the same service provider’s domain.

I have already discussed this redirection mechanism, at the end of my Single-Sign-On (SSO) capabilities with Identity Providers article

Once a user provides the valid crdentials, the IdP redirects to the Default Assertion Consumer URL. In this example as you may see, the consumer URL is home.jsp page.This is the point where the SAML Response occurred.

This is a SAML tracer extension. Just open this extension and keep a side before you click the Login button on the Service Provider. Once you click the login you may be able to see the SAML request, you may able to sea the SAML Request as follows,

Once you provide valid credentials, SAML Response seems like below. Unlike in SAML Request, in the Response it includes the logged user’s name (line 90) and other requested attributes as well.

So hope you have learned something new. Let’s catch up in the very next episode.