How To: Use Protocol Transition for Impersonating and Delegating the Original Caller in WCF

Applies To

Microsoft® Windows Communication Foundation (WCF) 3.5

Microsoft Visual Studio® 2008

Microsoft Windows Server® 2003

Summary

This How To article walks you through the process of using protocol transition for impersonating and delegating the original caller. You will learn how to use the client certificate for authentication. You will then use the service for user (S4U) Kerberos extensions
to create a Windows identity for the authenticated user, by using the user principal name (UPN) and impersonating and delegating the original caller.

Objectives

Learn how to do protocol transition in WCF by using a client certificate.

Learn how to configure the WCF process identity for protocol transition and constrained delegation.

Overview

In many situations—for example, if your users access a WCF service over the Internet—you cannot use Kerberos authentication because firewalls prevent the client computer from directly communicating with the domain controller. Instead, your application must
authenticate the client by using another approach, such as username authentication, or client certificate authentication.

Windows Server 2003 includes a protocol transition feature that permits services to use a non-Windows authentication mechanism to authenticate users, while still using Kerberos authentication and delegation to access downstream network resources. This allows
your application to access downstream servers that require Windows authentication, and allows you to use Windows auditing to track user access to back-end resources.

Note that impersonating a Windows identity to access downstream resources brings a number of advantages, but also some disadvantages. The advantages include the ability to use Windows auditing to track user access to back-end resources, and the ability to implement
fine-grained access controls to resources (such as databases) on a per-user basis. The disadvantages include the additional administration required to administer fine-grained access controls, and reduced scalability. For many applications, the trusted subsystem
model is appropriate; for example, where the WCF service authenticates the caller, but then uses a service identity to access downstream resources on behalf of the original caller. This results in reduced administration and improved scalability.

The use of protocol transition to access downstream resources relies on two extensions to the Kerberos protocol. Both extensions are implemented in Windows Server 2003. These extensions are:

Service-for-User-to-Self (S4U2Self), which allows you to obtain a Windows token for the client by supplying a UPN without a password.

Service-for-User-to-Proxy (S4U2Proxy), which allows an administrator to control exactly which downstream services can be accessed with the S4U2Self token.

Step 3 – Create and Install a Service Certificate

In this step, you create a temporary service certificate and install it in the local store. This certificate will be used for service authentication and to encrypt the message, thereby protecting any other sensitive data.

Creating and installing the certificate is outside the scope of this How To article. For detailed steps on how to do this, see “How To - Create and Install Temporary Certificates in WCF for Message Security During Development.”

Note:

If you are running on Microsoft Windows® XP, give the certificate permissions for the ASPNET identity instead of the NT Authority\Network Service identity because the Internet Information Services (IIS) process runs under the ASPNET account in Windows
XP.

The temporary certificate should be used for development and testing purposes only. For actual production deployment, you will need to get a valid certificate from a certificate authority (CA).

Step 4 – Configure the Service Certificate for the WCF Service

In this step, you configure the WCF service to use the temporary certificate you created in the previous step.

In the Configuration Editor, expand the Advanced node, and then expand the
Service Behaviors and ServiceBehavior nodes.

Click Add.

In the Service Behavior Element Extensions dialog box, select the serviceCredentials option and then click
Add.

Expand the serviceCredentials node and then select the serviceCertificate node.

Set the FindValue attribute to the name of the service certificate that you created; for example, "CN=tempCertServer".

Leave the default settings for StoreLocation and StoreName.

In the Configuration Editor, on the File menu, click Save.

In Visual Studio, verify your configuration. The configuration should look as follows.

Step 5 – Impersonate the Original Caller in the WCF Service

Perform the following steps to retrieve the UPN from the client certificate, create the
WindowsIdentity token, and impersonate the original caller.

Add using statements to add references to the relevant namespaces as follows:

using System.IdentityModel.Policy;
using System.IdentityModel.Claims;
using System.Security.Principal;

Extract the Subject name from the certificate, as shown in the following example. Note that the Subject name for the client certificate is the user’s UPN – this is done consciously at the time of client certificate creation in order to simplify the process.
Alternatively, you could have other extended attributes with the user UPN.

