Consider Using S4U Feature for Impersonation and Delegation, When You Cannot do a Windows Mapping

- J.D. Meier, Carlos Farre, Jason Taylor, Prashant Bansode, Steve Gregersen, Madhu Sundararajan, Rob Boucher

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 Service must authenticate the client by using another approach, such as username authentication, or in an extranet scenario, client certificate authentication.

In such situations where you cannot map the username or certificate authentication directly to Windows accounts, you can consider using the protocol transition (S4U) feature that permits applications to use a non-Windows authentication mechanism to authenticate users, but still use Kerberos authentication and delegation to access downstream network resources. This allows your application to access downstream servers that require Windows authentication and it allows you to use Windows auditing to track user access to backend resources.

Use the WindowsIdentity constructor to create a Windows token giving only an account's user principal name (UPN).

Important: To impersonate at impersonation level, you must grant your process account the "Act as part of the operating system" user right. To impersonate at delegation level, to access network resources, you must enable protocol transition in Active Directory.

The following code shows how to use this constructor to obtain a Windows token for a given user.
using System;
using System.Security.Principal;
public void ConstructToken(string upn, out WindowsPrincipal p)
{
  WindowsIdentity id = new WindowsIdentity(upn);
  p = new WindowsPrincipal(id);
}

Additional Resources

Last edited Jun 12, 2008 at 9:40 PM by prashantbansode, version 1

Comments

No comments yet.