An Introduction to Windows Identity Foundation 4.5

WIF is used to externalize the user security from applications by using claims on enterprise level.It is to incorporate security in our enterprise applications in the same way we handle security in our daily lives. Let's consider an example from real world. You go to a skydiving center to enjoy the sport. Since this is a dangerous sport, you must be 18 years of age or older to partake. How do you think they verify the age? They check your Id and determine age. If you are 18 years of age on the day, you are good to go, otherwise, go home to your parents.



Now consider how we have been implementing the similar security in our application design. In our organizations we have hundreds of applications. Each application requires some sort of authentication because security audit requires so. So if I have rights on a few applications then I have to remember the credentials of all of these applications. There is no way I could remember all these passwords, so it is possible that the user would keep the same password for all these applications or would use some easy to use password. From the enterprise architect perspective, it is difficult for me too to maintain the security logic and credentials for all of these applications. Why not we implement it the same way as the "SkyDiving Center" is verifying the age limit of the customers. They trust a government authority which issues them Id. They trust the Id as long as they have no doubts that this is actually issued by the authority. It is totally up to the State Agency how they want to verify the age. They might change it any time they want but as long as they would issue these Ids, as a business owner I don't have to change my process. As an application architect, why do I have to write security logic every time a new application is introduced. We must be creating the similar software based authorities in our environment providing security and our applications should trust these authorities for their security requirements. This is federated security. Windows Identify Foundation is to support the same.

Although we have discussed it specially in the context of government issued Id, the same scenario is true for other Ids too, including our financial Ids including credit and debit cards. Although there is a series of transactions between merchant, acquirer (merchant's bank) and issuer (customer's card issuer) for authorization, batching, clearing and funding, but there is a trust relationship between acquirer and issuer which makes financial transactions easier for us as a customer. [How credit card transactions work]

So federated security is good for the applications as there is no management of user accounts required in the applications. It is easier for enterprise security as we have a central security and authentication mechanism which can be managed more easily. This is more open to security policy changes. As a user too, this is beneficial. I am not comfortable creating user accounts in all the applications I access. This might be because I don't want to give a lot of my personal information which might be required at the user creation. Plus, I have to remember so many user names and passwords. With federated security, I don't have to do it anymore.

Let's consider the example of online shopping is Paypal. For most online shoppers, paypal offers the most secure payment experience. As a customer, we are concerned about our credit card security and don't want to share with every online merchant. So for customers, paypal offers security that we don't have to share our credit card information with the merchants. We expect Paypal to only share some useful information with merchant including name and shipping address. We can use our credit cards / bank deposit to pay PayPal but this is none of the concern of the merchant. The merchant just redirects us for payment to Paypal. We authenticate with Paypal and make payments. As soon as we make these payments we are redirected to merchant's website with the useful information for the merchant which would be used for shipping the package. As a merchant, I don't have to do any payment processing except the fact that the funds would be automatically transferred to my account balance. This is simpler than credit card processing but this model is closer to what WIF offers. When we reach a relying party, it redirects us to STS which authenticates us and provide useful tokens and we are redirected with these tokens to relying party applications. This is for Passive clients using WS-Federation Passive profiles used by browser based applications. For WS-Trust / WS-Federation Active profile based applications including smart client with web services, the model is a little bit different but the overall experience is same. This doesn't include redirection but, at design time, the client knows which STS it should use for authentication and then it just gets the issued tokens to the relying party web service application. This is certainly not the same model provided by WIF but it might make it easier to understand why tokens make sense.

What is Claim?
The whole WIF stack is based on claims. MSDN defined Claim as follows: "A Claim is a statement made by a subject about itself or another subject." Here a subject can easily be a person or an application. Since any subject can make any claim, the claims must be stamped and provided by a trusted issuer, which is called Token Issuer [Token is just a package of claims].

