Really nasty bug created by different behavior of WCF Security Principal in Azure (vs Locally in IIS or Cassini)

A couple days ago, I spent most of one day 'bashing my head against a brick wall'  due to an authorization bug that only happened in Azure!

Here are the rough screenshots I took when I was debugging it (the extra logging entries where added to help me understand what was going on (in Azure and locally))

Losing the Principal Security roles:

Note how in the screenshot below the list of current roles is lost in Azure



but not in local IIS or Casini



Different Thread Principals

I finally tracked this down to the fact that In Azure, there was a different Thread.CurrentPrincipal



The problem is that, locally (on IIS and Cassini), at the point of security demand, the Thread Principal is a Generic Principal (vs a RoleProviderPrincipal in Azure)



Different Code paths

Here is the stack trace (on the point of demand) in Azure:


and locally



Some minor differences here too:

At azure



Locally