ASP.NET authorization Authorization

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