How to Configure URL Authorization
Background
URL authorization allows ASP.NET applications to manage access to resources
without having to rely on the security system of the operating system. Prior to
ASP.NET, the only easy way to manage access to resources was to rely on access
control lists (ACLs). The problem with this approach is that ACLs grant or deny
access based on the identity of the running thread. Therefore, you could not
easily protect resources from users who were not authenticated by Internet
Information Services (IIS). ASP.NET solves this problem by creating its own
security layer on top of the operating system.
How It Works
URL authorization works by way of a URL authorization module. Whenever a
request is made to an ASP.NET resource, the URL authorization module examines
the HTTP context for a principal object, one that implements IPrincipal. It
calls the IsInRole method of this object to determine whether a user is
authorized to access a resource that is granted based on role membership. It
accesses the underlying identity, an IIdentity instance, to determine whether a
user is authorized to access a resource that is granted based on the name of an
identity. It also uses this instance to determine whether an anonymous user is
allowed to access a resource.
Authorization
Authorization is performed based on the configuration of <authorization>
elements in the Web.config and machine.config files. The <authorization>
element supports <allow> and <deny> elements, which are
self-explanatory. The default setting of the machine.config file allows access
to all users. This behavior can be overridden by individual Web.config files.
To allow or deny access to a user, you add an element similar to the following:
<allow users="Singh"/>
<deny users="Sam"/>
However, URL authorization also supports the ? and *
symbols, which stand for anonymous users and all users, respectively.
Elements are processed from top to bottom. This means that if a user is already
granted or denied access by an element higher in the list, elements lower in
the list will not affect that same user. For example, consider the following
configuration:
<authorization>
<allow users="*"/>
<deny users="?"/>
</authorization>
The <allow> element appears first. It grants access to all users. The
following <deny> element denies access to anonymous users. However,
because anonymous users are a subset of all users, anonymous users would have
already been processed and granted access by the previous <allow>
element. Therefore, the <deny> element would have no effect. To deny
access to anonymous users and grant access to all other users, you would need
to a configuration similar to the following:
<authorization>
<deny users="?"/>
<allow users="*"/>
</authorization>
Anonymous users are denied access first. Therefore, when the <allow>
element is processed, only users that are not anonymous will be granted access.
Conclusion
With ASP.NET, you no longer need to use impersonation and ACLs to grant or deny
access to resources for users of a Web application. You can use URL
authorization, while continuing to allow the Web application run under a
dedicated identity. If users need to gain access to resources that are not
within the scope of the Web application or are not protected by URL
authorization, you can use a combination of declarative and imperative
role-based security checks.
Back to Tips and Tricks