Going through the documentation becomes easier if we first understand the terminologies. A list of terms and their definition can be found here [http://msdn.microsoft.com/en-us/library/ee534975.aspx]. It was provided for sharepoint applications but it seems applicable for other scenarios as well.



The applications supporting claims for security, have trusted issuers which are verified. They issue tokens which can be used by the applications. These applications are called Relying Party.



So for WIF based applications, single sign on is just a matter of more than one applications supporting the same tokens provided by some issuer.



As a relying party, we trust the tokens provided by the subject as long as we could verify that they are issued by a our trust worthy Token Issuer. When the subject requests token from the Token Issuer it has to specify what relying party is it interested in. It is possible that the Token Issuer generates relying party specific tokens as the claim requirements for one application might be different than any other application.



Before subject start using the relying party features, it is asked about getting the claims from the token issuer. The mechanism for this would depend on the type of the subject. Browser based applications accesses the application and they are redirected to the token issuer. Browser based subjects are called passive. Here WS-Federation Passive profile is used where, first, user reaches to the relying party where it is redirected to token issuer. The token issuer adds the token and based on the returned response, the user is redirected to the relying party application. The relying party looks at the token and extract useful information. It might discard the message when it is found that the issuing authority is not trust worth or some required tokens are missing. Non-browser based applications including Smart client applications can have information about the token issuer at design time. This is possible because, unlike internet browsers, these are custom built client applications. So for smart client applications, even before hitting the application, the subject gets token from the token issuer and pass them to the relying parties. These clients use WS-Federation Active Profile or WS - Trust.

By using token mechanism, we have extracted the authentication and authorization logic completely outside the application. Now each application would just need the necessary tokens from the subjects which it supposed to get from token issuer. Now why and how the issuer provide the tokens to the subject? It must have to authenticate itself to the issuer. Now issuer's authentication might be based on username / password, digital certificates or any other form of authentication. This mechanism can also be changed anytime. We just need to change it at a single place i.e. the issuer side and the rest of enterprise software stack would remain unchanged. It might even use Activity Directory based domain accounts for authentication. Now active directory has no idea what claims are and how to receive user request and bless them with tokens. So Microsoft has provided another tool, called AD FS [Active Directory Federation Services 2.0]. This tool can use the authentication from Active Directory and pass tokens based on user requests. So Token issuer assigns token based on the subject's details as provided by an Identity Provider.



So the token issuer wouldn't be just providing you any tokens. First, it must have to authenticate the subject. For a simple scenario we can use ADFS 2.0 as the available Security Token Service. This can use Active Directory based accounts for authentication. It is also possible that the identified STS redirects the subject to some other STS where it can be authenticated based on other STS's identity providers. We should be able to configure this on STS level withouth making any changes to the relying party applications. This is specially useful under two scenarios:

1. Providing federated security for online applications using global identity providers. This might include public ones including Google and Microsoft Live.


2. Company mergers and acquisitions where applications would get authenticated from their enterprise STS. If Company A and Company B merges, then for company A's users to access the applications originally provided for company B's users is just a matter of configuring their STS's to trust each others. Now when company B's user accesses the application to company A's applications, it would be redirected to company A's STS first. Company A's STS would look at the user and figure out this is company B's subject so it must be redirected to company B's STS where it can be authenticated using the authentication mechanism of company B's STS.


3. Providing subjects access to the relying party applications from outside the organization's boundaries. Since Active directory is behind the firewall, the subjects cannot be authenticate using the domain accounts directly. Here Microsoft Azure Access Control Service [ACS] can be used. Now user gets the claims package by redirecting between ACS in the cloud and company's STS authenticating using the domain's account.

Active & Passive Security Token Services
WIF also support building custom STS supporting WS-Trust scenario. These are called Active STS. The STS supporting WS-Federation are called Passive STS. They are used for web-browser based clients.

Required Tools for Developing WIF based Applications
For development in Visual Studio 2010 and .net framework 4.0, we need to use Windows Identity Foundation SDK. This provides the necessary API to develop Identity aware applications and services. It also adds the required features in Visual Studio 2010 for ease of development. [Download Windows Identity Foundation SDK]



Since .net framework 4.5 has in-built support for Identity. The API support is already available. We still need to add "Identity & Access Tool" extension in Visual Studio 2012. This can be downloaded from Visual Studio Gallery.



As we know we can add extension directly from Visual Studio. Just search for "Identity and Access Tool" in Extensions and Updates window available as Tools -> Extensions and Updates.



The package has known conflict with other extensions but it seems that people has complained about different extensions. I noticed the following failure when I restarted Visual Studio after installation of the extension.



The Activity Log has the following error.

If you notice this then just uninstall the extension and disable all other extensions. Now you can install the Identity and Access Tool Extension and restart your Visual Studio. Once started you can enable all other extension. I haven't noticed the same failure when I restarted my Visual Studio again.

Microsoft Federation Identity Model
There are three components to Microsoft's federation Identity Model:

1. Active Directory Federation Services (ADFS) 2.0
2. Windows Azure Access Control Services (ACS)
3. Windows Identity Foundation

WIF 3.5 and WIF 4.5
The version number corresponds to the .net frameowork version WIF was released for. The first version was released as a separate download for .net framework 3.5 sp1. With .net framework 4.5, it is called WIF 4.5. Now this is integrated within .net framework 4.5. Applications written with WIF 3.5 need to be migrated to WIF 4.5.

WIF API
WIF types are spanned across the following assemblies:

1. mscorlib
2. System.IdentityModel
3. System.IdentityModel.Services
4. System.ServiceModel

The types are spanned across the following namespaces:

1. System.Security.Claims
2. several System.IdentityModel namespaces
3. System.ServiceModel.Security

Before .net framework 4.5, RolePrinciple, WindowsPrincipal and GenericPrincipal were all inheriting from System.Object.



Similarly the hierarchy of Identity(s) has been updated as follows:


Here FormsIdentity is from System.Web assembly. Further details about the API can be found here [ http://msdn.microsoft.com/en-us/library/jj729788.aspx]

Adopting WIF
As a business enterprise, we should never be in a business of writing STS. We can directly use ADFS 2.0 if we our applications are only available for intranet access. In case, we need to provide access from outside the application boundaries, we can start using Azure ACS. We still need to write applications which are claims aware (relying parties). We can configure the STS to provide the required tokens by relying parties which can also be based on the individual applications. For authentication, we can use Active Directory based domain authentication. I would recommend picking up an application where you provide the security authorization based on Domain Groups. From the code, get the list of authorizations performed based on the windows accounts. Now agree on converting them to be based on some claims instead. Now introduce STS and create the same tokens based on the same windows domain groups based on user login information. Configure the application and STS to trust each other. Now the application is cleaner as it has no hard-coded logic based on user's domain groups. Move applications one-by-one to use claims. Try to use the same claims as much as possible with the idea of introducing intra-organization universal claims.

Identity Developer Training Kit
In order to make learning easier for developers, Microsoft has provided a developers training kit. This can be obtained from Microsoft's download page [Download Training Kit]. The kit is available for both Visual Studio 2010 and Visual Studio 2012.



Identity Training Course
Microsoft has other offline training courses for the identity development for different scenarios. All of these trainings are free. The trainings can be accessed from here [ http://msdn.microsoft.com/en-us/evalcenter/gg557929]. The trainings are available to for websites, web services, Windows Azure and Silverlight based application development. There are following units available for the course: