Authorization in ASP.NET applications

In general, two approaches to Authorization are possible for ASP.NET applications.

First is role based, users are grouped in application-defined roles. Members of a particular role share same privileges within the application. Access to operations is authorized based on the role-membership of the caller. Resources are accessed using fixed identities (such as Web application’s or Web service’s process identity).

The second approach is resource based. Individual resources are secured using Windows Access Control Lists (ACL). The ACL determines which users are allowed to access a particular resource and also the types of operations the user can perform with that resource. In this case, resources are accessed using original caller’s identity.

.NET Web applications typically use one of the following two security models for resource access.

a) Trusted subsystem model
b) Impersonation/delegation model

Under the Trusted subsystem model, the middle tier service uses a fixed identity to access downstream services and resources. The security context of the original caller does not flow through the service at the OS level, although the application may choose to flow the original caller’s identity at the application level. (Why? It may need to do so in order to support back end auditing requirements or to support per-user data access and authorization). The downstream service “trusts” the upstream service to authorize callers.

Under the Impersonation/delegation model, a service or component (usually somewhere within the logical business services layer) impersonates the client’s identity (using OS-level impersonation) before it accesses a downstream service. If the next service in line is in the same computer, impersonation is sufficient. Delegation is required if the downstream service is located on a remote computer. As a result of delegation, the security context used for the downstream resource access is that of the client.