Windows Identity Foundation is a new framework from Microsoft that helps to solve the identity crisis so many users face with multiple accounts for on-line services, applications, etc.  WIF (dub-eye-eff, not “wiff”), supports the notion of claims-based authentication where a user will authenticate with an external provider and return to your application with a set of claims (in the form of an encrypted token such as SAML) which you then verify and accept.  Delegating authentication is meant to remove the responsibility of authenticating from your application so that it can focus on doing what the app needs to do and not become full of logic to authenticate users.

What’s in a Claim Anyway?

Claims based security isn’t something new.  The idea behind claims is simple.  Users go to a centralized provider where they authenticate and are given a token which contains information about that user; their name, roles, and any other data the authentication store provides.  The user then takes those claims and presents them to the application.  The application verifies the authenticity of the claims and allows the user to access the resources which they are authorized to use.

Real World Claims

The identity problem hasn’t been eliminated in the real-world.  Think about how many cards you carry in your wallet that identify you to some other external party.  You have a drivers license, credit cards, video club cards, etc.  These cards are generally only trusted by the person issuing them.

Since I’ve been doing a lot of flying lately, let’s consider this example.  When you go through the airport now you are required to have a “government issued ID” in addition to your boarding pass.  In the United States alone there are 50 governments responsible for issuing IDs.  You can also print your own boarding pass and each of the airlines format is slightly different.  When you hand your ID and boarding pass to the TSA agent they are not going to verify who actually printed your ID or the legitimacy of your boarding pass.  They are looking for signs of fraud and that the person in the picture resembles the person standing in front of them.

You present the TSA agent your claims (valid boarding pass and government issued ID) and they verify your claims by checking against known signs of fraudulent IDs.

WIF Terms

Claim – Comes from the attribute store for a user.  Typically a key value pair.

Identity Provider – The service responsible for provisioning users & their attributes.

Relying party – The application which will rely on an STS to provide authentication and a token containing claims.

Security Token Service (STS) – The interface of the Identity Provider which allows you to interact with the Identity Provider as a web service.

Token – The “thing” that contains claims to be used by an application. Typically it is an encrypted cookie or xml file.

Getting Started with WIF

To build your first claims aware application you’ll need to grab the SDK here.  To use WIF you need to have IIS installed.  For instructions on installing IIS on Windows 7, check this post.  Included in the samples are several ways you can use WIF.  For this post we’ll look at the PassiveRedirectBasedClaimsAwareWebApp found in {Program Files}\Windows Identity Foundation SDK\v3.5\Samples\Quick Start\Web Application.

To get started with the samples after you installed IIS, be sure to run the SamplesPreReqSetup.bat in {Program Files}\Windows Identity Foundation SDK\v3.5\Samples\Utilities (You must run this “as administrator”)
 

After running the pre-requisite setup, you need to run the Setup.bat in {Program Files}\Windows Identity Foundation SDK\v3.5\Samples\Quick Start\Web Application and once again be sure to run as administrator.

To test your app just point your browser to https://localhost/WebControlBasedClaimsAwareWebApp/default.aspx.  Log in with your windows account and you should see a page listing the claims in the token.  Note the https; during the pre-requisite setup the scripts will create an SSL cert and enable SSL on your machine. 

Let’s Add a Claim

The STS is located in the PassiveSTS project.  Open App_Code and then the MySecurityTokenService.cs file.  This is the STS implementation.  You can look through the code to get a feel for how the STS works.  To add claims, jump down to the GetOutputClaimsIdentityMethod.  To add a claim use the following snippet:

outputIdentity.Claims.Add(new Claim("http://christopherDeweese.com/Claims/Twitter", "@cdeweese"));

We’ll also need to alter the web applications to support the claim.  The code in the apps will ignore claims it is not expecting.  Open the default.aspx.cs in WebControlBasedClaimsAwareWebApp.  Add the following code near the top where the ExpectedClaims field is defined:

 string[] ExpectedClaims = new string[]  {   Microsoft.IdentityModel.Claims.ClaimTypes.Name,
"http://WindowsIdentityFoundationSamples/myID",
"http://WindowsIdentityFoundationSamples/2008/05/AgeClaim",
"http://christopherDeweese.com/Claims/Twitter"
                                            };

When you browse to the page your output should look something like:

What Just Happened?

Nothing like learning about it by diving in head-first.  When we made our first request to the web app it could not locate our token with the claims and we were immediately redirected to the STS where we were prompted for our logon credentials.  After we were authenticated the STS built an identity which was returned in an encrypted token and we were redirected back to the web app.  This time the web app found our token and allowed us in, displaying the page we see above.

Conclusion

Windows Identity Foundation is a different way to solve your identity problems.  WIF focuses on a model that focuses on how the problem is dealt with in the “real-world”; though we haven’t solved it there yet either.  This will hopefully be part one of many posts that will cover WIF and the good, bad, and ugly of using it to tackle identity problems head-first.