An introduction to Federated Identity Management

Federated Identity Management is a set of techniques and standards destined to make users', developers' and administrators' lives easier. The goal of this presentation - and, we assume, your motivation to read it - is to understand what specific problems it solves and how it achieves that objective.

To better follow this explanation, it is important that the reader be familiar with the basic concepts behind public key infrastructures and identity management; if you haven't done so already, we recommend reading our introduction to PKI.

You may already be familiar with Alice, whom we will use to illustrate our examples. She works for Company A, a mid-sized business that produces landing gear for large aircraft. Landing gear systems are very complex pieces of equipment, and they integrate into even more complex pieces of equipment. Alice can't do everything by herself; her work demands that she collaborate and exchange information with many people.

Authentication

Today, Alice needs to access Document X, a file that contains specifications and parameters for the landing gear she is currently designing, dubbed Project Z. That document is stored on a company file server that she can access through the company network.

Traditionally, to access the file server, she would need to enter a username and password. This tells the server who she claims to be (the username), and provides it with a certain amount of proof of that fact (the password).

If Alice's company has a PKI in place, the file server may use Alice's certificate to establish who she is. This could be done, for example, by encrypting a random string of characters with Alice's public key and sending her the resulting ciphertext; she can then decrypt it and return the plaintext to the server. Since we take for granted that Alice is the only one with access to the corresponding private key, a successful exchange can be accepted as proof that the server is indeed talking to Alice.

Whatever method is used, the file server wants to establish one thing: the person trying to access it is the person it knows as Alice. This process, proving who you are (or, in more technical terms, proving the identity behind an action), is called authentication.

Not all authentication methods are equal; specialists tend to qualify them as weak (for example, username/password), strong (certificates, challenge-response tokens, fingerprint readers...), very strong (a combination of the previous), etc.

Permissions

However, authentication isn't everything. Through it, the file server has established that the person trying to access the Document X is Alice. But is Alice entitled to access Document X? To answer that question, the file server needs to be provisioned with detailed listings that establish which users have permission to access which documents. This concept, permission, is a very important one; without it, authentication is pretty useless. Conversely, permissions without reliable authentication are just as pointless.

Creating those lists can be a painstaking exercise; updating them can be even worse. Yet, it needs to be done, since the best authentication and encryption in the world won't help you if your permissions are not accurate and up-to-date. Project teams change, people get laid off, company policies evolve; the workplace is a dynamic environment, and security needs to keep up to adequately reflect its needs.

Attributes

Fortunately, there are ways to help with this exercise. A fairly simple improvement would be for the file server to assemble users in groups and assign permissions to groups instead of individual users.

For example, let's say that all people working on Project Z should have access to Document X. The file server's administrator configures a simple permission for Document X: "accessible to members of the group All People Working On Project Z". All that's left is to create a group named All People Working On Project Z, list all people working on Project Z in it (including Alice), and you have yourself a valid access.

Of course, for one user and one document, this is probably not worth the trouble. However, when you have dozens of users joining and leaving Project Z, and thousands of files, it very quickly becomes a huge time-saver, and dramatically simplifies the process. And since the worst enemy of security is complexity, simplicity is definitely worth pursuing.

Let's take this one step further. Over the course of her workday, Alice also has to access the room where people are working on Project Z. Imagine this is done via a door equipped with an electronic lock and keycard reader. This situation is similar to the previous one with the file server; authentication is made via the keycard ("this is Alice") and a permission, usually on a centralized server, states that Alice can access this room ("Alice can open this specific door"). Permissions can again be made on a door-by-door and person-by-person basis, or an All People Working On Project Z group can be created.

All in all, Company A's various administrators can end up building a lot of identical All People Working On Project Z groups. When Alice stops working on Project Z to move on to her next project, that could mean a lot of places where Alice's name needs to be removed from that group.

What if, instead of having Alice added and removed from a multitude of All People Working On Project Z groups, we simply replaced this with an "Alice is part of Project Z" statement that would be communicated to the various services? Part of Project Z would be an attribute of Alice, something that characterizes her. Other attributes could be, for example, Employee of Company A and Female. When she leaves Project Z, that attribute would simply be removed from her attribute list. The Female attribute is more likely to remain stable, but in this day and age, you never know.

Now, all we need is somewhere to get those attributes from.

Service Providers and Identity Providers

A system that uses attributes to make decisions about what an authenticated user can or can't do, such as the file server and the electronic lock system at Company A, is called a service provider. These service providers need to get attributes from a source that is:

authoritative (i.e., that is in a good position to know about those attributes)
able to communicate this information in a reliable manner (ideally, with integrity and confidentiality)

At Company A, a good example of an authoritative source would be the Human Resources department. They are very well-placed to know if Alice is an employee of Company A, and what projects she is currently working on. They are probably also privy to enough personal information - including face-to-face meetings - to establish her gender. All they need is to set up a server which can distribute that information upon request; the server also needs a private key and a certificate, since service providers will need to make sure the information is indeed coming from the right source.

The formal name of such an "attribute source" is identity provider.

There doesn't have to be just one identity provider in Company A's environment; Project Omega can have its own, which would be authoritative on who has the Part of Project Omega attribute. Of course, service providers need to be told by their administrators which identity provider they must trust as a source for which attribute.

Another characteristic of identity providers is that they don't necessarily communicate directly with the service provider. Sometimes, the attribute is signed and packaged in a token, which is then handed over to the user whose identity this attribute is associated with. That way, the user can control exactly what attributes are passed to what service providers. The token can then be transmitted by the user to the service provider.

So how does this all work together? Here's an example, using our previous file server case:

Alice requests Document X from the file server
the file server asks "Who are you?"
Alice replies "I am Alice, here is my certificate" and sends her certificate
the file server recognizes the certificate is signed by Company A's CA, which it trusts; it therefore accepts the enclosed public key as Alice's
the file server generates a random sequence of characters and encrypts it with Alice's public key
the file server sends the encrypted sequence of characters to Alice and says "If you are really Alice, you should have Alice's private key; use it to decrypt this and send me the reply"
Alice decrypts the sequence of characters with her private key and sends the result to the file server
the file server verifies that the sequence of characters matches the one it generated; a successful comparison confirms that the person at the other end of the communication channel is indeed Alice
the file server checks the permissions for Document X; they state that people who have the attribute Part of Project Z have read-write access to it, and people who have the attribute Part of Project Omega have read-only access to it
the file server has the information that it should trust the HR identity provider as authoritative for the Part of Project Z attribute, and the Project Omega identity provider as authoritative for the Part of Project Omega attribute
the file server asks the HR identity provider "Does Alice have the Part of Project Z attribute?". This query is signed by the file server.
the HR identity provider verifies the signature; a successful verification leads to its acceptance of the query (since identity providers don't necessarily provide information to just anybody...)
the HR identity provider checks its internal lists and replies "Alice has the Part of Project Z attribute". This reply is signed by the HR identity provider.
the file server verifies the signature; a successful verification leads to its acceptance that "Alice has the Part of Project Z attribute"
the file server follows the same process with the Project Omega identity provider, but this time concludes that "Alice does not have the Part of Project Omega attribute"
the file server, now knowing that Alice has the Part of Project Z attribute, concludes that it can allow read-write access to Document X
the file server tells Alice "You have read-write access to Document X, enjoy"
Alice enjoys.

Yes, that is a fairly complex process. And since a couple of gory details were glossed over, reality will be even more complex than that. However, once the pieces are in place, it can be extremely flexible, efficient, cost-saving, time-saving, and secure.

Federated Identity Management

It gets even better.

The next day, Alice needs access to Document Y. Document Y contains the detailed description of the communication protocols Project Z's landing gear must use to send tire pressure information to the aircraft it is attached to. There's only one problem - Document Y is on a file server located at Company B, which assembles the aircraft.

Again, the file server's administrators could painstakingly configure the permissions for each file and state that Alice-at-Company-A can access Document Y. But Company B knows very little about Alice; should she be assigned to another project or leave Company A, it could take a long while before the news reaches them.

However, if Company B's file server is configured as a service provider, it can very easily offer the service and circumvent those issues. Appropriate rules such as "people who have the Part of Project Z attribute have read-only access to Document Y" and knowledge that Company A's HR identity provider is authoritative on the Part of Project Z attribute will do the trick; no need for Company B to be kept appraised of Alice's current status.

The management and use of a user's attributes becomes decentralized and spread across multiple security domains while all being linked to a single identity - this is what federated identity is about.

We hope you have found this presentation enjoyable; if you have any questions or comments, we would love to hear them. Please feel free to contact us.