How Does SSO With SAML 2.0 Work?
We go over the two types (Identity Provider-Initiated and Service Provider-Initiated) and give an example walkthrough of what it looks like in practice
Having trouble figuring out how to implement SSO with SAML 2.0? Or are you just curious about what it even is?
We’ve got you covered on both bases. This post will help you understand what SSO with SAML 2.0 is. We’ll explain it at a high level, then go through an example about what it looks like in practice.
By the end, you should have a solid understanding of SSO with SAML 2.0. But first, SSO is a big topic, and we can’t cover everything about it in one post.
What This Post Contains
- An overview on what SSO is and specifically how it works with SAML 2.0 (For simplicity, whenever we mention SAML from now on, we mean SAML 2.0)
- An explanation of the two types of SSO with SAML: Identity Provider-Initiated and Service Provider-Initiated. (Hint, they are both part of the same flow, but IdP-Initiated just starts at a later point than SP-Initiated. Also, we’ll explain what all those terms mean.)
- An example walk-through of how a user would log into a service using SSO with SAML
What This Post Does Not Contain
- A breakdown of every single implementation of SSO with SAML. SAML is a standard and not a specific procedure, so there are many ways to customize it to your needs. We can’t cover them all.
- A deep dive into all the different types of SSO.
We’ve got a lot of ground to cover, so let’s get started!
Overview On SSO
SSO stands for “single sign-on.” At its core, SSO enables a user to log into one place, then access external services without having to directly log into them.
There are many types of SSO. One such example is using Facebook to log into other apps. You aren’t creating individual usernames and passwords for these other apps. Instead, your Facebook credentials are being used to authenticate you for these other apps.
You sign into one place (Facebook) and get access to multiple services.
That is SSO in a nutshell.
In more technical terms, we would say that SSO handles the authentication of a user in a federated identity system. Some versions of SSO handle authorization in addition to authentication. The difference between the two is that authentication handles whether a user can log into a service, whereas authorization handles which permissions the user has in that service.
There are many different options for SSO, including OpenID Connect, Facebook Connect, Microsoft Account, and SAML. Within each of those options, SSO can be configured in many ways.
Now you see why we’ve got to limit the scope.
We’re going to cover SAML, and within that, we’re going to explain one way to implement SSO with SAML. By no means is this the only way to do it. But we’re trying to write a post here, not a book.
What Is SAML?
SAML stands for Security Assertion Markup Language. According to Wikipedia, it is “an open standard for exchanging authentication and authorization data between parties, in particular, between an identity provider and a service provider.”
That’s a lot of terms there. Let’s break them down.
Open standard: We’ve covered this already. There are many ways to implement SSO with SAML.
Authentication and authorization data: SAML is used to allow users to log into a service (authentication) and also control which permissions a user has in that service (authorization).
Identity provider: This is the service that has information about the user. It handles authenticating the user and communicating which services the user is authorized to do in the other service.
Service provider: This is the other service. This is what the user ultimately wants access to.
SSO with SAML is mostly done in an enterprise setting. For example, an employee at Nike wants to use Salesforce. Nike would probably have an SSO provider like OneLogin or Okta. Nike would add any external web services they want their employees to be able to access there. An employee could log into the portal and then click a link to go to the appropriate web service and be automatically logged in there.
This type of setup eliminates employees having to create individual credentials for these other services. This increases security because employees don’t have to remember passwords, and Nike’s IT department doesn’t have to worry about their passwords being insecure.
The Two Ways Of Implementing SSO With SAML
The two ways are all part of the same flow. You could say that one option is just starting later in the process.
Service Provider-Initiated
The user goes to the SP first and provides enough information that the SP knows where to contact the identity provider to ask for authentication. A common example is requiring an email address from a user. Since the user is probably coming from a company portal and using a company email, the SP knows to route the user back to the identity provider that is associated with that company.
Identity Provider-Initiated
The user starts at their identity provider. (Or ends up here as part of the SP-Initiated flow.) They log in. The user clicks a link that sends them to the SP along with their authentication details. The SP verifies these authentication details and logs the user into their service.
So an IdP-Initiated flow just starts at a later point than the SP-Initiated one.
Example Walkthrough
We’ve gone over a lot of terms. Maybe it still feels a bit too abstract.
No worries, let’s go through two examples to show exactly what happens — a short version and a detailed version.
Let’s say we have a hypothetical employee named John Brown. He works at Nike. He wants to access Salesforce. And Nike uses OneLogin as their SSO provider. The employees must log into OneLogin to be able to access all third party web services.
For the short version, we just need a refresher on what the relevant terms mean:
- Identity provider — Nike’s OneLogin dashboard
- Service provider — Salesforce
That should be enough for now. We’ll go more in-depth once we get to the longer version.
The Short Version
- John goes to the Salesforce site and enters his email.
- Salesforce looks up the identity provider that is associated with Nike (in this case OneLogin), and sends an authentication request to them.
- OneLogin asks John to login to their portal. John does.
- OneLogin sends a POST request to Salesforce with a SAML Assertion that says he is authenticated.
- Salesforce processes the POST request and logs John into the system.
- John can do all the Salesforce shenanigans he wants to.
From John’s perspective, he had to enter his email address on Salesforce and then log into his OneLogin dashboard. And that’s it. He’s ready to use Salesforce.
These steps are the SP-Initiated flow. An even quicker way for John to log into Salesforce is through IdP-Initiated flow. In that case, he would start at his OneLogin dashboard, log into it, and then click a link for Salesforce. Then he’d be logged into Salesforce.
The only difference between SP-Initiated and IdP-Initiated flows are where John starts the process.
If he starts at the service provider, it’s SP-Initiated.
If he starts at the identity provider, it’s IdP-Initiated.
We’ve brushed over some of the details of how SSO with SAML actually works, so let’s go over a more detailed walk-through now.
The More Detailed Version
Since this will be a more in-depth walk-through, let’s again go over the terms we need to know:
- Identity provider — Nike’s OneLogin dashboard
- Service provider — Salesforce
- User agent — a web browser like Firefox
- Principal — John Brown
Each step we go over corresponds to the numbered step in the image above.
Step 1: Request Target Resource / John Visits The Salesforce Website
The principal tells the user agent to go to the service provider. In our example, John opens up Firefox and visits the Salesforce SSO login page.
But Salesforce doesn’t know who John is. They don’t know that he works at Nike and should have access to Salesforce. Right now, he’s just a random guy on the internet. What it needs is some identifying information, so it can determine who wants to log into Salesforce.
John enters his email address — johnbrown@nike.com.
Salesforce sees that the email address belongs to Nike. How does Salesforce know where to redirect John to for authentication?
Well, that’s kind of a trick question because Salesforce already has to know this information.
Huh?
SSO with SAML isn’t magic, people. It doesn’t just work out of the box. The IdP and the SP need to set up some configuration ahead of time.
The three main pieces of configuration are the following:
- Certificate — The SP needs a public certificate from the IdP to validate a later XML signature. The certificate is stored on the SP side and used when a SAMLResponse arrives. Basically, the SP needs a way to verify a later message from OneLogin that says, “Hey, Nike here. We’ve logged John in on our side, and we say he can use Salesforce now.”
- ACS Endpoint (Assertion Consumer Service URL) — This is often referred to simply as the SP Login URL. This is the endpoint provided by the SP where the IdP can send a POST request with a SAMLResponse that is the proof that John is authenticated. The SP needs to provide this information to the IdP ahead of time.
- IdP Login URL — This is the endpoint on the IdP side where the SP redirects the User Agent and sends along a SAMLRequest that asks for the user in question to be authenticated. The SP needs to obtain this information from the IdP ahead of time.
With these pieces in place, when John enters his Nike email address, Salesforce can look in its back end for which IdP Login URL corresponds to Nike. Salesforce can now send John to the right place to get authenticated.
Important note — SSO with SAML is an asynchronous process. All necessary information must be sent along with every network request. Salesforce isn’t storing any information or waiting for John to get back to them.
Technical note — Let’s say after logging in, Salesforce brings to you a “/accounts” page. If John tried to immediately load “/accounts/marketing/budgets” instead, the additional path information will be stored as the RelayState parameter. This information must be sent on every network request, so that once John is authenticated for Salesforce, he can jump straight to the deeper page he originally wanted. This is an example of the stateless nature of SSO with SAML. If at any point, the RelayState parameter is left off a request, then ultimately, John will be sent to whatever the first page of Salesforce is.
Step 2: Redirect To IdP SSO Service / Salesforce Sends A Redirect To The Browser
Salesforce generates a SAMLRequest parameter (and a RelayState parameter if needed), adds them to the IdP Login URL as query parameters and redirects the browser to the IdP SSO Service.
A SAMLRequest can also be called an Authentication Request. It contains identifying information for the person trying to access Salesforce.
In our example, Salesforce would tell Firefox to redirect to the IdP Login URL that it has stored for Nike.
Step 3: Request The SSO Service At The IdP / Browser Goes To The Identity Provider
The user agent sends a GET request to the IdP Login URL. The IdP will process the Authentication Request and perform a security check.
A security check just means that OneLogin will see if John is logged into their service. If he’s not, he will be prompted to log in.
Step 4: Respond With An XHTML Form / IdP Sends A Form To The Browser
Note: SP-Initiated flow has now reached the start of IdP-Initiated flow. These proceed in identical fashions from here on out.
The IdP will respond with an XML document that contains an XHTML form. Inside the form is a SAMLResponse parameter that contains an XML Assertion. The Assertion can contain a few statements, but the main one is an Authentication statement which says the specified subject was authenticated. The Assertion could also have one or more Attributes, and these could be used to label the user for the purposes of authorization. For example, an Attribute of “Admin” might give John full access to Salesforce, whereas an Attribute of “Sales” would give him access to the Sales pages.
For some examples of SAML Responses, you can check out this link.
Basically, this SAMLResponse is the proof from OneLogin that John is logged in on their side and has permission to access Salesforce.
The IdP sends this response to the User Agent.
Step 5: Request Assertion Consumer Service / Browser Sends The Form To Salesforce
The User Agent sends a POST request to the Assertion Consumer Service URL. This is a specific endpoint that the SP has for verifying authenticated users.
The SP could compare the public certificate it has stored on its back end with the XML Signature of the document it received from the IdP to verify it is coming from the correct source. Another step could be decrypting the XML document if it was encrypted before being sent over.
This step is about the SP verifying that the user has been authenticated by the IdP.
In our example, Salesforce confirms that OneLogin has logged in John and given him permission to access Salesforce. Salesforce would create session credentials for John and probably store them somewhere (e.g. in a cookie or local storage). In this way, John could have access to Salesforce for a period of time before needing to re-authenticate at OneLogin.
Step 6: Redirect To The Target Resource / Salesforce Sends A Redirect To Firefox
The SP tells Firefox to go to the main Salesforce page that users visit after being logged in. (If a RelayState parameter was added, Salesforce would tell Firefox to load the deeper page that John initially requested.)
Step 7: Request The Target Resource At The SP Again / Firefox Requests The Main Salesforce Page
The User Agent requests the target resource at the service provider.
Firefox tries to access Salesforce.
Step 8: Finished! / Respond With Requested Resource / Salesforce Allows John In
Success! John is logged into the SP, and anything he wants to access is open season (assuming he’s authorized to access it).
Why Does This Matter
John just did ninja log in magic.
He was able to access Salesforce by logging into OneLogin.
And John can log into multiple other services as long as they are set up to handle SSO with SAML by Nike. These other services aren’t sharing session information either. Each session John creates is unique to that service.
That is the power of SSO with SAML.
Summing It What We’ve Learned
We’ve covered what SSO with SAML is and gone over the two ways of implementing it: IdP-Initiated and SP-Initiated. We’ve also shown a couple examples of what it looks like in practice.
There’s plenty more to learn about the topic, and hopefully this was a nice introduction. Thanks for reading, and if you have any questions, feel free to leave them in the comments!
