I recently ran into an issue after using Windows Identity Foundation (WIF) to modify an existing ASP.NET application as a Relying Party to use a Secure Token Service (Identity Provider) rather than using traditional ASP.NET Forms Authentication. I began by applying a very aggressive ASP.NET authorization configuration to the entire site. I locked-down the site disallowing any anonymous access using the <authorization> element in the <system.web> section. Not all areas of the site required restricted access so <location> tags were used to allow anonymous access to certain folders and page resources. Everything seemed to be functioning exactly as desired. It worked; It was secure; and it restricted access to secure areas of the application to anyone who hadn’t first authenticated against the Identity Provider. All is well!

 

Then one day a defect crosses my inbox… Our QA analyst was testing the custom errors pages on the site. Without authenticating, she purposefully entered an incorrect URL expecting to see our custom error page for HTTP 404 errors. Instead, she was redirected to our Identity Provider for authentication. After authentication, she was correctly redirected back to the site and to the 404 custom error page… This wasn’t the desired behavior as she shouldn’t have had to authenticate before redirecting to the custom error page.

 

So what’s the deal? The problem was that as a default behavior, the entire site was configured to require WIF authentication. This is also the case for non-existent resources that produce HTTP 404 errors. Following is a sample of the web.config file elements that are of interest here. This is how the site was originally configured.

 

<system.web>
    <authorization>
        <deny users="?"/>
    </authorization>
</system.web>

<location path="SomeAnonymousResource.aspx">
    <system.web>
        <authorization>
            <allow users="*"/>
        </authorization>
    </system.web>
</location>

<location path="SomeAnonymousFolder">
    <system.web>
        <authorization>
            <allow users="*"/>
        </authorization>
    </system.web>
</location>

 

Here’s what the configuration elements look like now… I’ve replaced the aggressive authorization restrictions at the site root with a more targeted approach restricting access only as necessary. Instead of <location> elements to allow anonymous access for resources, there are <location> elements for restricting secure parts of the application. Problem solved – no more redirects for authentication just to end up at the 404 custom error page.

 

<system.web>
    <authorization>
        <allow users="*"/>
    </authorization>
</system.web>

<location path="SomeSecureResource.aspx">
    <system.web>
        <authorization>
            <deny users="?"/>
        </authorization>
    </system.web>
</location>

<location path="SomeSecureFolder">
    <system.web>
        <authorization>
            <deny users="?"/>
        </authorization>
    </system.web>
</location>