Federation

  • Article

As you are moving to Web Services world one of the buzz words that you will hear time and again is "Federation". This is simply a security scenario that involves 3 parties to secure a Message. The 3 parties in the scenario are,

  • Client
  • Security Token Service (STS)
  • Target Service

This is very similar to Kerberos authentication. In a typical Federation Scenario, a client that wants to talk to a Target Service will first go to the STS and present its credentials and will ask the STS to issue it a token with which it can talk to the Service. The STS then issues a token to the Client which the client presents to the Service to gain access to the Service's functionality.

What the Client has effectively done here is to transfer its one set of credentials to another that the Target Service will understand.

One simple scenario is Microsoft Passport. Once you login to passport with your username/password then you can access other sites which accepts the passport credentials. All the other sites now don't have to know your username and password to authenticate you. They know you have a Passport ticket and that is good enough for them.

So, is Federation all about Single Sign On (SSO)? Not really. SSO is just one feature of Federation. Let's consider another scenario. Company A and Company B might come to agreement that all of Company A's employees can access certain resources inside Company B. Now, let's say both Company A and B has an Active Directory (AD) which contains credentials for all their own employees. Now to allow access to Company A's employees, Company B can create accounts for all of Company A's employees in its AD. As you would realize this is not a viable/scalable solution. Instead, Company B can ask Company A to setup a STS on its end that will authenticate its employees based on their credentials in AD and issue a new token that the Service at Company B will understand and also contains the permission set associated with that employee. Now there is a implicit understanding between Company A's STS and Company B's Serivce on how this token should look like and how to verify the authenticity of this token and so on. SAML (Security Assertion Markup Language) is a great option for the token that gets passed between the STS and the Service.

WCF has good support for Federation and SAML 1.1. The latest specification of SAML is SAML 2.0 which WCF does not support out of the box. You can create SAML 2.0 as a custom token using the extensibility points available in WCF. I will post more information about Federation and SAML later.