Azures inbuild Website Authorization throws permission error after returning to my site

Question

When activating "Authentication / Authorization" on my site through the Azure portal.

I'm not getting an exception "You do not have permission to view this directory or page." after I've been redirected back to my site.

Also it redirects me back to my site on this url pattern: https://{somewebsitename}.azurewebsites.net/{ActiveDirectoryApplicationGuid}/login

When I look at the detailed logged errors I can see this error:

<h3>HTTP Error 403.71 - Forbidden</h3> 
<h4>You do not have permission to view this directory or page.</h4> 
</div> 
<div class="content-container"> 
<fieldset><h4>Most likely causes:</h4> 
<ul>    <li>This is a generic 403 error and means the authenticated user is not authorized to view the page.</li> </ul> 
</fieldset> 
</div> 
<div class="content-container"> 
<fieldset><h4>Things you can try:</h4> 
<ul>    <li>Create a tracing rule to track failed requests for this HTTP status code. For more information about creating a tracing rule for failed requests, click <a href="http://go.microsoft.com/fwlink/?LinkID=66439">here</a>. </li> </ul> 
</fieldset> 
</div> 
<div class="content-container"> 
<fieldset><h4>Detailed Error Information:</h4> 
<div id="details-left"> 
<table border="0" cellpadding="0" cellspacing="0"> 
<tr class="alt"><th>Module</th><td>&nbsp;&nbsp;&nbsp;EasyAuthModule_32bit</td></tr> 
<tr><th>Notification</th><td>&nbsp;&nbsp;&nbsp;AuthenticateRequest</td></tr> 
<tr class="alt"><th>Handler</th><td>&nbsp;&nbsp;&nbsp;ExtensionlessUrlHandler-Integrated-4.0</td></tr> 
<tr><th>Error Code</th><td>&nbsp;&nbsp;&nbsp;0x80004005</td></tr> 
</table> 
</div>

This EasyAuthModule is not part of our code or any of our referenced libraries.

How can I resolve this is? This exact setup used to work just fine and has just stopped working. Which adds to the confusion.

Answer 1

This is EasyAuthModule is actually a Microsoft library. The Azure support informed me, they had just moved to a native library EasyAuthModule.

There seems to be a compatibility issue with Glimpse though.

After removing any Glimpse reference from my web.config, it's now working fine!

The Azure support told me they are working on resolving this issue on their end, so we can use Glimpse again.

Answer 2

As Sam7 mentioned. EasyAuthModule is an HTTP module which is injected into the website process as part of the Authentication / Authorization feature. A recent change was made to this module which can cause conflicts with other HTTP modules running in the same application. Glimpse is one such HTTP module which has a default configuration which is known to cause conflicts with the latest version of the EasyAuthModule.

EDIT: 9/30/2015 An update was recently made to the EasyAuthModule and Glimpse should work correctly now.

---

Warning, super-technical details below

---

The problem is that HTTP modules such as the Glimpse module may read the HTTP request entity body in the beginning of each HTTP request. Normally this is fine because ASP.NET managed modules can read the content of an ASP.NET request without causing any side effects. However, this prevents any non-ASP.NET code from reading the request body - in this case, Glimpse prevents the new version of EasyAuthModule (which was converted from an ASP.NET managed module to a native IIS module) from reading the login token that was sent from Azure AD when a user signs in. The result is a HTTP 403.71 response.

To work around the issue, you can either disable the 3rd party module (e.g. Glimpse) which is reading the HTTP request content, or configure it to stop reading the request content for login requests (I believe Glimpse, for example has a way to exclude certain URLs and/or only read request headers - I will defer to the documentation for this). This will allow the EasyAuthModule to read the Azure AD login tokens and authenticate HTTP requests successfully.

Longer term, the EasyAuthModule is going to be refactored in a way to make sure it intercepts the HTTP requests before 3rd party modules can read them to avoid this kinds of compatibility issue. Unfortunately, for now you will need to modify your config to work around this until a permanent fix is made.