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();
}
C#
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.
C# Forms-Based/Cookie Authentication with URL Authorization
|