313
configuration system.web
authentication mode=Windows authorization
deny users=? authorization
system.web configuration
6.10.1.3 Understanding authentication
Choosing an authentication mechanism is something that must be done at the site level. Therefore, only the web.config file in the applications root directory should have an
authentication element.
Setting an authentication mechanism does not in itself protect resources. The authentication mechanism simply determines how a users identity will be determined if that user attempts to access
protected resources. If no resources are protected, the authentication mechanism wont be activated. Determining whether resources are protected is what authorization is all about.
6.10.2 Authorization
Authorization involves determining whether the authenticated user is authorized to view a given web page or to execute some given code. As with authentication, page-access authorization can be
handled either by ASP.NET or by the Windows operating system. Code-access authorization is handled by checks that the application developer writes into the application.
6.10.2.1 ASP.NET authorization
Access to web pages and other files is controlled by the authorization
element in the applications web.config file. The settings affect all files in the virtual directory that contains the
web.config file and all of its virtual subdirectories, unless it is overridden by a setting in a web.config file in a virtual subdirectory. Therefore, if web pages or other files are to have different accessibility
rules, they must appear in different directories and there must be different web.config files in each directory.
In this sections examples, the authentication
element isnt shown. It is assumed that the appropriate
authentication element appears in the root directorys web.config file, as
discussed in the previous section.
An example authorization
element is shown here: ?xml version=1.0 encoding=utf-8 ?
configuration system.web
authorization allow users=
authorization system.web
configuration
This authorization
element indicates that all users including anonymous users are permitted to access all resources. This setting applies to resources in the same directory in which the web.config
314
file appears, plus resources in all the subdirectories of that directory except for any subdirectory that contains its own web.config file with overriding entries.
Authorization to resources is specified with allow
and deny
elements, which appear within the authorization
element. Attributes of the elements specify who is being allowed or denied access. The value of the
users attribute is one or more usernames, separated by commas. For
example, these are all valid allow
elements: allow users=
allow users=SomeUsername, SomeOtherUsername allow users=SOME-DOMAIN\SomeUser
allow users=?
Note the following: •
signifies all users including anonymous users. If this is the only setting that appears, authentication wont occur. The system already knows that access will be granted, so it wont
take the trouble to determine who the user is. •
? specifically signifies anonymous users.
• If Windows authentication is used, the username should include the domain name, like this:
DOMAIN-NAME\username .
• If Forms authentication is used, the username should match the name that was supplied to the
first argument of the RedirectFromLoginPage method of the FormsAuthentication class defined in the System.Web.Security namespace. This method was discussed in the previous
section.
Users can be explicitly denied access if they are named in a deny
element. The usage is the same as the
allow element.
When multiple allow
and deny
elements appear in a configuration file, they are examined by ASP.NET in the order in which they appear. As soon as ASP.NET finds an element that can be
applied to the current user, the examination halts, and access is either allowed or denied, depending on the element that was found. Consider this web.config file:
?xml version=1.0 encoding=utf-8 ? configuration
system.web authorization
allow users= deny users=daveg
authorization system.web
configuration
Although the author of this configuration file probably intended that user daveg be denied access, ASP.NET doesnt see it that way. The first entry in the
authorization section grants access to
all users, including daveg, so the second entry isnt even seen. To achieve the desired effect, reverse the entries:
?xml version=1.0 encoding=utf-8 ? configuration
system.web authorization
deny users=daveg allow users=
authorization system.web
315
configuration In this case, when daveg attempts to access resources in a directory protected by this configuration
file, ASP.NET will note that the first entry can be applied to daveg and will apply it. The second entry isnt seen. When other users attempt to access the same resources, ASP.NET notes that the first
entry cant be applied to them and continues looking. The second entry then allows access to all other users.
The following authorization
section allows access to authenticated users, regardless of who they are. Anonymous users are denied access.
?xml version=1.0 encoding=utf-8 ? configuration
system.web authorization
deny users=? allow users=
authorization system.web
configuration
When nested directories each contain their own web.config files, the authorization
element in the current directorys web.config file is examined first. If no entries explicitly grant or deny access to
the current user, the web.config file in the parent directory is examined, and so on, up to the computers machine.config file. As soon as an entry is found that explicitly allows or denies access,
this examination stops. By default, the machine.config files authorization
section contains the entry:
allow users= Thus, if there is no explicit
deny entry at a lower level, all users are granted access.
In addition to specifying authorization based on username, it is also possible to specify authorization based on role membership. Thus, a business application could define certain roles, such as
Customer Service Rep, Accounting Specialist, Auditor, etc., and specify authorization for the roles rather than for individual users. Users can then be assigned to and removed from these roles as
necessary.
The way a user is made a member of a role depends on the type of authentication being used. If Windows authentication is used, role membership is determined by membership in Windows groups.
In other words, the Windows groups to which the user belongs are what ASP.NET considers as the users roles. If Forms authentication is used, the application must specify the roles to which the user
belongs. The easiest way to do this is for Microsoft to put an additional parameter in the RedirectFromLoginPage method that allows the code on the login page to specify a string array
containing role names. They dont do this, however, so we have to find another way. This requires that we understand a little more about what happens during authentication.
As you know, whenever a page that requires authorization is requested, it triggers the authentication process to determine who the user is. The first time this happens, the user is redirected to the login
page, which collects the users credentials and stores an authorization cookie on the users browser. Subsequent page requests find the cookie and use it to reauthenticate the user to the application.
Note that authentication occurs during every page access but that the Forms authentication mechanism handles subsequent authentication requests without further input from the user.
There is an event that gets triggered during each authentication request. This can be handled by placing a method called Application_AuthenticateRequest in the applications global.asax file. It is in
this event handler that roles can be specified for the authenticated user. Ex am ple 6- 15
shows the code.
316
Example 6-15. Specifying user roles using Forms authentication
Public Sub Application_AuthenticateRequest _ ByVal sender As Object, _
ByVal e As EventArgs _ Do this only after the user has authenticated.
If Not Context.User Is Nothing Then If Context.User.Identity.IsAuthenticated Then
Get the username. Dim username As String = Context.User.Identity.Name
Get the users roles. In a real application this line should be replaced with a lookup based on the username.
In addition, performance can be improved by caching the roles in session state or in a browser cookie.
Dim roles As String = {Administrator, User} Create a new principal from the username and the roles.
Dim ident As _ New System.Security.Principal.GenericIdentityusername
Dim prin As _ New System.Security.Principal.GenericPrincipalident, roles
Associate the new security principal with the request. Context.User = prin
End If End If
End Sub
Ex am ple 6- 15 examines the User property of the request context to determine whether the user has
authenticated to the system. If so, a new security principal is created based on the username and desired roles. This security principal is then attached to the request context. Having done so, the user
can be allowed or denied access to pages based on role membership.
To control access based on role membership, use the roles
attribute of the allow
and deny
elements. Usage is similar to the usage of the users
attribute, except that role names are given instead of usernames. For example, if the pages in a certain directory should be limited to members of
the Accounting Specialist role, a web.config file should be placed in that directory and should have the following entries in its
authorization section:
?xml version=1.0 encoding=utf-8 ? configuration
system.web authorization
allow roles=Accounting Specialist deny users=
authorization system.web
configuration
When specifying Windows group names as role names, include the entity that defines the group. For example, for groups defined
in a domain:
317 DOMAIN-NAME\GroupName
For groups defined on the web server machine: MACHINE\GroupName
6.10.2.2 Windows NTFS authorization