- Identity Flow
- Impersonation
- Trusted and Delegation Security Models
- Impersonation on ASP.NET
- Impersonation on.NET Remoting
- Impersonation On DCOM/COM+ (.NET Serviced Components)
- Conclusion
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Before delving into the different Microsoft technologies available for client server communication, it's important to analyze the typical application architectures and the options we can adopt for identity flow management.
In classic client/server applications, there is actually some degree of impersonation taking place when communicating to a remote database server using integrated security or accessing other resources (such as UNC file shares). In such situations, however, authentication works out-of-the-box in the SQL server and NetBIOS network protocols without the need for any special intervention or configuration.
Things start to get more complicated when we examine multilayered and Web applications. Let's start focusing on multilayered, non-Web applications. In such architecture, a so-called fat Windows client (Windows Forms-based) connects to an application server, specifically to .NET or COM components hosted in one or more dedicated processes. Such components typically connect to a backend database server and to other server-side resources using one of the available wire protocols (more on this later).
Security models for distributed applications may choose to adopt two different approaches: the Trusted model or the Delegate model. Both models require knowing the identity of the caller on the server side. In the Trusted model, access checks are performed "at the gate" when the remote call hit the application server.
This is typically done using COM+ or .NET role- based security, which performs access checks at the application level semantic. In the Trusted model, the "check at the gate" is considered exhaustive. After the call is allowed to get into the application layer, the work is done using the identity of the process hosting the component (this includes database access).
On the other hand, in the Delegate model "checks at the gate" (if any) are not considered exhaustive; hence, the execution of the remote call is done impersonating the caller identity, so additional access checks at the database level or by other downstream application server can be done against the original caller credentials.
The Trusted model is by far the easiest one to implement and manage, whereas the Delegate model is more difficult to implement properly and requires a much more administrative burden. In some situations, strict requirements dictate the adoption of a Delegate model. Most times, however, a Trusted model coupled with robust auditing will strike the balance between security requirements and ease of management.
Web-based distributed applications add another level of complexity to the picture. The end user identity running the browser must flow from the client workstation to the Web server, which in turn acts as the calling client from the perspective of the application server. Evidently, impersonation is out of the picture in Web applications if you adopted custom or ASP.NET form authentication options.