SAML 101: How it works

Bart Hendrickx SmallPosted by Bart Hendrickx

In my last post, I wrote about what SAML is. In this one, I’ll offer a use case to put it into context. There are a number of scenarios where SAML can be used, but I will stick toSSO3 login (authentication) that is initiated by the service provider. I’ll use Questionmark OnDemand as an example of a SP that can work with SAML. Our fictitious customer has an identity provider that is internally hosted behind a firewall, inaccessible from the outside world. Users at the customer’s company can go on the Internet; therefore, they can also take Questionmark OnDemand assessments.

User Jane Doe wants to connect to Questionmark OnDemand, to take an assessment that was scheduled to her. She browses to her company’s OnDemand area, which had been set up to authenticate via SAML. Through the federation metadata, Questionmark OnDemand knows which identity provider to ask for those authentication details. But it cannot talk to the IdP directly. Instead, it creates a SAML request which the web browser passes on to the IdP. Jane Doe’s computer is on the internal network and can access the IdP. The request is forwarded to the IdP, which accepts it because it knows about the service provider (SP), i.e. the customer’s OnDemand area—also possible thanks to the federation metadata.

Jane Doe is already logged on to the IdP: she opened her company’s intranet page this morning, which required her to authenticate, and that session is still active in her browser. So when the IdP gets a request: “Who is this user?”, it already knows the answer: “This is Jane Doe.” The IdP prepares a SAML response and includes a number of attributes, such as Jane Doe’s email address and hire date. All those data form an assertion, which is part of the response.

Again, Jane Doe’s browser plays a key role. It receives the SAML response with the assertion from the IdP and passes it on to the customer’s OnDemand area, which then reads the response. The OnDemand area confirms that this information comes from its trusted IdP and sees that this is Jane Doe. and that an assessment has been scheduled to her. Jane Doe now has access to the OnDemand area and can take the assessment.

For Jane Doe, this all happens seamlessly. She may see her browser redirect to other URLs a few times, when it is relaying information from the SP to the IdP and vice versa, but the entire process usually only takes a couple of seconds.

In a future post, I will explain what SAML requests and responses do and do not contain. Stay tuned!

SAML 101

Bart Hendrickx SmallPosted by Bart Hendrickx

As I mentioned in my previous post on SSO, Single Sign-On: Who’s Involved?, we’ll take a look at SAML to understand what it is and how it’s used with SSO. In this post I’ll explain what SAML is, and I will offer an example use case in my next post.

Webinar

So, What Is SAML?

SAML, or Security Assertion Markup Language, is a protocol that allows systems to exchange authentication data on users. (It facilitates other use cases as well, but I will focus on authentication.) What does that mean? It means that one system can ask: “Who is this user?” and another system can answer: “This is Jane Doe.” As I mentioned in my post previous post, I am talking about the service provider (SP) and identity provider (IdP) respectively.

Service providers (SP) in this context can be any software system with which you can do something, such as sending and receiving email, tracking projects or delivering assessments. Similarly, an identity provider (IdP) can be any software system that contain data on users that you can use to determine who those users are.

If you manage an SP, you probably don’t want just any IdP telling you who someone is. You will typically trust only one or a few IdPs. And if you are in charge of an IdP, you will likewise prefer to send user data only to those SPs you know and trust. To accomplish that, the SP and IdP exchange data allowing them to establishing a trust relationship. Those data are often called federation metadata, federation referring to the fact that there is an alliance between the different systems.

SAML is a popular protocol to set up such federations between service providers and identity providers. Look up SAML in your favorite search engine and you will get many results. One of its advantages is that it is extensible, meaning that you can exchange information that is relevant to your situation. For example, do you have an IdP that stores the hire date for an employee (or enrollment date of a student)? Do you want to share those data with an SP so that it can decide whether the user is allowed to access a certain resource? Then you can set up the federation in such a way that the IdP will send an attribute for hire (or enrollment) date to the SP.

Another advantage, and it is a huge one, is that SAML can be used in situations where the IdP and SP cannot talk to each other, for example because they are on different networks. You may have an IdP running on your internal network, behind a firewall. Your SP may be available in the cloud, as is the case with Questionmark OnDemand. The SP cannot talk to the IdP because it cannot “see” it. However, that’s not a problem for SAML. In my next post, we’ll take a look at a typical use case so we can see the practicality of using SAML with SSO.