<%@ Page Language="C#" MasterPageFile="~/aspnet/section.master" %> <%@ Register TagPrefix=Acme Namespace=Acme %> <%@ Register TagPrefix="Acme" TagName="SourceRef" Src="~/util/SrcRef.ascx"%>

Authorizing Users and Roles

ASP.NET is used to control client access to URL resources. It is configurable for the HTTP method used to make the request (GET or POST) and can be configured to allow or deny access to groups of users or roles. The following example shows access being granted to a user named someone and a role named Admins. All other users are denied access.

<authorization>
    <allow users="someone@www.contoso.com" />
    <allow roles="Admins" />
    <deny users="*" />
</authorization>

Permissible elements for authorization directives are either allow or deny. Each allow or deny element must contain a users or a roles attribute. Multiple users or roles can be specified in a single element by providing a comma-separated list.

<allow users="John,Mary" />

The HTTP method can be indicated using the Verb attribute:

<allow VERB="POST" users="John,Mary" />
<deny VERB="POST" users="*" />
<allow VERB="GET" users="*" />

This example lets Mary and John POST to the protected resources, while only allowing everyone else to use GET.

There are two special usernames:

UserName	Description
*	All users
?	Anonymous (unauthenticated) users

These special usernames are commonly used by applications using forms-based authentication to deny access to unauthenticated users, as shown in the following example:

<authorization>
    <deny users="?" />
</authorization>

URL authorization is computed hierarchically and the rules used to determine access are as follows:

Rules relevant to the URL are collected from across the hierarchy and a merged list of rules is constructed.
The most recent rules are placed at the head of the list. This means that configuration in the current directory is at the head of the list, followed by configuration in the immediate parent, and so on, up to the top-level file for the computer.
Rules are checked until a match is found. If the match is allowable, access is granted. If not, access is disallowed.

What this means is that applications that are not interested in inheriting their configuration should explicitly configure all of the possibilities relevant to their applications.

The default setting in the machine-wide configuration file (machine.config) is to grant access to all users. Unless an application is configured to the contrary (and assuming that a user is authenticated and passes the file authorization ACL check), access is granted.

When roles are checked, URL authorization effectively marches down the list of configured roles and does something that looks like the following pseudocode:

if(User.IsInRole("ConfiguredRole")) { ApplyRule(); } If User.IsInRole("ConfiguredRole") Then ApplyRule() End If
What this means for your application is that you use your own class that implements System.Security.Principal.IPrincipal to provide your own role-mapping semantics, as explained in Windows-based Authentication.

The following sample uses forms-based authentication services. It explicitly denies access to someone@www.contoso.com and anonymous users. Try logging into the sample with Username="someone@www.contoso.com" and Password="password". Access will be denied and you will be redirected back to the logon page. Now log on as Username="someone.else@www.contoso.com" and Password="password". You will see that access is granted.