ASP.NET 2.0 Security Guidelines - Authorization

From Guidance Share

Revision as of 04:49, 6 March 2007; Admin (Talk | contribs)
(diff) ←Older revision | Current revision | Newer revision→ (diff)
Jump to: navigation, search

- J.D. Meier, Alex Mackman, Blaine Wastell, Prashant Bansode, Andy Wigley, Kishore Gopalan


Use URL Authorization for Page and Directory Access Control

Use URL authorization to control which users and groups of users have access to the application or to parts of the application. In ASP.NET version 1.1, URL authorization only applies to file types that are mapped by IIS to the ASP.NET ISAPI extension (Aspnet_isapi.dll). In ASP.NET version 2.0 on Windows Server 2003, URL authorization protects all files in a directory, even files that are not mapped to ASP.NET, such as .html, .gif, and .jpg files.

When your application uses Windows authentication, you can authorize access to Windows user and/or Windows group accounts. To do so, you should configure your application to use ASP.NET Role Manager. For more information, see the "Use ASP.NET Role Manager for Roles Authorization" section in this topic.

You can use the <location> tag to apply authorization settings to an individual file or directory. The following example shows how you can apply authorization to a specific file (page.aspx).

<location path="page.aspx" />
  <allow users="DomainName\Bob, DomainName\Mary" />
  <deny users="*" />

Configure ACLs on Your Web Site Files

You need to configure the right access control lists (ACLs) for the right identities on your Web site files so that IIS and also ASP.NET file authorization control access to these files appropriately. You need to grant access to the following identities:

  • Your Web application identity. If you are using a custom service account to run your ASP.NET application, you can grant the appropriate permissions to the IIS metabase and to the file system by running Aspnet_regiis.exe with the–ga switch.
  • Your application's users. ASP.NET file authorization performs access checks for file types mapped by IIS to the ASP.NET ISAPI extension (Aspnet_isapi.dll). If you are using Windows authentication, the authenticated user's Windows access token (which may be IUSR_MACHINE for anonymous users) is checked against the ACL attached to the requested ASP.NET file. If you are using forms authentication, access is checked against IUSR_MACHINE.

File authorization works automatically when using Windows authentication, and there is no need to impersonate the original user. The FileAuthorizationModule only performs access checks against the requested file. For example, if you request Default.aspx and it contains an embedded user control (Usercontrol.ascx), which in turn includes an image tag (pointing to Image.gif), the FileAuthorizationModule performs an access check for Default.aspx and Usercontrol.ascx, because these file types are mapped by IIS to the ASP.NET ISAPI extension. The FileAuthorizationModule does not perform a check for Image.gif, because this is a static file handled internally by IIS. However, because access checks for static files are performed by IIS, the authenticated user must still be granted read permission to the file with an appropriately configured ACL.

Use ASP.NET Role Manager for Roles Authorization

In ASP.NET version 1.1, you had to create, manage, and look up roles for the authenticated user by writing your own code. ASP.NET version 2.0 provides a new role manager feature that automatically performs this work. Roles are accessed from the configured role store by the RoleManager HTTP module by using the configured role provider. This occurs after the user is authenticated but before URL authorization and file authorization access checks occur and before programmatic role checks can occur.

If your application needs role-based authorization, use the following guidelines:

  • Use role providers to perform role authorization. Role providers allow you to load the roles for users without writing and maintaining code. Additionally, the role providers offer a consistent way for you to check the role membership of your users, regardless of the underlying data store. Where possible, use one of the supplied roles providers; these include SqlRoleProvider, WindowsTokenRoleProvider, and AuthorizationStoreRoleProvider. If you already have a custom role store in a non-SQL Server database or in a non-Active Directory LDAP store, consider implementing your own custom role provider.

The following code shows how to use the role manager API and specifically Roles.IsUserInRole.

// Tests whether the currently authenticated user is a member 
// of a particular role.
  // Perform restricted operation
  // Return unauthorized access error.
// Tests whether any given user is a member of a role:
  // Perform restricted operation
  // Return unauthorized access error.
  • Use the SqlRoleProvider when your roles are in SQL Server. If you store role information in SQL Server, configure your application to use the SqlRoleProvider. You can also configure forms authentication with the SqlMembershipProvider to use the same database for authentication and authorization, although this is not required.
  • Use the WindowsTokenRoleProvider when you use Windows groups as roles. If your application uses Windows authentication and you use Windows groups as roles, configure your application to use the WindowsTokenRoleProvider.
  • Use the AuthorizationStoreRoleProvider when your application roles are in ADAM. If your application uses Windows authentication against Active Directory, and you need application specific roles instead of using your domain Windows group membership, you can store role information in SQL Server or in an Authorization Manager (AzMan) policy store in ADAM.

Authorization Manager provides a Microsoft Management Console (MMC) snap-in, to create and manage roles, and to manage role membership for users.

If your user accounts are in Active Directory, but you cannot use Windows authentication and must use forms authentication, a good solution for roles management is to use the AuthorizationStoreRoleProvider with an AzMan policy store in ADAM.

Note The AuthorizationStoreRoleProvider does not directly support Authorization Manager business logic such as operations and tasks. To do this, you must use P/Invoke and call the Authorization Manager API directly. For more information, see How To: Use Role Manager in ASP.NET 2.0.

If Your Role Lookup Is Expensive, Consider Role Caching

If the performance overhead of role lookup is too great, perhaps because of slow data access or a large number of roles, consider caching roles in the roles cookie by setting the cacheRolesInCookie attribute to true in the Web.config file as shown here.

<roleManager enabled="true"
                ... >

When role checks are performed, the roles cookie is checked before calling the role provider to check the list of roles within the data source. This improves performance. The cookie is dynamically updated to cache the most recently validated role names. If the role information for a user is too long to store in a cookie, ASP.NET stores only the most recently used role information in the cookie and then it looks up additional role information in the data source as required. The most recently referred to roles end up being cached in the cookie.

Protect Your Authorization Cookie

You should protect roles data in the authorization cookie to stop users from modifying the list of roles to which they belong, and to stop intruders from gaining information about the roles used by your application. You protect the authorization cookie by appropriately configuring the <roleManager> element as follows:

  • Set the cookieProtection attribute to All. This ensures that the role names in the cookie are digitally signed and encrypted to prevent unauthorized viewing and modification of the role data.
* Set the cookieSlidingExpiration attribute to true and the cookieTimeout attribute to an integer number of minutes (for example, 10 to 20 or fewer). The cookie expires when the timeout expires and must be renewed. 
  • Set the cookieRequireSSL attribute to true to specify that the authorization cookie with the role information should only be returned to the server over HTTPS connections.
  • Set the createPersistentCookie attribute to false to ensure that the roles cookie is session-based and not a persistent cookie.
  • If you cannot use SSL, consider reducing the cookieTimeout to 10 minutes. If you are concerned with cookie hijacking, consider setting the cookieSlidingExpiration attribute to false. This causes the cookie to expire after the fixed timeout period and must be renewed.

The following example shows a <roleManager> element configured to protect the authorization cookie.

<roleManager enabled="true"
Personal tools