Using Impersonation with Transport Security
This article is now a part of the Windows SDK.
Impersonation and delegation are remote security concepts that really seem to throw people for a loop. That may be because every single networking implementation seems to treat them differently. Transport security is no exception, and this article covers the unique characteristics you need to know. Configuring impersonation in the service and picking certificates is exactly the same between transport and message security so those topics aren't included here.
Using Impersonation with Transport Security
Impersonation is the ability of a server application to take on the identity of the client. It is common for services to use impersonation when validating access to resources. The server application runs using a service account, but when the server accepts a client connection, it impersonates the client so that access checks are performed using the client's credentials. Transport security is a mechanism both for passing credentials and securing communication using those credentials. This document describes using transport security in Windows Communication Foundation (WCF) with the impersonation feature.
Impersonation
There are five levels of impersonation that are used with transport security.
Impersonation Level |
Description |
None |
The server application does not attempt to impersonate the client. |
Anonymous |
The server application can perform access checks against the client's credentials, but does not receive any information about the client's identity. This impersonation level is only meaningful for on-machine communication, such as named pipes. Using Anonymous with a remote connection promotes the impersonation level to Identify. |
Identify |
The server application knows about the client's identity and can perform access validation against the client's credentials, but cannot impersonate the client. Identify is the default impersonation level used with SSPI credentials in WCF unless the token provider provides a different impersonation level. |
Impersonate |
The server application can access resources on the server machine as the client in addition to performing access checks. The server application cannot access resources on remote machines using the client's identity because the impersonated token does not have network credentials. |
Delegate |
In addition to having the power of Impersonate, the server application can access resources on remote machines using the client's identity and pass the identity to other applications. The server domain account must be marked as trusted for delegation on the domain controller to use these additional powers. This level of impersonation cannot be used with client domain accounts marked as sensitive. |
The impersonation levels most commonly used with transport security are Identify and Impersonate. The None and Anonymous impersonation levels are not recommended for typical use and many transports do not support using those levels with authentication. The Delegate impersonation level is a powerful feature that should be used with care. Only trusted server applications should be given the permission to delegate credentials.
Using impersonation at the Impersonate or Delegate levels requires the server application to have the SeImpersonatePrivilege privilege. An application has this privilege by default if it is running on an account in the Administrators group or on an account with a Service SID (Network Service, Local Service, or Local System). Impersonation does not require mutual authentication of the client and server. Some authentication schemes that support impersonation, such as NTLM, cannot be used with mutual authentication.
Transport Specific Issues with Impersonation
The choice of a transport in WCF affects the possible choices for impersonation. This document covers the standard HTTP, TCP, and named pipe transports in WCF. Custom transports have their own restrictions on support for impersonation.
The named pipe transport is only intended for use on the local machine. Named pipes in WCF explicitly disallow cross-machine connections. Named pipes cannot be used with impersonation levels Impersonate or Delegate. The named pipe cannot enforce the on-machine guarantee at these impersonation levels.
The HTTP transport supports several schemes for authentication, see the HTTP Authentication document for more details. The supported level of impersonation varies depending on the authentication scheme. The Anonymous authentication scheme ignores impersonation. The Basic authentication scheme only supports the Delegate impersonation level. All lower impersonation levels will be upgraded. The Digest authentication scheme only supports the Impersonate and Delegate impersonation levels. The Ntlm authentication scheme, either directly or through Negotiate, cannot be used with the Delegate impersonation level except on the local machine. The Negotiate authentication scheme leading to Kerberos can be used with any supported impersonation level.
Next time: Building a Custom File Transport, Part 11: Putting it Together
Comments
- Anonymous
May 05, 2006
Today is the final day of coding for the file transport. The last piece is the request context for the... - Anonymous
May 05, 2006
The following links to .NET resources have been collated over time with the assistance of colleagues. ... - Anonymous
July 24, 2006
I still get a lot of hits for the series of documentation articles I did back in April and May. All... - Anonymous
August 31, 2006
Today's post is a supplement for those people annoyed that Using Impersonation with Transport Security... - Anonymous
October 08, 2006
Today's post is a supplement for those people annoyed that Using Impersonation with Transport Security