Geneva ships with three HTTP modules to use with ASP.NET: ClaimsPrincipalHttpModule, SessionAuthenticationModule and WSFederationAuthenticationModule. What are they for – and when to chose which?

In this post I will focus on the simplest one of the three: ClaimsPrincipalHttpModule – in following post we will have a close look at the remaining two.

The claims principal module is your easiest entry into the claims-based world. It simply takes whatever identity is on HttpContext.User and turns that into an IClaimsPrincipal. No STS or issued tokens required. There are three main decisions made:

• If client is using Windows authentication, create a WindowsClaimsPrincipal. This principal allows downcasting to WindowsPrincipal and WindowsIdentity (to access things like impersonation and other Windows security specific features). Furthermore it contains the Windows token details as claims (primary SID, group SIDs, SAM account name…).
• If the client is a FormsAuth client, a claims principal holding the user name, authentication method and instant is created.
• If RoleManager is enabled, Roles.GetRolesForUser() is called to retrieve the user’s role. These roles are transformed into claims of the “http://schemas.microsoft.com/ws/2008/06/identity/claims/role” type. Lovely.

In all cases this means, that traditional IsInRole based security (imperative or via UrlAuthorizationModule) as well IIdentity.Name continues to work while you get the benefits of claims.

The next step would be to wire up a ClaimsAuthenticationManager to add your own custom claims to the principal. This gives you a smooth migration path and co-existence between roles and claims. Nice.

One thing that’s missing IMO is the conversion of client certificates to claims. I’ll file that as a feature request.

Sample: ClaimsHttpModule.zip (8.5 KB)

(btw – this all reminds me so much of my ClaimsManagerModule I have posted in March’08 ;))