Understanding the SAML Authentication Flow for SP-Initiated SSO

SAML (Security Assertion Markup Language) is one of the most common protocols used for implementing SSO. This article walks through the high-level flow of the SP-initiated SSO process, explaining the interaction between the key components involved: the End User/Browser, Service Provider (SP), Identity Provider (IDP), and the Identity Store (LDAP).

Components in the SP-Initiated SSO Flow

Before diving into the flow, it’s essential to understand the components involved:

1. End User/Browser: This is the user accessing the application or service hosted by the Service Provider (SP) – a user Browser.

2. Service Provider (SP): The application or service that the end user is trying to access. It relies on a trusted Identity Provider (IDP) for user authentication. The main focus of this service provider is to provide its services to end users.

3. Identity Provider (IDP): A system responsible for authenticating users and providing the necessary identity assertions(user details/attributes of the user) to the SP. The IDP validates the user's identity and generates authentication details within the assertion XML format.

4. Identity Store (LDAP): A centralized directory or database that stores user credentials and other identity-related information. The IDP communicates with the identity store (often an LDAP server) to authenticate the user.

---

High-Level SP-Initiated SSO Flow

The SP-initiated SSO flow begins when a user attempts to access a protected resource on the Service Provider’s site. Below is a step-by-step breakdown of the process:

1. User Requests Access to the SP

The flow begins when an end user attempts to access an application or service hosted by the Service Provider (SP). This is typically done by typing the URL of the SP into the browser. If the user is not already authenticated, the SP needs to authenticate them to ensure they have access to the protected resources.

• Action: The browser sends a request to the SP’s server for a specific resource.
• Eg: SP URL: https://www.salesforce.com/payment

2. SP Redirects to the Identity Provider (IDP)

Upon receiving the request, the SP checks if the user is authenticated. If the user is not authenticated (which is the case for the first request or after a session expires), the SP needs to authenticate the user via an external identity provider (IDP).

The SP sends a SAML authentication request to the IDP, redirecting the user’s browser request to the IDP. This request is often sent in the form of a URL query string that contains information about the SP and the requested authentication context.

• Action: The SP constructs a SAML authentication request and redirects the user's browser to the IDP.

3. IDP Authenticates the user

At this point, the IDP receives the request from the SP and checks if the user is already logged in. If the user is not logged in, the IDP will prompt the login page to the user to provide their credentials.

The IDP will communicate with the Identity Store (LDAP) to authenticate the user. The LDAP server holds the user credentials (username, password, etc.), and the IDP will validate the credentials against the identity store.

• Action: The IDP either asks the user to log in or validates the user’s session if already authenticated. The IDP then verifies the credentials against the LDAP identity store.

4. IDP Issues a SAML Assertion

Once the user is authenticated successfully, the IDP will create a session within the user's browser and generate a SAML assertion, which is a digitally signed XML document that contains the user’s identity information. This assertion serves as proof that the user has been authenticated.

The IDP sends the SAML assertion back to the SP. The assertion is sent in an HTTP POST request to a specific endpoint on the SP’s server.

• Action: The IDP generates a signed SAML assertion and sends it to the SP via the user’s browser.

5. SP Validates the SAML Assertion

Upon receiving the SAML assertion, the SP validates it and creates an application session within the user’s browser. The validation process includes verifying the digital signature on the assertion to ensure it was indeed issued by the trusted IDP and hasn’t been tampered with. The SP also checks that the assertion is still valid (i.e., not expired or misused).

The SP uses the information in the assertion (such as user attributes and authentication statements) to establish a session for the user. This information might include the user’s name, email, roles, or other relevant data.

• Action: The SP validates the SAML assertion and extracts user identity details.

6. Access Granted to the User

Once the assertion is validated, the SP establishes a session for the user and grants them access to the requested resource or application. The user's browser is redirected to the protected resource, and the user is now able to access the service without having to authenticate again.

• Action: The SP grants access to the requested resource, and the user is now authenticated and authorized.

Share on Google Plus

About Satya

Satya is an IAM Engineer and the Editor of Techstotle.com. He possesses a deep passion for Identity and Access Management (IAM) technologies, with a particular focus on PingFederate and PingAM. Satya is dedicated to demystifying these complex technologies and making them accessible to a wider audience. Techstotle.com serves as a one-stop shop for the latest IAM insights, featuring comprehensive tutorials on PingFederate and PingAM. Join Satya on this journey of tech exploration as he empowers you to navigate the ever-evolving world of IAM.