I wrote here about a new method to override in ServiceAuthorizationManager.

Yesterday suddenly a service began to behave very strangely after adding an authorization manager to it – and after some debugging I found out that my custom claims were missing and authorization broke all over the place.

After a little more digging it turned out that this was caused by implementing the new CheckAccess method without calling the base class implementation.

The call sequence in ServiceAuthorizationManager is a little strange (I guess that’s the result of adding the new method without introducing a breaking change):

1. WCF plumbing starts the authorization process
   (System.ServiceModel.Dispatcher.AuthorizationBehavior.Authorize (ref MessageRpc))
2. CheckAccess(OperationContext, ref Message)
3. CheckAccess(OperationContext)
4. CheckAccessCore(OperationContext)

In step #3 the external authorization policies get added to the message which in turn means that the first access of AuthorizationContext afterwards triggers their evaluation. That means if you don’t call the base class implementation, the external policies never get attached – hence my claims were missing.

This is working:

class TestAuthorizationManager : ServiceAuthorizationManager
{
    public override bool CheckAccess(OperationContext operationContext, ref Message message)
    {
        base.CheckAccess(operationContext, ref message);

        // authZ code
    }
}