Consider S4U when you need a Windows token and you don’t have the original caller’s credentials

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

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 situation 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 obtain the impersonation type of token from the WindowsIdentity constructor, you must grant your process account the "Act as part of the operating system" user right. And for obtaining the delegation -level token, 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);
}

Last edited Apr 24, 2008 at 12:06 AM by prashantbansode, version 2

Comments

No comments yet.