One of the most historically difficult problems to address in IT is usernames and passwords for multiple applications. We all have a multitude of accounts we have to manage. Bank accounts, social media, email, work accounts, cloud storage, and every other system we use relies on usernames and passwords to “authenticate” who we are. There are a number of different solutions for this problem, but the most user friendly method is a technique called “Identity Federation.” Now that the cloud is becoming more important to business functions, IT needs to simplify the relationship between devices that access corporate resources and the resources themselves.
What is Identity Federation?
Federation is a very technically complicated subject that involves a lot of different things. It allows multiple organizations to accept the same login credentials to access applications that have entirely separate infrastructure and account databases. This is referred to as Single Sign-On, and it is used very heavily in Office 365 and other online applications.
The most common example of this is linking a social media account like Facebook, LinkedIn, or Google to some other application. Whenever you “log in” with Facebook and others, you’re using a federated login relationship set up between the application or website and Facebook to facilitate and simplify login. Essentially, the app will accept your login for Facebook instead of forcing you to create a user account on their network. The relationship between that app and Facebook is set up ahead of time in such a way that allows A user to log in to Facebook, then Facebook will talk to the app to let it know what the username is and some pertinent information about that user for the application to use. This would include things like your first or last name, email address, and other things.
How Federation Works
Federation can be difficult to understand because there are several different standards. The most popular are SAML, OAUTH, OpenID, and WS-Federation. I won’t go into any details about each standard, because they all boil down to the same end result; using one application or organization’s credentials for access to any number of other applications or organizations.The ability to accomplish this type of thing is generally referred to as Single Sign On (SSO). There are, however, additional types of Single Sign On that are not based on Federation. Federation’s primary focus is allowing SSO to work between organizations without a common database of usernames and passwords. This is extremely useful when you want to simplify access over an untrusted network like the Internet.
The Basic Pieces
As I mentioned, there are many different ways to set up federation, but they all have similar major pieces. First, there is an Identity Provider (IdP). This is where the accounts are stored (Identity is another term for user account, or any piece of information that validates that you are you). In Microsoftland, this is going to be Active Directory so I will use that in my examples here, but there are other methods of storing accounts. Don’t think you are stuck with Microsoft here. The second piece is the Relying Party (RP). This is the environment that will be accepting logins from the IdP.
The third piece is the trust relationship, usually called the Relying Party Trust (RPT). The RPT is set up ahead of time and essentially configures the application to accept login information from the IdP.
The final piece is the Token. A token is an encrypted package of information about the user that is generated after they authenticate against the IdP. This information includes information about the user that the application needs or requests to do what it does. Most of the time this is the user’s account name at minimum, but can include any information stored in the IdP’s database.
All of these pieces fit together with a federation server that manages the relationship between organizations. The federation server will also generate tokens and communicate with the databases or applications inside each organization.
How the Pieces Fit Together
With the four pieces above, we can put them all together to build a federated login for our users. If you know the song, sing along. The IdP bone is connected to the Federation Server bone, the Federation Server bone is connected to the…you know, maybe a diagram would work better here.
Wow, that’s complicated. For now, just pay attention to the curved lines and you’ll note that each one represents a “trust” relationship. The federation server on the left (for this example, we’re using ADFS) trusts an Identity Provider (Active Directory) and will communicate with that to authenticate users. The federation servers on each side also trust each other in a Relying Party Trust. This relationship causes the federation server on the right (A SAML server) to accept authentication information from the server on the left. The federation server is trusted by the application to forward “Claims” to it. I’ll explain what that means in the next section.
The Federation Process in a Nutshell
Let’s look at the numbers in that complicated diagram. Each one represents a step in the federation process.
- The user attempts to access an Application of some type.
- The application forwards the user to the federation server on the right and requests authentication information.
- The federation server on the right forwards the user again, this time to the federation server on the left.
- The federation server on the left presents a login prompt to the user. Once the user enters a username and password (or some other form of authentication), the federation server will verify that information against the IdP’s database.
- If the authentication information is valid, the user is authenticated and a valid authentication response is sent to the federation server on the left. Once the federation server on the left (I really should have added numbers or letters to those servers…Oh well) receives a valid response from the IdP, it will read the user account’s information that is stored in the IdP and compile a selected group of “attributes” (Any information about the user. Usually their name, email address, and anything the application needs to function) into a token.
- The token is presented to the federation server on the right. That server reads the token. The Relying Party Trust validates the token and the attributes stored therein are compiled into “claims”.
- All of the claims are passed on to the application server for use.
- The application server compares the claims against its own back-end database of users to verify that the logged in user actually exists.
- The database responds with any additional information not included in the claims to the application.
Yes, Virginia, That Was the Nutshell Version
Federation is stupidly complicated, but is has to be because it allows a lot of flexibility. As long as the federation servers use the same standards, they will provide full authentication between any number of applications and user databases. Consider that very few applications share attributes with the multitude of IdP databases that can provide authentication through a Relying Party Trust. For instance, Active Directory has two different potential username formats that can be used, SAM Account Name and User Principal Name. While SAM Account Name is unique to Windows environments, User Principal Name is more universal. However, if the application uses email addresses for its user names, neither of those attributes will work, so the federation servers have to do a little work to get the application to accept the claims it is presented.
Is Federation Secure?
Yes, but it is less secure than having separate login credentials for each system you log into. Federation tends to make life easier for users, and most systems that make things easier for users will result in an overall decrease in security. In many situations, however, the cost of not using federation for Single Sign-On readily justifies the lowered security stance. Office 365, for instance, integrates with Active Directory Federation Services (the aforementioned ADFS) to allow companies to use their own Active Directory usernames and passwords to use any of the services provided in the Office 365 suite. This essentially cuts the administrative burden of using O365 in half by allowing central management of accounts. It, as mentioned, also makes life easier for users, who don’t have to remember and reset two different passwords when their employer moves to O365. The only other alternatives for doing this, password sync and pass-through authentication, have significant downsides that make them slightly less secure than O365 in some instances.
With that said, there are many different techniques that can exploit the use of Tokens used in a federated login. For instance, if an application isn’t written properly, it is possible to simply hit the back button to return to a screen where someone was logged in and reuse the token data from that session to act as a user who has already logged out (Office 365 isn’t vulnerable to this type of thing, luckily). Other attacks can take advantage of users who don’t pay attention to what they are connecting their accounts to. Think of the numerous Facebook hijacks that start with a request to connect your Facebook account to an application. Once that authorization is granted, a malicious application can remotely lock a user out of their account or just automatically read everything the user has stored in their Facebook Profile and make use of it in marketing campaigns or for more nefarious purposes.
So What Now?
My purpose in writing this isn’t to teach people how to use federation or properly configure it. This post is a simplified explanation of how federation works so normal people can understand what’s going on when they use their social media accounts to log in to other applications. I also hope to provide a good foundation of knowledge for IT Professionals who find themselves needing to deal with federation. It really is a great tool, despite its flaws and vulnerabilities, but as always, it’s extremely important to be careful about how you use federation or you can unwittingly expose important, private information to people you really shouldn’t “trust”.
