How to use Authorization with ASP.NET Roles in IIS 7.x

The native URL authorization module shipping with IIS 7.x, does not understand ASP.NET-specific role information, because this information is only encapsulated into managed objects implementing managed interfaces.   On the other hand, running IIS 7.x in ASP.NET integrated mode provides a unified HTTP processing pipeline where managed and native modules are processed within the same HTTP module pipeline. For that reason, you can use any managed HTTP module written with .NET language to extend the default behavior of IIS 7.x. That means:

1. You can write your own HTTP module with .NET and integrate them into IIS 7.x processing pipeline.

2. You can integrate existing ASP.NET modules such as the FormsAuthentication or the UrlAuthorization modules directly into the processing pipeline.

That enables you to achieve the following two targets:

1. Protect non-ASP.NET resources.

2. Use ASP.NET security for any other web application, even if it’s not written with ASP.NET.

In both cases you just need to enable the managed UrlAuthorization module shipping with ASP.NET to be processed in the native pipeline together with other IIS 7.x modules (and ASP.NET modules) as well. The next picture shows how you can enable this configuration option in the IIS 7.x modules configuration feature:

 

As soon as you have enabled the managed UrlAuthorization module, any resource of the website (images, text files or any type of file such as classic ASP or PHP pages) gets protected by ASP.NET security, as well. Now you can configure authorization roles for accessing all of these resources through the <authorization> configuration section within the <system.web> section of your web.config file which is looks similar to the following one.

 

<configuration>

<!– More configuration settings here … –>

<system.web>

<authentication mode=”Forms”>

<forms cookieless=”UseUri” />

</authentication>

<authorization>

<deny users=”?” />

</authorization>

<!– More configuration settings here … –>

</system.web>

<system.webServer>

<validation validateIntegratedModeConfiguration=”false” />

<security>

<authorization>

<remove users=”*” roles=”” verbs=”” />

<add accessType=”Allow” users=”*” roles=”” />

</authorization>

</security>

<modules>

<remove name=”UrlAuthorization” />

<remove name=”FormsAuthentication” />

<add name=”FormsAuthentication”

type=”System.Web.Security.FormsAuthenticationModule”

preCondition=”” />

<add name=”UrlAuthorization”

type=”System.Web.Security.UrlAuthorizationModule”

preCondition=”” />

</modules>

<!– More configuration settings here … –>

</system.webServer>

</configuration>

 

Important notes:

1. The IIS 7.x authorization allows access to the website to any user, whereas the ASP.NET authorization clearly denies access to anonymous users. In addition, the IIS 7.x configuration includes both the ASP.NET FormsAuthenticationModule and the ASP.NET UrlAuthorizationModule in its processing pipeline, which means they will affect access to any resource—whether ASP.NET-based or not ASP.NET-based—within the web application directory. This also means that you can leverage roles managed by ASP.NET through the roles API and roles API framework for any resource hosted in an IIS 7.x web application.

2. Using the UrlAuthorization module of ASP.NET for the native processing pipeline only makes sense when not using Windows authentication. With Windows authentication you can configure any declarative authorization rules directly through the IIS 7.x management console to influence the out-of-the-box functionality provided by the native UrlAuthorizationModule shipping with IIS 7.x.