A couple of times recently I’ve had to explain SAML-based federation to people whose areas of expertise lie outside identity and security. After repeatedly drawing things in different ways on a whiteboard, I found myself working towards a real-world analogy.
It’s a bit tortured, and not exactly representative of the inner workings of SAML, but it gives the basics. For a real, technical explanation, the Wikipedia page gives a good outline, and hardcore nerds can read more at saml.xml.org… But if you’re interested in reading those, you’re probably not the right audience for this post anyway.
So, we’re trying to achieve federated SSO – that is, I’m a user at Company X, and I’m trying to access resources at Company Y. As the user, I don’t want a new set of credentials to manage at Company Y, and Company Y doesn’t want to have to deal with joiner/leaver for me. SAML allows us to solve this problem fairly easily – indeed in the case of some service providers (Salesforce and Google Apps as an example), this is trivial out-of-the box functionality for some SSO systems.
SAML federation occurs through a series of interactions between the two parties, after first establishing trust between them. So, on to…
Imagine I’m a consultant (I am, so it’s easy for me), and I’m going to be working on a client site for a while. We’re going to look at my interactions with my own employer (my identity provider) and that of the client, whose resources I’ll be using (the service provider).
Clearly, I can’t just turn up unanounced at the client’s site. There’ll be a series of meetings, swapping of business cards, probably some lunch… And then a contract will be signed. This contract will determine the length of the work order, and we’ll probably sign NDAs, and perhaps we’ll be given details of security behaviour (what to do on the first day, etc). The client will conduct due diligence, making sure (s)he knows our company, checks references and so on.
What we’ve done here is established trust between the two entities. They know who each other is, have contractual agreements on information sharing, and some basic protocol information.
Swapping tokens – authentication
So, now that we’ve arranged the work, on Monday morning I’ll turn up at the client’s office. Of course, the guy at the security desk has never heard of me. So firstly he asks me for some recognised ID, and I show him my passport. So now he knows I’m who I say I am – one might say I’ve used a standard protocol and token. But he doesn’t know that I really work for my employer, so a couple of things might happen. He could check in his computer system and call the security team at my employer, or call someone in his own organisation who’s already done this.
He’s now established I’m who I said I was, and that I belong in his building, he gives me a security pass for the building. It’s a temporary pass, obviously. It might be valid for the whole duration of the work order, or a shorter period. If the contract is a long one, he might want to periodically call up my employer to make sure I haven’t been fired – but probably not every day.
So, I’m authenticated at my employer with a token (my security badge). But the client doesn’t understand this so a shared token standard is used to convey this information to the client – my passport. On validating the token, the client needs to check that I belong to the partner and I’m not just a random, so they call up and check, in the same way SAML back-channel validation can occur. Once validated, I’m given a session token with the client/provider, which has a local expiration, and a periodic check against the partner.
The building pass he’s given me lets me into certain parts of the client building, based on the work I’m doing for them (as agreed with my employer). This compares to the pass I’ve got from my employer, which restricts me to access based on the job I do when I’m back at base – but the two cards are completely unrelated and disconnected.
Here we’re highlighting that my level of access on either side of the partnership are disconnected. My employer has agreed the work package with them, so they know what access to give me in their building based on that role. This is of course related to my role in my own office – but the access level given here is completely different.
So, that’s a high level explanation of how federation occurs, particularly with regard to SAML. I’ve found it a useful simplification for people who have no comprehension of how this stuff works – obviously it breaks down if you look more carefully! If you read this and can think of improvements, let me know.
Update: I had some debate with @paulmadsen regarding the ‘passport’ part of this. It doesn’t really work in the analogy – I was trying to convey the idea of the SAML token being something generated to a common standard, that both parties understand, and that’s not the same as the internal auth token necessarily. A passport is wrong since anyone can read your passport in the real world, but with SAML only the two endpoints can read it.