Here I showed you how to transform authentication specific claims to general application claims. The same model can be also used outside of WCF. I will use a client application here as an example and save ASP.NET for a later post (as this requires some extra work).

Typically, in client applications you don’t need all these layers of indirection and flexibility since you will have (most likely) a single authentication type. But to prove the point that you can reuse your existing policies – here’s what you would do:

• Create a claim set for your “technical” user, e.g. from a username/password dialog, the Windows token or an inserted SmartCard
• Map the “technical” identifier to an application identifier
• Create the customer claims

It turns out that the only thing that is different to the WCF scenario is the initial “technical” claim set. The rest of the code stays the same.

You can create the authorization context by calling CreateDefaultAuthorizationContext on the AuthorizationContext class (and passing in the three policies described above). From that point on you can use the same authorization code as you would write in WCF.

The context creation code could look like this:

private static AuthorizationContext CreateContext()
{
    WindowsIdentity identity = WindowsIdentity.GetCurrent();

    AuthorizationContext context =
      AuthorizationContext.CreateDefaultAuthorizationContext(
        new List<IAuthorizationPolicy>()
        {
            // claim set based on Windows authentication
            new WindowsUserAuthorizationPolicy(identity),

            // mapping of authentication to application id
            new CustomerIdAuthorizationPolicy(),
           
            // application claim set
            new CustomerAuthorizationPolicy()
        });

    return context;
}

The only new code here is the policy for Windows authentication. This one is very simple:

class WindowsUserAuthorizationPolicy : IAuthorizationPolicy
{
    WindowsIdentity _identity;

    public WindowsUserAuthorizationPolicy(WindowsIdentity identity)
    {
        _identity = identity;
    }

    public bool Evaluate(EvaluationContext evaluationContext, ref object state)
    {
        evaluationContext.AddClaimSet(this, new WindowsClaimSet(_identity));

        return true;
    }

    public System.IdentityModel.Claims.ClaimSet Issuer
    {
        get { return ClaimSet.System; }
    }

    public string Id
    {
        get { return “WindowsUserAuthorizationPolicy”; }
    }
}

Now you have an AuthorizationContext. But there are some small things left to do. How do you make that context available to the rest of your app? How can you propagate this information across across thread switches. This brings us back to an old friend called Thead.CurrentPrincipal. Stay tuned.