Professional ASP.NET 1.1 [Electronic resources] نسخه متنی

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:

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