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:

WordPress.com Logo

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

Twitter picture

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

Facebook photo

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

Google+ photo

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

Connecting to %s