How to: Impersonate a Client on a Service
Impersonating a client on a Windows Communication Foundation (WCF) service enables the service to perform actions on behalf of the client. For actions subject to access control list (ACL) checks, such as access to directories and files on a machine or access to a SQL Server database, the ACL check is against the client user account. This topic shows the basic steps required to enable a client in a Windows domain to set a client impersonation level. For a working example of this, see Impersonating the Client. For more information about client impersonation, see Delegation and Impersonation with WCF.
When the client and service are running on the same computer and the client is running under a system account (that is, Local System or Network Service), the client cannot be impersonated when a secure session is established with stateful Security Context tokens. A WinForms or console application typically is run under the currently logged in account, so that account can be impersonated by default. However, when the client is an ASP.NET page and that page is hosted in IIS 6.0 or IIS 7.0, then the client does run under the Network Service account by default. All of the system-provided bindings that support secure sessions use a stateless Security Context token by default. However, if the client is an ASP.NET page and secure sessions with stateful Security Context tokens are used, the client cannot be impersonated. For more information about using stateful Security Context tokens in a secure session, see How to: Create a Security Context Token for a Secure Session.
To enable impersonation of a client from a cached Windows token on a service
To set the allowed impersonation level on the client
To use Delegation, negotiated Kerberos authentication (sometimes called multi-leg or multi-step Kerberos) must be used. For a description of how to implement this, see Best Practices for Security in WCF.