Claims Based Authentication using Windows Identity Foundation

This is a rather large topic. Rather than butcher it, I will point you to the MSDN site for information about Federated Identity and WIF. In a nutshell, by using WIF’s Claims Based Authentication and Federated Identity, we extract the authentication process out of the application itself and place the burden elsewhere. Amongst other things, this allows us to use other Identity Providers such as Windows Live, Google, Facebook, etc.

Conceptually, from an end-user’s perspective, this “single sign on” model would virtually eliminate the need for the user to have to register with and remember a different username and password for every site. They register once with a given identity provider, for example Google, then they could log into your application by signing into their Google account and granting your application permission to their Identity Information. So if you needed their address or phone number, you could simply pull it from their token.

The steps involved are as follows:

  1. Browser makes request to your application
  2. Your application provides the address to your STS provider (This example will use Azure ACS)
  3. Browser goes to STS address and authenticates using the Identity Provider (Google)
  4. STS provides browser with a token
  5. Browser goes back to your application and provides said token.

My goal with this article is to provide DiscountASP.NET customers with a simple example of setting up an application that uses Claims Based Authentication on our servers that will utilize the Azure ACS as an STS. If you are new to WIF, you will want to visit their site for a proper introduction and to get the bits.

The primary issue when deploying a claims based application to our servers or a web farm is that behind the scenes, Windows Identity Foundation uses the DPAPI to encrypt and decrypt cookies. In this example we are going take the DPAPI out of the equation and use either our SSL certificate, or a custom certificate to perform this process. So the first thing you will need to do is create a ticket via your control panel for our support department, and ask that your ASPNet user be granted access to either a custom certificate that you provide or your SSL certificate if you already have one setup.

Next, create a new Web Forms Project in Visual Studio. Add references to Microsoft.IdentityModel and Microsoft.IdentityModel.Windows.TokenService. Make sure in the properties of these libraries, you set Copy Local to true as they are not installed in the GAC.

Next, configure your Azure ACS.

Now configure a trust between your project and the ACS by right clicking on your project node in solution explorer and selecting Add STS reference. Go through the wizard.

Now let’s wire things up to perform the security operations on the cookies that we went over earlier. In your global.asax, we will add the following namespaces:

using Microsoft.IdentityModel.Tokens;

using Microsoft.IdentityModel.Web;

using Microsoft.IdentityModel.Web.Configuration;

using System.Text;

We will now add the following methods:

void WSFederationAuthenticationModule_RedirectingToIdentityProvider(object sender, RedirectingToIdentityProviderEventArgs e)
{

HttpRequest request = HttpContext.Current.Request;

Uri requestUrl = request.Url;
StringBuilder wreply = new StringBuilder();

wreply.Append(requestUrl.Scheme); // e.g. "http" or "https"
wreply.Append("://");
wreply.Append(request.Headers["Host"]
?? requestUrl.Authority);
wreply.Append(request.ApplicationPath);

if (!request.ApplicationPath.EndsWith("/"))
wreply.Append("/");
e.SignInRequestMessage.Reply = wreply.ToString();

}

void OnServiceConfigurationCreated(object sender, ServiceConfigurationCreatedEventArgs e)
{

//
// Use the <serviceCertificate> to protect the cookies that are sent to the client.
//
List<CookieTransform> sessionTransforms = new List<CookieTransform>(new CookieTransform[] { new DeflateCookieTransform(), new RsaEncryptionCookieTransform(e.ServiceConfiguration.ServiceCertificate)
});
SessionSecurityTokenHandler sessionHandler = new SessionSecurityTokenHandler(sessionTransforms.AsReadOnly());

e.ServiceConfiguration.SecurityTokenHandlers.AddOrReplace(sessionHandler);
}

Finally, In our Application_Start method, we will add the following to wire up the event handler:

FederatedAuthentication.ServiceConfigurationCreated += OnServiceConfigurationCreated;

The final step is our web.config. We need to add two things. The first is to our system.web entry:

<system.web>
... OTHER STUFF
<trust level="Full" />
<httpRuntime requestValidationMode="2.0"/>
</system.web>

The next, is in Microsoft.identityModel. You need to point to your certificates thumbprint. Im just using my SSL certificate, so I got the thumbprint from my browser by viewing the certificate details. Put your thumbprint in the certificateReference entry.

<microsoft.identityModel>
...OTHER STUFF
<service>
...OTHER STUFF

<serviceCertificate>

<certificateReference x509FindType="FindByThumbprint" findValue="YOUR THUMBPRINT HERE"/>

</serviceCertificate>

</service>

</microsoft.identityModel>

Suggested Reading:

http://acs.codeplex.com/
http://msdn.microsoft.com/en-us/wazplatformtrainingcourse_introtowindowsazurelabvs2010_topic1.aspx#_Toc268095450

– Michael Ossou

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.