Authorization and Roles in IIS 7.x

IIS 7.x natively supports the same URL-based authorization mechanisms as ASP.NET does. You can configure URL-based authorization in the <authorization> configuration option as a part of the <system.webServer> section of the web.config configuration file, because IIS 7.x ships with its own UrlAuthorizationModule. On the other hand you can also configure web application hosted in IIS 7.x to influence the ASP.NET-based URL authorization module directly, when running IIS in ASP.NET integrated mode. You can therefore leverage existing <authorization> configurations within the <system.web> section.

IIS 7.x permits you to manage access rules for your own, built-in authorization module for websites directly from within the management console. You can manage roles stored in your configured roles API provider’s data store from the management console, as well. The next picture shows the authorization configuration feature of the IIS 7.x management console:

 

 

The IIS 7.x URL authorization feature works completely independently of ASP.NET.  As mentioned earlier, it is configured in a separate configuration section within your web.config configuration file. Any authorization rule you configure through the IIS 7.x management console gets added to an <authorization> configuration section within the <system.webServer> section of the web.config file. A typical IIS 7.x authorization configuration in a web.config file looks similar to the following one and conceptually works the same way as ASP.NET authorization rules do.

 

<system.webServer>

<security>

<authorization>

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

<add accessType=”Deny” users=”?” />

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

</authorization>

</security>

…

<!– Other system.webServer related configuration –>

…

</system.webServer>

 

The configuration within that section adheres to the same rules that the authorization configuration of ASP.NET introduced in the article How does URL Authorization work in ASP.NET. IIS 7.x evaluates these rules from top to bottom, and as soon as it finds an applicable rule it stops searching immediately. The next picture shows that the authorization is implemented in its own native UrlAuthorizationModule.dll module, which ships with IIS 7.x:

 

Important notes:

1. You can use IIS 7.x UrlAuthorizationModule.dll independently from ASP.NET. When you install IIS 7.x on a machine without installing ASP.NET in the web server, you could use URL-based authorization through the native module.

2. The native URL authorization module shipping with IIS 7.x is able to correctly identify logged in users authenticated by all possible authentication modules, including Basic authentication, Windows authentication, and even forms authentication. This is because the module has been developed so that it understands the forms uuthentication ticket (either encoded in a cookie or the query string) correctly. But unfortunately it has not been implemented with ASP.NET roles in mind.

The reason for that is because the roles are extracted by the ASP.NET infrastructure at a certain stage within the application’s life cycle from a database configured for the roles provider. Role information is then encapsulated in managed objects implementing the IPrincipal interface, and therefore stored in pure, managed .NET objects that are not accessible to native modules of IIS 7.x. Therefore, native modules of IIS 7.x such as the UrlAuthorizationModule cannot make use of this information. As a result, you cannot configure any ASP.NET-based roles in conjunction with the native IIS 7.x URL authorization module within the <authorization> configuration of the <system.webServer> section. In reality, that means you can use only Windows Roles principal names when using the native UrlAuthorizationModule shipping with IIS 7.x.

3. In the case of user names you can fully influence the authorization management of IIS 7.x, because the native module is implemented in a way that recognizes users authenticated by native modules and users authenticated by managed modules such as the FormsAuthenticationModule. To make use of the FormsAuthentication module in conjunction with the native UrlAuthorizationModule, the FormsAuthentication module needs to be enabled for the native processing queue.

4. Role-based authorization is one of the few exceptions where you still have to keep IIS-based and ASP.NET-based configuration in mind separately.