Differences Between ASP.NET URL Authorization and IIS URL Authorization

Differences Between ASP.NET URL Authorization and IIS URL Authorization

There are small but important differences between ASP.NET UrlAuthorization and IIS URL Authorization. Both modules can be installed via the IIS Setup. IIS URL Authorization installs when you install the "URL Authorization" feature in the IIS Setup User Interface:

ASP.NET Url Authorization is installed when you install ASP.NET on top of IIS. If you are an ASP.NET expert, you recall that ASP.NET UrlAuthorization is implemented in the System.Web.Security.UrlAuthorizationModule module. The corresponding configuration section is system.web/authorization. Here is the configuration entry.

XML

<add name="UrlAuthorization" type="System.Web.Security.UrlAuthorizationModule" preCondition="managedHandler" />

The IIS URL Authorization module is implemented in the global module urlauthz.dll.

XML

<add name="UrlAuthorizationModule" image="%windir%System32inetsrvurlauthz.dll" />

It is important to keep in mind that the managedHandler precondition is on the ASP.NET UrlAuthorization module. The precondition tells you that the URL authorization module is invoked only when the code that handles the request is mapped to managed code, typically an .aspx or .asmx page. IIS URL Authorization, on the other hand, applies to all content. You can remove the managedHandler precondition from the ASP.NET Url Authorization module. It is there to prevent a performance penalty you have to pay when every request (such as a request to .html or .jpg pages) would have to go through managed code.

Rules Evaluation

There are also differences in the order in which IIS and the two URL authorization modules evaluate authorization rules. ASP.NET URL Authorization is developer-focused and developers have full control over which rules they set. IIS URL Authorization keeps the Administrator in mind and tries to make sure that developers cannot override the rules an Administrator sets.

An example

Suppose the administrator wants to ensure that all users of a particular site must be authenticated. To do this is, set the following configuration on the site root:

XML

<authorization lockElements="clear"> 
    <add accessType="Deny" users="?" /> 
</authorization>

This configuration denies access to anonymous users (? = anonymous users, * = all users). With the lockElements="clear", you ensure that no one on a lower level can clear the inheritance of this setting. Your setting would be inherited to all applications and virtual directories of this site. It comes to a lock violation when you try to use the <clear/> statement at a lower level.

For more information on configuration locking, see How to: Lock ASP.NET Configuration Settings.

You can also lock the clear element in ASP.NET Url Authorization. The problem is that ASP.NET URL Authorization evaluates authorization rules from the bottom up, i.e. it first evaluates rules in the current web.config file before it evaluates parent rules. As soon as a match is found, access is granted or denied. In the above example, you can still grant access to anonymous users by specifying <add users="?"/> as an authorization rule in the secure web.config file. Because it gets evaluated first, anonymous users would be granted access.

The IIS URL Authorization module evaluates deny rules first. Because you deny access to anonymous users, you cannot simply override that rule. The other big difference is that parent rules are evaluated first. This means that if you deny access for Fred at a higher level, you can't allow access to Fred on a lower level.

Differences table

Differences table

Difference	ASP.NET URL Authorization Behavior	IIS URL Authorization Behavior
Rule evaluation	Order: a) Lower level first going up to the parent b) Order of appearance in rule collection	Order: a) Deny rules get evaluated first starting at the parent b) Allow rules starting at the parent. c) Order of appearance in rule collection
IIS User Interface	No IIS User Interface	"Authorization Rules" User Interface
Configuration section	system.web/authorization	system.webServer/security/authorization
Module	System.Web.Security.UrlAuthorization	%windir%system32inetsrvurlauthz.dll
Content	Applies only to content that is mapped to a managed handler (can be turned off via managedHandler precondition)	Applies to all content

Deny all files in a directory, via web.config setting

 

 

 

 

You may be running in to the difference between ASP.NET URL Authorization and IIS URL Authorization. A detailed summary on this is at http://www.iis.net/learn/manage/configuring-security/understanding-iis-url-authorization#Differences

Briefly, what happens with ASP.NET by default with web.config is that it only apply the allow and deny rules to files handled by the managed handler.

Files such as .txt and .html files are handled by IIS and not ASP.NET, so the authorization rules aren't applied to them.

You can test this out by adding this to your main web.config to use the IIS version.

<system.webServer>
    <modules>
        <remove name="UrlAuthorization" />
        <add name="UrlAuthorization" type="System.Web.Security.UrlAuthorizationModule"  />
    </modules>
</system.webServer>

I tested this with your same security and same directories and files, and all appears to work

A more complete version if you use other authentication methods such as forms could be this

<system.webServer>
    <modules>
        <add name="FormsAuthenticationModule" type="System.Web.Security.FormsAuthenticationModule" />
        <remove name="UrlAuthorization" />
        <add name="UrlAuthorization" type="System.Web.Security.UrlAuthorizationModule"  />
        <remove name="DefaultAuthentication" />
        <add name="DefaultAuthentication" type="System.Web.Security.DefaultAuthenticationModule" />
    </modules>
</system.webServer>