10.1 Role-Based Security Explained

Role-based security (RBS) is a common security model in contemporary computing. When users wish to access a computer system, they must first prove their identity a process known as authentication. Authentication requires the user to provide a set of credentials that uniquely identify him. These credentials are commonly a name and password but could be a physical token, such as a key card, or a biological attribute, such as a thumbprint. The computer system consults an authority to determine if the supplied credentials represent a known user and whether that user should have access to the system. During operation, the system relies on the user's authenticated identity when performing authorization the process of determining what actions and resources a user has authority to access. A person's authority is expressed in terms of roles. A role is a logical categorization that grants members of the role specific permissions.

To use an example with which you should be familiar, the Windows NT, Windows 2000, and Windows XP user account systems provide a form of RBS. Each user authenticates with Windows by providing a username and password that must match a predefined user account; to the Windows operating system, the user account represents the user's identity. The Windows groups that the user account is a member of represent the user's roles and determine the resources and operations to which the user has access.

The most common types of roles mirror the jobs and activities we perform in everyday life, such as teller, manager, or administrator, and grant their members the authority to perform the actions and access the resources that they need to carry out their daily duties. However, roles are an abstract concept that you can use to represent any kind of grouping to which you want to assign a set of permissions (for example, members of a certain project that need access to a special color printer).

10.1.1 .NET Role-Based Security Explained

.NET provides a general-purpose RBS abstraction that you can use in conjunction with a variety of authentication and authorization mechanisms. In .NET RBS, an identity represents the user on whose behalf code is running. Normally, this is the currently logged-on Windows user, but this is not always the case. If your application authenticates users against an authority other than the Windows account system, then the identity may be different to the currently logged-on Windows user.

A principal encapsulates an identity and the roles to which the identity belongs; we illustrate this relationship in Figure 10-1. If the identity represents a Windows user account, the roles will identify the Windows groups to which the user belongs. Because a principal encapsulates both the identity and roles of a user, it is the primary reference point on which the .NET runtime bases any role-based security decisions.

Figure 10-1. The relationship between principals, identities, and roles

.NET role-based security is independent of the role-based security mechanism provided by COM+. See Chapter 19 for a discussion of how to use COM+ security.

10.1.2 Comparing .NET Role-Based Security and Windows Security

.NET RBS makes it easy to integrate with the Windows user accounts system, but .NET RBS is not just an extension of Windows user security into the .NET runtime. .NET RBS and the Windows user account system are completely independent security mechanisms that operate concurrently and serve different purposes.

Windows security protects the integrity of the entire system by controlling user access to important operating system operations and resources. Every Windows process and thread has an associated access token that represents the user on whose behalf the process or thread is running. The access token is an operating system object that contains information about the permissions and privileges of the user it represents, and the groups to which the user belongs. Before Windows allows code to perform a protected operation or access a protected resource, it evaluates the thread's access token to ensure that it contains the permission necessary to perform the operation. Windows enforces security regardless of whether an action is initiated by a managed .NET application or native code.

.NET RBS operates at the application level, providing a convenient mechanism through which you can control access to functionality based on the user's identity and roles. For example, you may only allow users who are members of certain roles to call an important method or you may make different menu items visible depending on the roles of the current user. Each thread running .NET code has a principal associated with it; the principal serves a similar purpose to the Windows access token, allowing .NET to determine if the user on whose behalf a thread is running is a member of a specified role. Although it is common for both the principal and access token of a thread to represent the same user, they are independent objects and there is no fixed relationship between the two. The use of .NET RBS is entirely optional; you are responsible for deciding what is protected by .NET RBS, and you must express these requirements in your code.

A .NET application can change the Windows access token of the current operating system thread in order to impersonate another Windows user see Section 10.2.3.2 later in this chapter for details.