Typically, a server responds to incoming requests from remote systems, using handlers to process requests appropriately. Before application code is actually called, a request might be processed by one or more handlers performing tasks such as routing, logging, and authentication. After authentication verifies the user's identity, the server attempts to determine whether the user making the external request is authorized to access the application. To perform authorization, the server must have access to information about the authenticated user. This information needs to be associated with the incoming request so that the information can be examined by the thread currently processing the request.
NGWS runtime role-based security provides support for authorization by making information about the principal available to the current thread. NGWS applications can make authorization decisions based on either the principal's identity or role membership or both. A role is a named set of users that have the same privileges with respect to security (such as a teller or a manager), and a principal can be a member of one or more roles. Therefore, applications can use role membership to determine whether a principal is authorized to perform a requested action.
Roles are often used in financial or business applications as a means of policy enforcement. For example, an application might impose limits on the size of the transaction being processed, depending on whether the user making the request is a member of a specified role. Clerks can process transactions that are less than a specified threshold, supervisors have a higher limit on the size of the transactions they can process, and vice-presidents have an even a higher limit (or no limit at all). Another situation where role-based security might be used is when an application requires multiple approvals to complete an action, such as might be the case in a purchasing system in which any employee can generate a purchase request, but only a purchasing agent can convert that request into a purchase order that can be sent to a supplier.
In the past, applications that used roles and principal information for authorization handled authorization using proprietary mechanisms. Microsoft introduced infrastructure to support role-based security with MTS and, more recently, provided role-based security in COM+ 1.0 services. The NGWS runtime provides role-based security support that is flexible and extensible enough to meet the needs of a wide spectrum of applications. Role-based security is particularly well-suited for use in ASP+ web applications, which are processed primarily on the server. However, NGWS runtime role-based security can be used on either the client or the server.
If you have used COM+ 1.0, you might already be familiar with the way role-based security works in that environment. However, because NGWS runtime role-based security is similar to (but more generic than) COM+ 1.0 security, it might be helpful to compare these two security models. COM+ 1.0 security relies on Windows NT accounts and tokens and requires Windows NT trust relationships. Roles are managed on a per-application basis, and the application code must be registered with the registration database. For registered applications, COM+ 1.0 tracks the security information associated with the code and maintains the mapping between user accounts and roles. With NGWS runtime role-based security, principals are not necessarily associated with Windows NT accounts and tokens –generic and custom principals are supported as well as Windows principals. There is no underlying assumption of trust relationships between computer systems, but applications can require these relationships if appropriate. Application-specific roles can be defined, and the runtime provides support for allowing administrators to map operating system accounts to roles as well as support for maintaining the mapping. There is no registration requirement for NGWS applications except in some interoperability scenarios. The NGWS runtime attaches a principal object to the call context, which is always available to the current thread. The principal object contains a reference to an identity object as well as the roles to which the identity belongs.
COM+ 1.0 does not need to be present on the computer for NGWS runtime role-based security to work. However, if COM+ 1.0 is installed, NGWS runtime interoperability features allow applications that use COM+ 1.0 security to interact with NGWS applications. For more information, see Interoperation with COM+ 1.0 Security.
To provide ease of use and consistency with code access security, NGWS runtime role-based security uses PrincipalPermission objects to enable the runtime to perform authorization in a way that is similar to code access security checks. However, you can access a principal's identity information directly and perform role and identity checks in your code when you need to.