You’ve probably visited a web site that provided authentication using a 3rd-party service, and it may have been using the Security Association Markup Language (SAML) to accomplish this. In this video, you’ll learn how SAML can be used to authenticate to one set of resources by using a completely different authentication provider.
<< Previous Video: LDAP and Secure LDAPNext: Identification, Authentication, and Authorization >>
Now that we use all of these different services in the cloud, it becomes a little bit cumbersome to create new security authentication every time we need access to a particular website. And you may have seen on a website that instead of creating a brand new account, you can authenticate to this website, if you have credentials on a third party website.
It’s very common to use a method like SAML, which stands for Security Association Markup Language, to be able to provide this authentication mechanism to one site without that site having any of your private authentication information. There’s obviously fills an important need. Authentication is such an important consideration for these services in the cloud, but of course, creating a separate authentication mechanism for every single website can be tedious for the end user.
And for the service provider there’s a number of security concerns for having all of this authentication information. Instead, using SAML allows the service provider to provide the services and an authentication provider to handle all of the authentication parts.
There are generally three pieces that are needed to create this association for authentication. One is the service provider. This is the person that’s providing that capability that we need access to. The other is, of course, you the client. You need to gain access to this service, and you’re usually doing this in a web browser.
And lastly, we have somebody that has all of that authentication information. In SAML we refer to them as the identity provider because they are containing all the identities and all of those login credentials.
Here’s how the flow of this authentication works. We are the client, and we need access to a resource server. So we’re going to access the application, and the application will then need us to authenticate. So it sends back a signed and encrypted SAML request, and we’re going to take that request and send it on to the authorization server.
At that point we’re going to provide our normal credentials to this third party authentication server, and that authorization server is then going to decide whether that authentication is correct. If the authentication is correct, it sends you back a token that has been digitally signed by the authorization server.
You then present that SAML signed token to the resource server. The resource server, of course, trusts anything that is digitally signed by the authorization server, and therefore, you then gain access to whatever resources you need on the resource server. This practice allows you to have a single login on an authorization server, but be able to access a number of different resources, all from different third parties.