Be careful with ServiceAuthorizationManager.CheckAccess()

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

This entry was posted in WCF. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s