Programmatic Security and Personalization

The techniques described so far can be used to control access to resources based on the principle of uniquely identifying a user through authentication , and then checking that user's access permission for a resource through authorization . This is sufficient to implement the common types of access control requirement for most applications.

However, there are times when you want to be able to control access on a more granular level, or just be able to tell who the current user is within your code. These two techniques are often referred to under the generic terms programmatic security and personalization . Let's look at them to see how to get information about the currently logged-on user.

Roles and Identity Overview

Once a user has been authenticated, the system knows at least something about that user. At minimum, it knows the username (the identity ) and the type of authentication that was carried out. In the case of Windows authentication, it also knows which roles (that is, which Windows account groups) the user is a member of.

You can access this information in code, and use it to tailor the way that your applications behave. For example, you can display different pages or change the content of pages depending on the specific user, or on the groups that they are members of. This is a very useful feature, as the only alternative would be to create multiple copies of the page and set up permission to access each page for the appropriate users. And even then, the only way that the user would know which page they could access would be to try them all. Not exactly a user-friendly approach!

There is also the situation where you allow each user to personalize their pages within an application “ perhaps to show different content, or just to change the font size , background color , etc. Again, you need to know who the user is so that you can build the appropriate pages. Maybe one user wants to see the current news headlines on their home page in your application, while another just wants the daily Dilbert cartoon.

Getting the User Identity and Role

The technique you use to get the user's identity depends on the type of authentication you used originally. ASP.NET exposes the IPrincipal object as the User property of the current HttpContext object (the context within which the page is executing). Through the Identity property, the User object exposes a reference to the IIdentity object that describes the current user. This object provides properties that you can use to identify the current user, as shown in the following table:

Property	Description
Name	Returns the username or the name of the account that the user logged on with, including the domain name if it was a Windows domain account
IsAuthenticated	Returns True if the current user has been authenticated
AuthenticationType	Returns a string indicating the authentication method used “ for example, Forms , NTLM , Basic , Passport

Depending on the type of authentication used, the Identity property will actually be an instance of one of three different objects. For Windows authentication, the property returns a WindowsIdentity object, for Passport authentication it returns a PassportIdentity object, and for Forms-based authentication it returns a FormsIdentity object. The three properties listed in the preceding table are common to all these objects:

  strUserName = User.Identity.Name   blnAuthenticated = User.Identity.IsAuthenticated   strAuthType = User.Identity.AuthenticationType  

However, the different Identity objects also expose properties that are specific to the type of authentication used. For example, the WindowsIdentity object exposes properties for the Windows security token and Boolean values indicating if the account is a guest account, an anonymous account, or a system account. The FormsIdentity object exposes the current user's cookie ticket value, and the PassportIdentity object exposes a host of properties and methods that are specific to this type of authentication.

The namespace containing the class that implements the Identity object ( System.Web.Security ) is imported into ASP.NET pages by default, but to create a specific reference to a WindowsIdentity object you also need to import the System.Security.Principal namespace:

  <%@Import Namespace="System.Security.Principal" %>  

This allows you to cast the User.Identity to a WindowsIdentity object, and use the extra properties and methods it provides. A full list of all the properties and methods for each object is included in the .NET Framework SDK in the section Reference Class Library System.Security.Principal.

Checking the User's Role

If Windows authentication was used, it's possible to tell which Windows account group the current user is a member of. Or rather, to be more exact, it's possible to tell if the user is a member of a group that you specify. For security reasons, you can't enumerate the list of groups “ instead you specify the group name in a call to the IsInRole method. This is a method of the User object for the current context:

  blnResult = User.IsInRole("MyDomainName\SalesDept")  

This method is useful if you want to change the behavior of a page or application based on the Windows account group that the user is a member of. For example, you can display different menus or links pages for members of the Administrators group, or change the appearance of pages for members of a group named SalesDept compared to the appearance when a member of the AccountingDept group accesses them. To test for a local (machine-level) account group include the machine name instead of the domain name:

  blnResult = User.IsInRole("MyMachineName\SalesDept")  

Using Built-in Account Groups

Windows 2000 includes several built-in groups, and it adds users to these groups automatically. For example, all user accounts are automatically members of the built-in Users group, and the administrator account is a member of the built-in Administrators group. To specify one of these built-in groups, you must include the word BUILTIN as though it is the domain name, for example:

  blnResult = User.IsInRole("BUILTIN\Users")   blnResult = User.IsInRole("BUILTIN\Administrators")  

However, instead of using the name of the group directly, you can substitute values from the enumeration named WindowsBuiltInRole to specify the groups that are built into Windows. This is useful because it will detect the groups or individual accounts if they have been renamed , and will also work on platforms other than Windows 2000 and in other localized operating system languages.

For example, using WindowsBuiltInRole.Administrator will include the built-in Administrator account, even if you have renamed it. The full list of members of this enumeration is shown in the following code:

  WindowsBuiltInRole.AccountOperator   WindowsBuiltInRole.Administrator   WindowsBuiltInRole.BackupOperator   WindowsBuiltInRole.Guest   WindowsBuiltInRole.PowerUser   WindowsBuiltInRole.PrintOperator   WindowsBuiltInRole.Replicator   WindowsBuiltInRole.SystemOperator   WindowsBuiltInRole.User