Authorization

You can use authorization to control access to directories, individual Web pages, page classes, and methods . If required, you can also include authorization logic in your method code. When you build authorization into your Web pages and controls, consider the following recommendations:

• Use URL authorization for page and directory access control .

• Use File authorization with Windows authentication .

• Use principal demands on classes and methods .

• Use explicit role checks for fine-grained authorization .

Use URL Authorization for Page and Directory Access Control

For page-level and directory-level access control, use URL authorization, which is configured by the <authorization> element. To restrict access to specific files or directories, place the <authorization> element inside a <location> element.

For more information, see "Authorization" in Chapter 19, "Securing Your ASP.NET Application and Web Services."

Use File Authorization with Windows Authentication

If ASP.NET is configured for Windows authentication, the FileAuthorizationModule checks all requests for ASP.NET file types. This includes ASP.NET page files (.aspx), user controls (.ascx), and any other file type mapped by IIS to the ASP.NET ISAPI filter.

To configure the FileAuthorizationModule , set the appropriate Windows access control lists (ACLs) on the ASP.NET files.

Use Principal Demands on Classes and Methods

Principal permission demands allow you to make authorization decisions based on the identity and role membership of the caller. The caller's identity and role membership is maintained by the principal object that is associated with the current Web request (accessed through HttpContext.User ). Use declarative security attributes to provide access controls on classes and methods, as follows :

 // Declarative syntax [PrincipalPermission(SecurityAction.Demand,            Role=@"DomainName\WindowsGroup")] public void SomeRestrictedMethod() { } 

Use Explicit Role Checks for Fine-Grained Authorization

Declarative security checks prevent a user from accessing a class or calling a specific method. If you need additional logic inside a method to make authorization decisions, either use imperative principal permission demands or explicit role checks using IPrincipal.IsInRole . These approaches allow you to use additional runtime variables to fine tune the authorization decision. The following example shows the use of an imperative principal permission demand:

 // Imperative syntax public void SomeRestrictedMethod() {   // Only callers that are members of the specified Windows group   // are allowed access   PrincipalPermission permCheck = new PrincipalPermission(                                          null, @"DomainName\WindowsGroup");   permCheck.Demand();   // Some restricted operations (omitted) } 

The following example shows the use of IPrincipal.IsInRole :

 public void TransferMoney( string fromAccount,                            string toAccount, double amount) {   // Extract the authenticated user from the current HTTP context.   // The User variable is equivalent to HttpContext.Current.User if you    // are using an .aspx page (or .asmx)   WindowsPrincipal authenticatedUser = User as WindowsPrincipal;   if (null != authenticatedUser)   {     // Note:  To retrieve the authenticated user's username, use the      // following line of code     // string username = authenticatedUser.Identity.Name;     // If the amount exceeds a threshold value, manager approval is required     if (amount > thresholdValue) {       // Perform a role check       if (authenticatedUser.IsInRole(@"DomainName\Manager") )       {         // OK to proceed with transfer       }       else       {          throw new Exception("Unauthorized funds transfer");       }     }     else     {       . . .     }   } } 

You may also have a method that allows callers from several different roles. However, you might want to subsequently call a different method, which is not possible with declarative security.