This is the first of a series of article about identity federation. It is an updated version of an older series that was hosted on the EMC community site but since publishing this is a read-only thing...
This series should give a overview about Identity Federation actually is, what it is used for and what we (RSA) do with it.
In this series of articles I'll plan to go deeper into the standards, use cases and RSA's implementations of them.
Most articles will first describe a certain aspect of a standard or use case and then show how e.g. RSA Via Access could be used to implement it.
There will be a number of blog posts - each looking at some specific topic in more detail. Here is the planned list:
- Introduction into ID Federation (this post)
- SAML Part 1: Overview
- SAML Part 2: NameID Mapping and Formats
- SAML Part 3: Authentication Statements
- SAML Part 4: Attributes
- SAML Part 5: Security
What are we trying to solve with ID Federation?
In my opinion the most fundamental problem that ID Fed solves is:
How can the state of an identity be securely transferred from point A to point B?
To be a bit more specific: The state mentioned above could be one or all of:
If and how the identity identified itself to point A
What/who is the identity at point A (and maybe at point B)
Up-to-date profile information about the identity
Too abstract? Let's give the participants names and provide some examples
Point A and Point B are just that: different entities that either know something about an identity (A) or like to know something about the identity (B).Generally Point A is called Identity Provider, IDP or Asserting Party whereas Point B is called Service Provider, SP or Relying Party. The individual could be either a real person or a abstract service (e.g. a server or program that needs to communicate to another server/program). Assume an individual is authenticated at the IDP. The IDP could tell the SP that it knows who the individual is and e.g. a attribute of the user. The SP could take this information to provide services to the individual. An important aspect of this is that the SP trusts whatever the IDP tells it. That 's the point: the SP "outsources" (at least partly) things like authentication, profile management etc. to the IDP. The SP may have chosen to outsource these things either because it doesn't want to be bothered with them or simply can't do them on it's own.
Let's leave the world of IT a second and explain this with real life examples
Entering a foreign country
Assuming it's your fist visit to country B the only piece of authentication is your passport.At the border they use the passport to find out who you are (in case Interpol likes to have a chat with you) and if the profile information (picture, size, eye color etc.) matches your appearance. This maps to:
- Trust in the issuing country (the trusted third party) that they issued the passport for somebody they know. "Authentication" is done remotely.
- Use profile information collected and vetted for by the issuing country
Renting a movie
The rental place knows you by name. If you walk into the store and they recognise you.However if you want to rent a "18+" rated movie ("R" rated for you US colleagues) than they are obliged to check how old you are by looking at your divers license, passport or ID card. This maps roughly into:
- Authentication is done locally (they know your face)
- Profile validation (you are older than 18) is done by checking a document issued by a trusted third party.
Getting a drink in a bar in most parts of the USA
THey guy or girl behind the bar doesn't really care who you are as long as you pay and can give proof that you are old enough. This Maps into:
- Order a alcoholic drink
- Show the barkeeper a trusted photo ID. This could be your passport or driving license issued by a third party. This document contains your birth date.
- Barkeeper does advanced math to determine your age based on your birthdate
- You get a drink (or not... sorry kid).
No authentication done either locally or via trusted third party - they don't have to know who you are just how old you are.
In contrast here is how you get a beer in Germany:
- Look old enough and order one
Back to IT - Some examples of ID Federation
Portal uses external IDP to authenticate users it doesn't know locally
A good example would be a customer from Europe back when there was a bit of craze about swine-flu (or bird-flu - can't remember which animal it was):A portal that handles the issuing of flu vaccination vouchers needs to be accessible not only for a bunch of users that can be authenticated locally with password or RSA SecurID but also by doctors. The doctors don't want to / can't use SecurID but they do already have a SmartCard they use to authenticate to some other systems. Instead of configuring the flu portal to work with the SmartCards and to know every single doctor (they do need an account of course) with all the profile information (name etc.) federation was used to handle all that. The doctors do authenticate to the foreign system (the IDP) as they use to already. If they want to access the flu portal (the SP) they get federated to it.The portal will know who they are and some profile information (e.g. Name) and therefore can provide whatever service a swine/bird-flu portal must provide. The advantage of using federation here were clear:
- No cumbersome registration of the doctors at the portal.
- Profile/account registration is not needed
- Handling of all the dirty bits of certificate authentication (revokation etc.) is not needed - the IDP takes care of that.
- If something changes on the other side (name change, new certificate, even new CA) it doesn't matter
- The doctors don't have to change the way they work. They simply see the swine/bird-flu portal as another source of information that is available to them.
Company likes to provide the employees SSO into a external training portal
Without federation the users would need to authenticate again when accessing the training portal - even if it looks like an internal resource it feels external with all the issues such as managing the password, profile information etc.
Additionally the information about who reports into whom is not at that training portal but only in the internal MS ActiveDirectory.
Without federation this information would need to be send to the training portal manually using some kind of batch job or maybe some form of agent that syncs the data into the portal every day.
With federation not only would the users have SSO but during federation the information about the user's manager could also be transferred.
This would then enable the managers to see which team members took the training already.
The company would be the IDP and the training portal the SP.
Here it get's a bit harder to understand because there is (hardly) any end-user involvement.
This is about one service communicating with another. No user interaction.
Webservice (SOAP) A likes to call webservice B.
B needs to authenticate A or even needs to know who told A to ask B to do something. In other words B may need to authenticate the service A and/or may need to know who originally called A and triggered the SOAP request to B.
Let's assume user X orders something from portal A. To fulfill the order one of the things that A needs to do is to tell webservice B to send a bill to X and service C to get money from X's credit card.
"A" could send a SOAP request to B telling B to mail a invoice to X. B may be an external service.
B should know who A is and if A is authorised. Federation could be used for the authentication part. A basically tells B "I'm A and I need a invoice with content abcd send to X".
An even stronger argument for identity federation in a web service environment is if a webservice needs to know who initially "pressed the button" that caused all those calls.
"A" needs to tell C that the user's credit card should be used to settle the bill. C not only likes to know who A is (that's almost a given) but likes to have proof that X really initiated all this.
"A" could send a SOAP request to C and use identity federation to proof to C that X really was the one that placed the order.
That enables C to really trust the request as well as maintain a good audit trail.
Granted: this use case is a bit harder to understand - especially if you're not into web services.