Using the WindowsIdentity constructor, pass the UPN string as the parameter, get the
WindowsIdentity token, and impersonate the original caller. If your WCF process identity is configured for protocol transition and trusted for delegation, you can access the remote resources as well.

In this step, you configure Active Directory to allow your WCF service to use protocol transition and constrained delegation to access a remote database server.

If your WCF service runs using the Network Service machine account, you must enable constrained delegation for your WCF server computer. However, if your WCF Service runs under a custom domain account, you must enable constrained delegation for the custom domain
account.

Note: If you use a custom domain account for running your WCF service, create a service principal name (SPN) for your custom domain account. Kerberos requires an SPN in order to support mutual authentication.

To configure constrained delegation for the machine account

This procedure assumes that you are running your WCF service under the Network Service machine account.

In the right pane, double-click your WCF server computer to display the Properties dialog box.

On the Delegation tab of the Properties window for the WCF server computer,
Do not trust the computer for delegation is selected by default. To use constrained delegation, select
Trust this computer for delegation to specified services only. You specify precisely which service or services can be accessed in the bottom pane.

Beneath Trust this computer for delegation to specified services only, select the option
Use any authentication protocol.

Click the Add button to display the Add Services dialog box.

Click the Users or computers button.

In the Select Users or Computers dialog box, type the name of your database server computer if you are running SQL Server as System or Network Service. Alternatively, if you are running SQL Server by using a custom domain account, enter that account
name instead and then click OK.

You will see all the SPNs configured for the selected user or computer account. To restrict access to SQL Server, select the
MSSQLSvc service, and then click OK.

Note If you want to delegate to a file on a file share, you need to select the Common Internet File System (CIFS) service.

To configure constrained delegation for a custom domain account

This procedure assumes that you are running your Web application under a custom domain account.

Create an SPN for your custom domain account. Kerberos requires an SPN in order to support mutual authentication. To create an SPN for the domain account:**

Note You can only have a single SPN associated with any HTTP service (DNS) name, which means you cannot create SPNs for different service accounts mapped to the same HTTP server unless they are on different ports. The SPN can include a port number.

In the right pane, double-click the user account you are using to run the WCF service. This displays the user account properties.

On the Delegation tab of the Properties window for the WCF server computer,
Do not trust the computer for delegation is selected by default. To use constrained delegation, select
Trust this computer for delegation to specified services only. You specify precisely which service or services can be accessed in the bottom pane.

Beneath Trust this computer for delegation to specified services only, select the option
Use any authentication protocol.

Click the Add button to display the Add Services dialog box.

Click the Users or computers button.

In the Select Users or Computers dialog box, type the name of your database server computer if you are running SQL Server as System or Network Service. Alternatively, if you are running SQL Server by using a custom domain account, enter that account
name instead and then click OK.

You will see all the SPNs configured for the selected user or computer account. To restrict access to SQL Server, select the
MSSQLSvc service, and then click OK.

Step 7 – Create a Test Client

In this step, you create a Windows Forms application to test the WCF service.

Right-click your solution, click Add, and then click New Project.

In the Add New Project dialog box, in the Templates section, select
Windows Forms Application.

In the Name field, type Test Client and then click OK.

Step 8 – Add a WCF Service Reference to the Client

In this step, you add a reference to your WCF service.

Right-click your client project and then click Add Service Reference.

In the Add Service Reference dialog box, set the URL to your WCF Service (e.g., http://localhost/WCFTestService/Service.svc) and then click
Go.

In the Web reference name field, change ServiceReference1 to WCFTestService.

Click Add Reference.

A reference to WCFTestService should appear beneath Web References in your client project.

Step 9 – Create and Install the Client Certificate for Authentication

In this step, you create a temporary client certificate by using the Root CA created as part of the Step 3, and install it in the local store. This certificate will be used for client authentication and to encrypt the message, thereby protecting any other sensitive
data.

Copy the root CA certificate (RootCATest.cer) and privatekeyfile (RootCATest.pvk), created as part of Step 3, to the client machine.

Open a Visual Studio command prompt and browse to the location where you copied the root CA certificate and privatekeyfile.

Run following command for creating a certificate signed by the root CA certificate: