In Star Wars, they talk about “the trade federation” and we instinctively know what they mean. Separate autonomous planets, galaxies, civilisations etc. that bind together to give themselves a greater force for intergalactic trade than they would otherwise have.
Federations such as NATO, the United Nations, The European Union and so on, though they may be huge organisations, are made up of members and each member contributes to the federation in some way. A typical feature of these federations is that the members have organisational boundaries between them: in the cases I’ve given above, countries, planets, galaxies, civilisations and so on - but they all aim to achieve a common goal.
And so it is when we talk about federated digital identity. The aim is to create a collection of bodies who all have a common aim, typically to run a collection of applications, but who each maintain control over policy within their own organisations. They create, maintain and delete their own user accounts, set security policy, password policies, make their own decisions about what a user can and cannot access and so on. Sometimes the organisational boundary is obvious – a supplier and 3 customers: each is a separate company. NATO: each is a country. Sometimes it’s not so obvious. Why would an organisation set up federation within its own organisational boundaries? In the UK, the National Health Service is made up of many health providers; local surgeries, small hospitals, very large hospitals and so on. They all aim to provide the UK with a common set of health services, but each organisation is responsible for its own service provision, budget, policy, IT etc. These organisations-within-an-organisation may often want to maintain their autonomy and yet still contribute to the greater good of the umbrella organisation. Federated digital identity finds itself in these environments. The different departments within some organisations can be considered as having organisational boundaries between them.
Let’s take the simplest federation – between 2 organisations. Imagine one organisation is an aircraft manufacturer. Let’s call them “Doying”. The other is a general-purpose supplier. Amazingly they can supply everything from a $5 million aero-engine, to a $1 notepad. Let’s call them Bolls-Boyce.
In order to make things simple, Bolls-Boyce want Doying to be able to place orders directly in to their sales system. Their first attempt was a disaster that lost a lot of investor confidence. This is what they did:
Doying had 3 buyers who used Bolls-Boyce’s application to place orders. Once the application was configured to face the internet it was simple; Bolls-Boyce simply created user accounts for Sally, Jane and Emma. When they needed to use the application, the ladies logged on and placed orders.
But then it all went badly wrong. Sally was actually a bit of a slacker for Doying and she got fired. The trouble was that she was the buyer who placed orders for the aero engines every time they were manufacturing a new plane. She was very fed up about being fired, and to get her own back, she connected to the net one evening, logged in to Bolls-Boyce’s application using the username Bolls-Boyce issued to her and placed an order for six $5m engines; a $30m order!
Bolls Boyce were very pleased, had a big expensive party because of the large unexpected order. It wasn’t until the engines arrived on the loading bay at Doying that things started to go awry. Doying insisted they never placed an order. Bolls-Boyce went through their application logs and said “Aha! – we’ve got you. Your Employee Sally, placed an order on the 25th September and we have proof – get out of that one”.
Doying said “she wasn’t our employee when she put the order in – nothing to do with us”. By now, things had become a political nightmare between Doying and Bolls-Boyce. Bolls-Boyce put a freeze on supply of even minor items like nuts and bolts until Doying had taken delivery of their “order”. Doying had put a ban on ordering any major parts (like engines!) but were finding it difficult to carry on manufacturing operations because the simple things weren’t there to do the job. Production slowed for Doying and the stock price took a dive. For Bolls-Boyce with a load of capital tied up in 6 aero engines they didn’t have a buyer for, their production slowed. The whole sorry tale was played out in the public glare of the press. It was a scandal!
OK – now let’s take a look at what happened with Aerocab and engine company Bratt & Britney:
Let’s take Bratt & Britney’s application. It is “protected” by their Federation Service, which is responsible for creating security tokens that are passed to the application.
The Federation Service in Aerocab trusts the Aerocab identity store. This store might be Active Directory, eDirectory, Sun One Java Directory, IBM Directory, or it might be a database of user accounts based on Oracle or… anything. This federation service creates security tokens that are related to the users in the identity store. For Jane, it might create a security token that specifies her first name, last name, email address and job title for example.
There is also a special kind of trust set up between the 2 organisations called a Federation Trust. Aerocab knows Bratt & Britney is a safe place to send security tokens. Bratt & Britney trusts the tokens issued by Aerocab.
Typically when 2 organisations set up a federation trust, it involves more than just IT. IT is required to set up and configure the services, but there is a higher-level business agreement that also needs to take place. I’ll show why this is important a little later.
Now let’s take Sally on the same journey with Aerocab, her new employer! Once, before she gets fired, and once after she gets fired.
That “dance” created a security token from Sally’s organisation, Aerocab. Now we need to “unwind” the dance and get something back to the application. That's what the next bit is about:
So by setting up a federation trust, the creation, maintenance and deletion of user accounts is in the control of Aerocab, not Bratt & Britney. Security policies associated with these accounts are also under Bratt & Britney’s control. So for example, if Sally forgets her password, she calls the Aerocab help desk. If the password policy is for a 30 day expiration and requires 14 characters with at least one uppercase and one number, it is Aerocab that enforces the policy not Bratt & Britney. However Sally can still access the application in Bratt & Britney, a different organisation.
When the application receives the token from Sally, it does whatever crypto it needs to do on the token and then extracts the claims. In this case, it’s interested in the jobtitle claim and the department claim. It makes an authorization decision based on the claims in the token, rather than say, the groups she is a member of. This pseudocode shows the flexibility of using claims:
if jobtitle == “buyer” and department == “production” then access = true
You see, if using groups, there are probably already groups called “buyer” and “production” but it’d really need a new group called say, buyers_in_production. That’s the problem with a discretionary access control system and many such systems (such as kerberos) suffer from group-bloat because of this problem. Role based system give a little more control, but just simply examining a token and making an authorisation decision based on the claims within it is much more flexible. It can take in to account both group and role claims alongside other claims such as jobtitle, department, company, country. This is data that already exists on many user objects in identity repositories such as Active Directory, Novell eDirectory and so on.
But let’s just stop for a moment and think about what we’ve done above. We’ve definitely factored the authentication out of the application. In the case with Doying and Bolls-Boyce, the authentication was inside the application. We’ve successfully moved the authentication not only outside the application, but also outside the organisation with Aerocab and Bratt & Britney.
At first glance though, it seems the authorization (the what-you-can-do as opposed to the prove-who-you-are (authentication)) is still deeply embedded in to the application. For example the pseudocode above lives inside the application.
But with federation, a good deal of it can be factored out of the application and in to the federation service that sits closest to the application. In the diagram above, notice in steps 1 and 2, Bratt & Britney’s federation service receives a token from Aerocab and then creates its own token. Instead of copying the claims directly from the input token to the output token, it could perform a little logic on it:
if jobtitle == “buyer” and department == “production” then output_token:spendlimit = “$5m”
Perhaps somewhere else is the logic:
if jobtitle == “buyer” and department == “stationery” then output_token:spendlimit = “$50”
…and yet it still seems as though we’ve just moved the problem to a different place. OK, so the application’s authorization logic is now simpler but there are now 2 systems to look after. Isn’t this more complicated? Well, with just one application yes it is. But if there are many applications that want to use a consistent, universal authorisation logic, then it means claims transformation can be applied consistently across the organisation.
Another strong reason for having a federation service which is also capable of claims transformation is to allow for semantic differences. Imagine Bratt & Britney have “purchasers”, not “buyers”. By transforming the value “buyer” in to “purchaser”, the application can conform to Bratt & Britney’s internal standards. But it also means if Bratt & Britney start also supplying McDougal Donald, an aircraft manufacturer, with parts, then when their “shopper” turns up at the application, it’s a case of making a claims transformation for that particular federation and not having to add logic to the application.
OK – let’s get back to Sally. Well, she’s done a bad job with Aerocab and has to be fired again, which is a sad thing because she had to move all the way from the North West of the USA to Europe to get her job at Aerocab! When Aerocab fired her, they also disabled her account – standard practice.
When Sally got home she was so angry she thought she’d pull the same stunt on Aerocab that she pulled on Doying:
You can see in this scenario, it was the division of responsibilities that led to a better outcome. The supplier, doesn’t want to be concerned with user-management, password resets, security policy and so on. The customer-organisation wants to be in control of its users. It wants to determine staff roles and be able to very quickly draft somebody in to replace Sally without having to engage in cross-organisational processes like getting a new user created (as would have been the case in scenario 1: “In the days before federated identity”). All it does in this case is set the relevant claims to the correct values and the employee who now has Sally’s old role can place orders.
I said earlier that a business agreement sits above all this technology when setting up a federation trust. The federation trust is a simple configuration set up in which each side of the trust is informed about the other side’s service URLs, and a certificate exchange takes place for the exchange of signed and encrypted tokens. Most of the COTS products which do the federation have endpoints where federation metadata is published to make the whole process of setting up a federation trust easy for technologists.
But now think about the scenario from a business perspective. Because in the case with Aerocab, if Sally had placed an order for $30m worth of aero-engines, she would have most definitely been an authorised employee at the time she did it. Aerocab’s processes, if correctly followed, would not have let her place such an order unless she was indeed an employee. So you can see that Bratt & Britney are going to want to be assured, at a business level that the invoice will be paid if such an order gets placed. Or at least that there is some agreed financial remedy in the case of a mistake being made. It should be technologically possible to determine whether the error was made by a Bratt & Britney employee or an Aerocab employee and so the contractual negotiations will need to underpin all the technology that goes on.
You can probably also see that Bratt & Britney might naturally be quite nervous that Aerocab might just renege on their part of the bargain if it came to the crunch. So it is often a case that the partner’s business processes are audited. For example do Aerocab just randomly hand out usernames and passwords willy-nilly or is the process locked down and solid? One would give confidence in the setting up of a federation trust, the other definitely wouldn’t. Modifying applications, installing and configuring federation services can frequently take a tiny fraction of the time it takes to come to an oganisational/political/legal/financial/business agreement. However, once it’s in place it allows both organisations to respond quickly according to their own needs safe in the knowledge that they won’t affect the operations of the other organisation.
With all these tokens, redirects and authentication processes happening, there must be standardised ways of achieving this. They differ in minor details but all follow the basic flow I have detailed. Some protocols allow for smart or “active” clients (Windows Cardspace for example) that can query policy for a service and then take action based on the results. Others (most) use dumb or passive clients (usually web browsers) that are simply redirected by the servers. Some protocols require consent to be granted before information is released.
Probably the most confusing protocol for people new to federation is SAML. It’s because SAML addresses 2 things: a protocol and a token format. The SAML protocol uses SAML tokens. However other protocols also use SAML tokens. So a good question to clear up in your mind when somebody uses phrases like “SAML exchange” is to ask whether they are talking about a protocol exchange or just the token.
WS-Federation is another popular federation protocol that uses SAML tokens. Shibboleth is yet another protocol. Information Cards (Microsoft’s implementation is called Windows Cardspace) use a combination of protocols – WS-Trust, WS-MetadataExchange, WS-Security, WS-SecurityPolicy and others which are orchestrated together to move tokens from one place to another.
From Microsoft, the main technologies in this area are:
It looks like there’s a SAML protocol disconnect between the app you write using WIF and ADFS 2.0. Although the federation service supports SAML-P, WIF doesn’t. So what do you do in that case? Well, the good thing is that ADFS can perform a protocol transition for you. So in the example above – let’s imagine Bratt & Britney’s application is using WS-Federation (through WIF) and their local ADFS 2.0 Server (federation service) is using SAML-P, while it communicates with the application it’s using WS-Federation and while it’s communicating with Aerocab’s SAML server, it uses the SAML-P protocol. Because the information included in redirects and POST data is common to both protocols (such as the source URL, the target federation server URL, the POST data (the SAML token), etc) it is possible to extract the relevant information and switch protocols.
Here’s a quick couple of orientation diagrams that fit the Microsoft products in to the scenarios I have described:
The diagram above shows how things might work in a pure on-premise environment.
Below I show the application installed in to Windows Azure:
I hope this gives enough of an overview for you to understand the basics of federation.