• Choose a category
• All
• Classic-Fiction

Using Claims in ASP.NET Applications

To use claims-based identity in your ASP.NET application, you must pick up an STS and understand what it can do for you. Next, you disable any classic security and add code talk to the selected STS.

As mentioned, WIF is the Microsoft infrastructure for working with claims-based identity. You can download the WIF runtime from http://www.microsoft.com/downloads/en/details.aspx?FamilyID=EB9C345F-E830-40B8-A5FE-AE7A864C4D76. The WIF SDK, instead, is available here: http://www.microsoft.com/downloads/en/details.aspx?FamilyID=c148b2df-c7af-46bb-9162-2c9422208504.

Picking Up the STS

To make an ASP.NET application claims-aware, you first need to get an STS. To start, you can use SelfSTS—a utility that emulates the minimal behavior of a realistic STS. You can get the STS from http://code.msdn.microsoft.com/SelfSTS.

If you use a Microsoft-provided project template for WIF, you then can rely on some tooling made to measure to add an STS reference and generate proper changes to code and configuration. At the end of the procedure, your authentication mode in the web.config file is probably set to None and a few HTTP modules have been added to the application’s runtime environment.

Configuring the ASP.NET Application

With STS configured and WIF modules in place, the type behind the HttpContext.User property is IClaimsPrincipal:

var claimsPrincipal = HttpContext.Current.User as IClaimsPrincipal;

var claimsIdentity = (IClaimsIdentity) claimsPrincipal.Identity;

You now own all claims as issued by the sample STS. You can enumerate claims with a plain loop, as shown here:

foreach(var claim in claimsIdentity.Claims)

{

// Use claims. Properties are ClaimType and Value

}

You use claims to enable or disable the various features of the application on a per-user basis.

For a lot more information about WIF and motivation to use it, I invite you to read Vittorio Bertocci’s excellent book, “Programming Windows Identity Foundation” (Microsoft Press, 2010).

Compared to classic Forms authentication, claims-based identity has one noticeable difference for developers that can influence your decision to go with it or stick to more traditional solutions. You usually can’t have a list of all the users that could log into your application.

All that your application can do is make public the list of claims it needs. After that, the selected (and trusted) STS gains control over the implementation of user accounts, and all your application has to do is check claims presented by users and reject users who don’t match requested claims. In this way, you should never be required to modify the application to accommodate new users, even when these new users come from other sites as might be the case with federated sites.

Security-Related Controls

ASP.NET offers several server controls that make programming security-related aspects of a Web application quick and easy: Login, LoginName, LoginStatus, LoginView, PasswordRecovery, ChangePassword, and CreateUserWizard. These are composite controls, and they provide a rich, customizable user interface. They encapsulate a large part of the boilerplate code and markup you would otherwise have to write repeatedly for each Web application you developed. Figure 19-8 offers a comprehensive view of the membership platform and illustrates the role of the login controls.

Figure 19-8. The big picture of ASP.NET membership and login controls.

The Login Control

An application based on the Forms authentication model always needs a login page. Aside from the quality of the graphics, all login pages look alike. They contain a couple of text boxes (for username and password), a button to validate credentials, plus perhaps a Remember Me check box, and possibly links to click if the user has forgotten his or her password or needs to create a new account. The Login control provides all this for free, including the ability to validate the user against the default membership provider.

Setting Up the