Understanding ASP.NET authorization

Working with Roles at Run Time

At run time, when users visit your site, they establish an identity, either as a Windows account name or by logging into your application. Information about the logged-in user is available to your application from the User property. When roles are enabled, ASP.NET creates an instance of the RolePrincipal class and adds it to the current request context, it also looks up the roles for the current user and adds them to the pervious created User object so that you can check them.

<roleManager

enabled="true"

cacheRolesInCookie="true"

defaultProvider="RoleManagerAzManProvider"

cookieName=".ASPXROLES"

cookiePath="/"

cookieTimeout="30"

cookieRequireSSL="true"

cookieSlidingExpiration="true"

createPersistentCookie="false"

cookieProtection="All">

The following example shows how to determine whether the current user is in the role of member. If the user is in the role, the code displays a button for members:

if (User.IsInRole("members"))

{

   buttonMembersArea.Visible = True;

}

Caching Role Information

If a user's browser allows cookies, ASP.NET can optionally store role information in an encrypted cookie on the user's computer. On each page request, ASP.NET reads the cookie and populates the role information for that user from the cookie. This strategy minimizes the need to read role information from the database. If the user's browser does not support cookies or if cookies are disabled, role information is instead cached only for the duration of each page request.

Whenever a request enters the ASP.NET pipeline it is associated with a security context, which includes information identifying the requestor. When using forms authentication, an authentication ticket is used as an identity token. The FormsAuthenticationModule is responsible for determining the identity of the requestor, which it does during the AuthenticateRequest event.

If a valid, non-expired authentication ticket is found, the FormsAuthenticationModule decodes it to ascertain the requestor's identity. It creates a new GenericPrincipal object and assigns this to the HttpContext.User object. The purpose of a principal, like GenericPrincipal, is to identify the authenticated user's name and what roles she belong to. This purpose is evident by the fact that all principal objects have an Identity property and an IsInRole(roleName) method. The FormsAuthenticationModule, however, is not interested in recording role information and the GenericPrincipal object it creates does not specify any roles.

If the Roles framework is enabled, the RoleManagerModule HTTP Module steps in after the FormsAuthenticationModule and identifies the authenticated user's roles during the PostAuthenticateRequest event, which fires after the AuthenticateRequest event. If the request is from an authenticated user, the RoleManagerModule overwrites the GenericPrincipal object created by the FormsAuthenticationModule and replaces it with a RolePrincipal object. The RolePrincipal class uses the Roles API to determine what roles the user belongs to.

The following figure depicts the ASP.NET pipeline workflow when using forms authentication and the Roles framework. The FormsAuthenticationModule executes first, identifies the user via her authentication ticket, and creates a new GenericPrincipal object. Next, the RoleManagerModule steps in and overwrites the GenericPrincipal object with a RolePrincipal object.

If an anonymous user visits the site, neither the FormsAuthenticationModule nor the RoleManagerModule creates a principal object.

The ASP.NET Pipeline Events for an Authenticated User When Using Forms Authentication and the Roles Framework