Consider S4U when you need a Windows token and you don’t have the original caller’s credentials
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).
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.
public void ConstructToken(string upn, out WindowsPrincipal p)
WindowsIdentity id = new WindowsIdentity(upn);
p = new WindowsPrincipal(id);