Recently I got a number of questions on what’s the best approach to implement a “custom claims principal”. What people typically mean by this is a ClaimsPrincipal derived class that provides some extra API surface like properties (think .EmailAddress). The reasons for that are mostly “type safety” and for streamlining the code.
The basic approach
The right way to associate identity data in .NET 4.5 with a security context is to use the claims collection – and nothing else. The reason I say this is, that other parts of the .NET Framework use that collection to give you additional services – like session management. So don’t even try to invent your own system unless you explicitly want something “separate”.
Given that all claims are in the collection you can write a very thin ClaimsPrincipal derived class to achieve the “strong typing”:
public class CustomClaimsPrincipal : ClaimsPrincipal
public CustomClaimsPrincipal(ClaimsPrincipal principal)
public bool IsOperator
return HasClaim(ClaimTypes.Role, “Operator”);
You would then simply wrap a standard ClaimsPrincipal (with its ClaimsIdentity and claims) with your derived class and use the standard operators (HasClaim, FindAll, FindFirst) to provide your more domain specific API.
An obvious place to set your custom claims principal in the pipeline would be e.g. a ClaimsAuthenticationManager.
Session management and type identity
Now when you use the above approach in conjunction with the session authentication module, you will notice that after the principal has once made the round-trip through session de/serialization, you will get a standard ClaimsPrincipal back in your application code.
This is because that during session token creation and re-hydration the type identity is lost. As I said, from a .NET Framework point of view, all that counts is the claims collection and not the type holding it (there is some special casing for Windows based principals, but that’s an internal implementation detail).
This means you need some extra plumbing to re-wrap that ClaimsPrincipal in your derived type for every request. Either automatically (e.g. in the PostAuthenticateRequest event in ASP.NET) – or simply while accessing it in application code, you could e.g. add a static method to your custom principal:
public static new CustomClaimsPrincipal Current
return new CustomClaimsPrincipal(ClaimsPrincipal.Current);
So your application code could look like this:
var p = CustomClaimsPrincipal.Current;
var op = p.IsOperator;
I actually prefer to stay away from derivation and rather use extension methods when I need to access certain information frequently and want to keep my code “clean”. Imagine this:
public static class ClaimsPrincipalExtensions
public static bool IsOperator(this ClaimsPrincipal principal)
return principal.HasClaim(ClaimTypes.Role, “Operator”);
Which basically gives you a programming model like this:
var op = ClaimsPrincipal.Current.IsOperator();
So in conclusion I think the only important thing to remember is, that if you want to play nice with “the system”, you should use the claims collection to associate identity information with a user. The way you access that information is totally up to. Derivation, helper methods or extension methods are just syntactic sugar.