The ASP+ URL Authorization facility is used to control access to 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 name John and a role named Admins. All other users are denied access.
<div class="code"><xmp>
<security>
<authorization>
<allow users="jdoe@somewhere.com" />
<allow roles="Admins" />
<deny users="*" />
</authorization>
</security>
</xmp></div>
<p>
Permissible elements for authorization directives are either <b>allow</b> or <b>deny</b>. Each allow or deny element must contain a <b>users</b> or a <b>roles</b> attribute. Multiple users or roles can be specified in a single element by providing a comma separated list.
<p>
<div class="code"><xmp>
<allow users="John,Mary" />
</xmp></div>
<p>
The HTTP method can be indicated using the Verb attribute:
<p>
<div class="code"><xmp>
<allow VERB="POST" users="John,Mary" />
<deny VERB="POST" users="*" />
<allow VERB="GET" users="*" />
</xmp></div>
<p>
This example lets Mary and John POST to the protected resources, while only allowing everyone else to use GET.
<p>
There are two special usernames, <b>*</b>, which indicates all users, and <b>?</b>, which refers to anonymous (unauthenticated users). This is commonly used by applications who using forms-based authentication to deny access to unauthenticated users, e.g.
<p>
<div class="code"><xmp>
<authorization>
<deny users="?" />
</authorization>
</xmp></div>
<p>
URL authorization is computed hierarchically and the rules used to determine access are as follows:
<ul>
<li>Rules relevant to the URL are collected from across the hiearchy and a merged list of rules is constructed</li>
<li>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 machine</li>
<li>Rules are checked until a match is found. If the match is an allow, access is granted. If it's a deny, access is disallowed</li>
</ul>
What this means is that applications that aren't interested in inheriting configuration should explicitly configure all of the possiblities relevant to their applications.
<p>
The default top level config.web for a given machine allows access to all users, so unless an application is configured to the contrary (and assuming that a user is authentication and passes the file authorization ACL check), access is granted.
<p>
When roles are checked, URL authorization effectively marches down the list of configured roles and does something that looks like the following pseudocode:
<div class="code"><xmp>
if( User.IsInRole("ConfiguredRole") )
{
ApplyRule();
}
</xmp></div>
<p>
What this means for your application is that you use your own class that implements <b>System.Security.Principal.IPrincipal</b> to provides your own role-mapping semantics, as explained in
The following sample uses forms-based authentication services. It explicitly denies access to "jdoe@somewhere.com" and anonymous users. Try logging into the sample with Username="jdoe@somewhere.com" and Password="password" -- access will be denied and you'll be redirected back to the login page. Now login in as Username="mary@somewhere.com" and Password="password" -- you'll see that access is granted.
