It is common for applications developers to make authorization decisions based on the identity and/or role(s) associated with the execution context. One often sees this in financial or business systems as a means of policy enforcement. For example, one may impose limits on the value of a transaction depending on the role of the user making the request. Clerks may be able to process transactions up to some set value, supervisors to some higher limit, and VPs yet a higher limit. Another example is business systems requiring multiple approvals to complete an action. Consider a purchasing system in which any employee may generate a purchase request, but only a purchasing agent may process that request into a Purchase Order that can be sent to the supplier.
In the past, such requirements were often handled using proprietary mechanisms. Microsoft first introduced infrastructure to support this type of “role-based” security with MTS and recently COM+1.0 services. The NGWS runtime provides similar support but does so in a way that is well integrated into the NGWS runtime programming model and scales to the needs of distributed internet applications.
Integration with the NGWS runtime programming model means that role-based security mechanisms:
Business logic operating on a server will often perform role-based checks as described above. From a programming standpoint, the NGWS runtime mechanisms for performing role-based security checks should appear identical whether one is running in a typical client or server environment. However, the server environment, as typified by the NGWS ASP+ and NGWS runtime remoting Well Known Object functionality, does impose important requirements on the infrastructure.
First, in the server environment one is most often dealing with an incoming request from a remote system. These requests are typically processed by one or more “handlers” prior to calling the application code. These handlers may perform multiple functions such as request routing, logging, authentication, etc. It is important to note that from a role check perspective, it isn’t the OS account on whose behalf the handlers are running that’s of interest, but rather the entity on whose behalf the external request is being made. Hence, the system must provide a straightforward means of linking Authentication actions and the server execution context.
Second, it is common in the server environment to use process/thread pooling with asynchronous call handling for efficiency. The result is that multiple processes/threads may be involved in responding to a given request. Once one has determined the entity on whose behalf the request is being made, it is necessary to bind this information to the call context so that it may be passed on to the thread currently processing the request.