SAML, But Simple
- Vítor Batista @asUgo
- 9 hours ago
- 4 min read
I was going to start with something like: SAML, or Security Assertion Markup Language, is an open standard widely used for Single Sign-On. It sounds serious, but it does not really help much. So I’ll stick with this:
SAML allows a user to log in to one application or system by using the identity already verified by another trusted application or system.
That means one system handles the login, and the other trusts the result. To accompany us on this journey, let’s take the example of a Salesforce login page, where you can log in using the credentials of another application called “McAwesome Lord of Sign-Ins”.
What I’ll tell you about SAML
Its key components;
How it works.
SAML Key Components
Identity Provider (IdP)
The actual “Lord of Sign-Ins” is the application or system responsible for authenticating the user. This is where the user proves who they are by logging in to that system. Its responsibilities usually include:
Authenticating the user;
Generating and signing the SAML assertion;
Managing identities and credentials.
Service Provider (SP)
In our scenario, Salesforce is the application the user is trying to access. Its responsibilities usually include:
Trusting the Identity Provider through configured metadata;
Receiving and validating the SAML response;
Granting access based on the assertion content.
SAML Authentication Request
What the Service Provider sends to the Identity Provider when it wants the user to be authenticated. This is used when the Service Provider is the one starting the process.
Just like in our scenario, the process starts on the Salesforce login page, when the McAwesome Lord of Sign-Ins option is clicked.
SAML Response
What the Identity Provider sends back after the user is authenticated. It contains the result of the authentication and includes the SAML Assertion. It can be signed so the Service Provider can trust it, but this signature can also be in the Assertion, or even in both Response and Assertion.
In other words, after the user successfully authenticates with McAwesome Lord of Sign-Ins, it sends a response back to Salesforce. This response contains a lot of important information and, possibly, a signature that helps Salesforce verify that McAwesome Lord of Sign-Ins was the one that sent it.
SAML Assertion
The core payload in the SAML flow: an XML document that mainly confirms the user’s identity and carries the authentication information from the Identity Provider to the Service Provider.
McAwesome Lord of Sign-Ins’s response will also tell Salesforce exactly who logged in. Remember the Assertion can also be signed by the Identity Provider.
Metadata files
XML configuration files shared between the IdP and the SP that help establish trust and define how the two systems should communicate. In simple terms:
The SP uses IdP metadata to know where to send requests and how to validate signatures;
The IdP uses SP metadata to know where to send assertions and what settings to use.
How does SAML work?
SAML supports two main login patterns. The difference is simply who starts the process.
SP-initiated SAML
Starting at the Service Provider, the typical simplified flow is:
The user tries to access a protected resource in the SP;
The SP sees there is no active session;
The SP redirects the user to the IdP and sends a SAML Authentication Request;
The IdP runs the authentication flow;
The IdP sends a signed SAML Response back to the SP’s ACS (endpoint where the SP is expecting the SAML Responses);
The SP validates the response and identifies the user;
If successful, the user is logged in to the SP.
This flow can be used if:
Tighter control over the login handshake is wanted;
Stronger control over how the request begins is needed;
Users should start from the application itself, just like in our scenario (in this case, points 1 and 2 are slightly different, since the user directly accesses the login page and chooses to log in using McAwesome Lord of Sign-Ins).
IdP-initiated SAML
Starting at the Identity Provider, the typical simplified flow is:
The user logs in to the IdP, or uses an already active session;
The user selects the Service Provider;
The IdP sends a signed SAML Response to the SP’s ACS;
The SP validates the response and identifies the user;
The user is logged in.
This flow can be used if:
Users start from a central SSO dashboard;
You want a simpler launch experience;
Entry point is less controlled than in SP-Initiated flows (Deep linking).
Final thought
SAML is based on trust between two parties:
The Identity Provider (McAwesome Lord of Sign-Ins);
The Service Provider (Salesforce).
No matter how the flow starts, the Identity Provider is always the system that authenticates the user, and the Service Provider is the system that accepts that result. This is the foundation.
SAML is one of those topics that often gets introduced in a very technical way, even though the core idea is not that complicated.
If you would like to share ideas, feel free to message me on LinkedIn at Vítor Batista | LinkedIn.
Comments