How do you overcome the identity double hop problem?
Windows credentials can only make one “hop” between machines on a network. The first hop is from the user’s browser to the web server; from here, to get to another machine on your network, a second hop is required.
There are two ways to work around this problem: 1) establish a delegation relationship between the web server and the other network machine, and configure the AD domain to allow Kerberos Protocol Transition, or 2) use the Win32 LogonUser API to switch to the user’s identity on the web server before making that single hop out to the other network machine.
Sharepoint Single Sign-On uses the second approach. The first approach is complex and probably akin to using a sledge hammer to crack a nut.
The great thing about the Sharepoint SSO service is that when creating Enterprise Application Definition’s, you can decide what credential fields are stored, so you can store, obviously, User names and Passwords, DB connection strings, Domain names and, well, other stuff you can put in a string.
So, as an example, a web part needs to collect information from a network machine to display in it’s UI to a user. You have two choices here, either the resource access needs to be done under the security context of the user (impersonation model), or, the resource access can be done under the security context of some ad-hoc user account (the trusted sub-system model).
In summary the webpart will retrieve security credentials from SSO, create an impersonation security context with those credentials using the LogonUser API, perform the resource access and then undo the impersonation.
We can overcome the double-hop problem using Sharepoint SSO while fulfilling both security models;
1. Trusted Sub-system Model
Create an SSO Enterprise Application Definition of type Group – all users will access network resources using the same credentials:
| MbosDoDefSSO | Display Name: | Mbos ESB Domain Access |
| Type: | Group | |
| Fields: | ||
|
Username (Unmasked) = esbprocess
Password (Masked) = ***** Domain (Unmasked) = MIT |
||
2. Impersonation Model
Create an SSO Enterprise Application Definition of type Individual – all users will access network resources using their own credentials:
| MbosLoDefSSO | Display Name: | Mbos ESB LogData Access |
| Type: | Individual | |
| Fields: | ||
|
Username (Unmasked) = hardingp
Password (Masked) = ***** Domain (Unmasked) = MIT |
||
First you’ll need to configure Sharepoint SSO, try google or this post here.
So assuming that you’ve configured SSO and set up these EAD’s, the next requirement is some code to do the impersonation which you can write, find on google or copy this one here.
Finally, you’ll want some code to get credentials from SSO, which I’ve reproduced below.
One thing to note, is that if you create an EAD of type Individual (Windows Authentication), when you call ISsoProvider.GetCredentials, a SingleSignonException exception will be generated if SSO doesn’t have credentials stored for the calling user, for the EAD.
In this case, you can make a call to ISsoProvider.GetCredentialManagementUrl to get the credential management URL to allow the user to enter their SSO credentials (for this EAD).
Putting these pieces together, accessing network resources either on behalf of the calling user, or as an ad-hoc user, can be accomplished as shown below;
// get sso creds
var ssoApp = SharepointSSO.GetEnterpriseApplication(C_SSO_EadId);
using (new Network.Impersonator(ssoApp.Fields["Username"], ssoApp.Fields["Domain"], ssoApp.Fields["Password"],
Network.LogonType.LOGON32_LOGON_NEW_CREDENTIALS,
Network.LogonProvider.LOGON32_PROVIDER_WINNT50))
{
// perform your network resource access here
}
Sharepoint Single Sign-On accessor code.
using System;
using System.Collections.Generic;
using System.Runtime.InteropServices;
using Microsoft.SharePoint.Portal.SingleSignon;
namespace Tools.Sharepoint.SSO
{
class SSOApplication
{
public IDictionary<string, string> Infomation
{ get; set; }
public IDictionary<string, string> Fields
{ get; set; }
}
class SharepointSSO
{
private static string ConvertSecureStringToString(System.Security.SecureString pValue)
{
IntPtr lValuePointer = IntPtr.Zero;
string lValueAsString;
try
{
lValuePointer = Marshal.SecureStringToBSTR(pValue);
lValueAsString = Marshal.PtrToStringBSTR(lValuePointer);
}
catch (Exception ex)
{
lValueAsString = ex.Message;
}
finally
{
if (lValuePointer != IntPtr.Zero)
Marshal.ZeroFreeBSTR(lValuePointer);
}
return lValueAsString;
}
public static SSOApplication GetEnterpriseApplication(string eadID)
{
if (string.IsNullOrEmpty(eadID)) throw new ArgumentException("an EAD ID is required", "eadID");
var ssoProvider = SsoProviderFactory.GetSsoProvider();
var ssoCreds = ssoProvider.GetCredentials(eadID);
var ssoApp = ssoProvider.GetApplicationInfo(eadID);
var ssoFields = ssoProvider.GetApplicationFields(eadID);
var creds = new SSOApplication
{
Infomation = new Dictionary<string, string>(),
Fields = new Dictionary<string, string>()
};
creds.Infomation["ID"] = ssoApp.ApplicationName;
creds.Infomation["Display Name"] = ssoApp.ApplicationFriendlyName;
creds.Infomation["Contact Name"] = ssoApp.ContactName;
creds.Infomation["Type"] = ssoApp.Type.ToString();
for (int idx = 0; idx < ssoFields.Length; idx++)
{
string ssoEvidence = ConvertSecureStringToString(ssoCreds.Evidence[idx]);
creds.Fields[ssoFields[idx].Field] = ssoEvidence;
}
return creds;
}
}
}
RSS - Posts
My 