In the previous posts I talked about claims and claim sets – but where do claim sets come from? The answer is easy – from authorization policies ;) OK – let’s have a closer look.

The “container” for claim sets is a called the authorization context (defined in System.IdentityModel.Policy).

The authorization context gets created by calling CreateDefaultAuthorizationContext on the AuthorizationContext class. The input for this method is a list of objects that implement the IAuthorizationPolicy interface. This interface defines a method called Evaluate. Inside of Evaluate you create the claim sets you need and then call the AddClaimSet method on the EvaluationContext that gets passed into Evaluate. So much for the facts. How do we bring that all together?

Typically you want to distinguish between two kinds of authorization policies (and thus claim sets) in your system – I like to call them internal and external authorization policies.

An internal authorization policy is very close to the implementation details of the authentication process. WCF e.g. creates them based on the configured client credential type. These policies in turn create claim sets based on the incoming credential (Windows, certificates, usernames, SAML tokens).

External authorization policies do the application specific transformation of claims. They should not rely on any environment specific properties like ServiceSecurityContext (WCF), Context.User (ASP.NET) or Thread.CurrentPrincipal (whatever) but instead use solely the claims created by the internal policies to figure out all necessary information about the entity. This way external authorization policies can be used environment independent and can be shared between services or applications.

Let’s do an example. Imagine a WCF service with multiple credential types. Regardless of the authentication type, you want to end up with a customer claim set that holds the necessary authorization information for your service. That could be done like this:

1. WCF creates a claim set based on the incoming credential type, e.g. a WindowsClaimSet, a X509CertificateClaimSet or a claim set that holds assertions from an incoming SAML token.
2. You create a policy that parses the WCF created claim set and transform the “technical” user identifier (e.g. Windows account name, X509 thumbprint, username) to an identifier that makes sense in your application. This identifier goes into a new claim set that gets added to the evaluation context.
3. You create another policy that parses the application identifier from the previously added claim set and retrieves all necessary authorization information. Based on that you create a customer claim set and add it to the evaluation context.
4. The business logic retrieves the information from the customer claim set and does authorization decisions.

If you follow this pattern you would only have to adjust the logic of the user id generation to your specific environment. The customer claim set creation policy is now easily re-usable.

In the next post I will show you some code ;)