I’m sure that many of our Engineers that listen to this show can agree on one singular thing: we are all eternally curious. If you give an Engineer a black box, they’re going to pry it apart. They’re going to wedge a spudger down in there and get at what makes this strange contraption tick. And, even if they can’t put it back together in the end, what they learn from this exercise is far more valuable than ever just possessing a black box.
This week that curiosity has led me to take apart what was once a black box in my mind. That black box is something called the Security Assertion Markup Language, or SAML. For the longest time I knew the acronym, what it stood for, and what it did. But, I didn’t know how it worked. Now, you will learn its secrets right along with me. But, first let’s go over a few basics to get our bearings.
What is it used for?
That’s simple, Engineers. It’s used to provide federated authentication and authorization for identities, just like Wikipedia tells me so.  The beauty of this system is it allows you to keep your identity provider separate from your service provider. This concept is important. If we think back to last week and the week before when we discussed software defined datacenters, you have to authenticate to that service provider somehow. Sure, you can make accounts within AWS or Azure and have users login that way. But, if you’re a business and you already have an Active Directory you probably don’t want reinvent the wheel in one of these Service Providers. You probably want to leverage the identities you have already. You put a lot of work into that database. Duplicating it would be a lot of work, not to mention cause a huge burden on the poor Engineer that has to maintain parity between the two. This is where SAML comes into play.
Although, before we get into how it works we have to get something out of the way. You may have caught it when I mentioned the terms Service Provider and Identity Provider earlier. We need to explain what they are. A Service Provider is the entity that requires authentication from an Identity Provider to grant authorization to a user. Are you starting to see how these two are intertwined? The Identity Provider does the heavy lifting of authenticating a user and knowing what they’re authorized to do. It then sends this assertion to the Service Provider. Think of Active Directory with Active Directory Federated Services (ADFS) as an Identity Provider and think of AWS or Azure as a Service Provider, at least for this example. The lines can get blurry, so try to keep this configuration in mind going forward.
SAML Assertion 
Let’s talk about that Assertion term next. A SAML Assertion is an XML document that the Identity Provider sends over to the Service Provider that tells the Service Provider what the user is authorized to do. This is the file type on which this entire system is built. There are three types of Assertions, though. We should discuss them first.
- Authentication – This assertion proves the identification of a user and provides the time the user logged-in. It also provides the method of authentication, such as Kerberos, 2-Factor Authentication, etc.
- Attribution – This assertion sends the SAML attributes to the Service Provider. A SAML attribute is a specific piece of of data that provides information about the user.
- Authorization Decision – This assertions proves that the user is authorized to use the service or if the Identity Provider has denied the request. A denied request could be due to a bad password or a lack of permission to use the service.
How SAML Works
With all of that out of the way, we can get to the actions behind the mechanisms that drive the SAML process. First off, in order for all of this to work, both the Service Provider and Identity Provider have to have the same SAML configuration. In order to understand this process, let’s look at an example using AWS.
The process goes as such :
- A user signs into their Windows computer first thing in the morning.
- The user then browses to a special local page located on the LAN which is served by Active Directory Federation Services (ADFS).
- This local page authenticates the user against the Active Directory Service.
- The user’s browser receives an Authentication SAML assertion from ADFS.
- The user’s browser sends this assertion to Amazon Web Services.
- AWS uses the AssumeRoleWithSAML API and requests temporary credentials. It then creates a new sign-in URL for the AWS Management Console and sends it to the user.
- The user receives the URL and redirected to the AWS Management Console.
Everything happens transparently for the user. This is the basis of what we commonly refer to as Single Sign-On, or SSO.
So, now we know more than what SAML is, we know how it works. It should be mentioned here, that while OAuth and OpenID are similar, they are not the same as SAML. They work in different ways. Some of our Engineers may recall back on Episode 38 we mentioned OpenID and OAuth briefly while talking about David Recordon. OpenID and OAuth are what you use when you use Facebook or Google to authenticate to Service Providers that allow it. AWS allows this mechanism, as well.
SAML allows for more control over the entire process for Enterprises. That is why I felt it was more appropriate to discuss SAML over OpenID or OAuth. SAML is far more common in Enterprise environments.
Now that you know how SAML works, what black box should we pry apart next? Where will our collective curiosity lead us? Come tell us in our Discord. We want to see you there.