SSO

We implement Single Sign-On (SSO) in many day-to-day authentication technologies. As the name suggests, SSO allows users to login or access multiple systems and services by providing credentials only once, just as we saw in Kerberos. Because of that, SSO is a “transitive” form of authentication, allowing users to access services in other domains so long as their is a transitive trust.

Having SSO is great because it eliminates the need to remember multiple login credentials. From a security perspective, SSO also limits the possibility of users writing down their passwords. And from an administrative perspective, it makes things a lot easier.

Transitive Trust

As I mentioned above, SSO is a form of transitive authentication. On any LAN using Microsoft Active Directory (AD), there are many domains, all consisting of parent domains and child domains. Domains fork apart and extend until they create what’s called a “forest.” In these domains are users/clients and network resources (all called “objects”). Each domain is controlled by one central server called a Domain Controller (DC). This server is running Active Directory Domain Services (AD-DS). The DC’s primary purpose is authenticating users and authorizing users to access network resources (if they are allowed). DCs use the Kerberos authentication protocol and LDAP to do this.

By examining the forest below, we can see how transitive trust works.

The parent domain in the forest above is thecybersecurityman.com. It has forked into two child domains: training and blogs. Each child domain has a two-way trust with the parent domain. Therefore, thecybersecurityman.com trusts training and in vice versa. Also, thecybersecurityman.com trusts blogs and in vice versa. However, training and blogs do not have a direct trust in each other, but because of the transitive trust, the child domains do end up trusting each other. Training trusts blogs only because it knows its parent (thecybersecurityman.com) trusts blogs. And blogs trusts training because its parent (thecybersecurityman) trusts training. Basically, they came from the same parent; therefore, they trust each other. So, if a user who is logged in to the training domain wishes to access a server or object in the blogs domain, that user can do so because of the transitive trust relationship. If we didn’t have transitive trust, we would have to create a whole separate user account in the blogs domain (and for every other domain the user wants to access resources in). This means users would be required to remember many, many login credentials. But, with SSO and transitive authentication, we only need to remember one set of credentials. For example, the DC in the training domain, will use Kerberos (an authentication protocol with SSO capabilities) to accept the user’s credentials and grant the user access to the server in the blogs domain (only if the user has the right privileges set).

Active Directory Federation Services (AD-FS)

SSO systems also connect totally different or non-homogeneous environments together through what’s called a federated identity management system. Unlike AD-DS, which has an organizational boundary, AD-FS does not. Therefore, we can connect two organizations together by what’s called a “federation trust.” Take a look at the example below.

In the diagram above, we can see that the Resource Partner Organization trusts the Account Partner Organization through what’s called a “federation trust.” This means that the Resource Partner Organization trusts the Account Partner Organization to authenticate and use its resources. Here’s how this works:

From the numbers in the diagram above:

An External user accesses a web application by logging onto that web application on the Resource Partner Org. They type that URL into their browser and attempt to use that resource. The external user is not authenticated yet.
Because it’s a resource in a Resource Partner Org., the external user will have to hit a Resource Federation Server in the Resource Partner Organization. That Resource Federation Server is going to send the external user to the Account Federation Server in the Account Partner Org.
The Account Federation Server will get a token containing the external user’s credentials and tying those to a “claim.” Notice the arrow between the Account Federation Server and the DC running AD-DS.
The token will be passed back to the Resource Federation Server identifying the external user attempting to communicate and his claims.
Those claims get mapped to the resources in the Resource Partner Org. and sends the external user to the Web server to actually get access to the application he wishes to access.

As you can see, the user had to only remember his login credentials to get access to another resource inside another organization that crossed his own organizational boundaries.

However, it’s just a tad bit more complicated than that. There’s actually a little more to it that I can explain in detail in the next section.

Security Assertion Markup Language (SAML)

SAML is an Extensible Markup Language (XML)-based data format used on Web browsers that exchanges authentication and authorization data between two entities (just like in the AD-FS example above). Imagine having two Web sites hosted by two different organizations. If these two organizations didn’t have a federation trust between them, you would have to remember to different login credentials for each Web site. But, if the two organizations trust each other as a federated identity management system, users can authenticate to one Web site and not have to re-authenticate to the second Web site. SAML is able to provide this authentication mechanism to one Web site without that Web site having any of your authentication information.

There are generally 3 pieces that are needed to create this association for authentication.

Service provider: This is the organization providing the capability we need access to, and we’ll call it a resource server. In the AD-FS example we set up earlier, the Resource Federation Server is the service provider that is providing access to the Web server.
Requesting Client (principal): This is the user that needs access, often from a Web server.
Identity Provider: This is something that has all the authentication information, like username and passwords. In SAML, we refer to them as the identity provider because they contain all the identities and login credentials. This will be an authorization/authentication server. In the AD-FS example we set up earlier, the DC running AD-DS in the Account Federation Organization is the Identity provider that stores user authentication information.

So, let’s go back through the example again, but this time, we’ll include the use of SAML:

An External user accesses a web application by logging onto that web application on the Resource Partner Org. They type that URL into their browser and attempt to use that resource. The external user is not authenticated yet.
Because it’s a resource in a Resource Partner Org., the external user will have to hit a Resource Federation Server in the Resource Partner Organization. That Resource Federation Server is going to send the external user a “SAML request” and redirect the external user to the Account Federation Server in the Account Partner Organization.
The Account Federation Server will get a token containing the external user’s credentials and tying those to a “claim.” Notice the arrow between the Account Federation Server and the DC running AD-DS. This DC is the identity provider. The DC is then going to decide if the authentication credentials the user entered earlier were correct. The DC stores the user’s credentials, so it should know if it’s valid or not. If the authentication is successful, a “SAML token” is generated. This SAML token is digitally signed and encrypted by the DC.
The SAML token will be passed back to the Resource Federation Server identifying the external user attempting to communicate and his claims. Basically, the external user presents the SAML token to the Resource Federation Server that is digitally signed, which verifies that the authentication provided by the external user was correct.
Those claims get mapped to the resources in the Resource Partner Organization and sends the external user to the Web server to actually get access to the application he wishes to access.

Conclusion

Today, we see federated identity everywhere, most noticeably in what we call single sign-on. With SSO, you can log into your Gmail and then open up YouTube in a different tab, for instance, and you will STAY logged in. It all hinges on a central domain verifying the status of each user as they move across sub domains.

References:

Gibson, D. (2017). CompTIA SECURITY+ Get Certified Get Ahead SY0401 Study Guide. Virginia Beach, VA: YCDA, LLC

Microsoft Virtual Academy. (2013). Understanding Active Directory [Lecture Slides]. Retrieved from https://mva.microsoft.com/en-us/training-courses/understanding-active-directory-8233?l=aErw3QJy_6904984382