I need to perform search impersonation in SharePoint 2010 for Claims users. To put this in context, I would like to first state how I get this to work with Windows accounts and then discuss Claims / WIF.
Windows Accounts
I can do this for "classic" Windows Integrated Authenticated users using:
WindowsImpersonationContext wic = null;
try
{
WindowsIdentity impersonatedUser = new WindowsIdentity("john.doe@mydomain");
wic = impersonatedUser.Impersonate();
// do impersonated work here...
// in my case this is a SharePoint KeywordQuery
}
finally
{
if (wic != null)
{
wic.Undo();
}
}
To get the above to work the impersonated account has to be in the same domain as the current user and I have to make sure that application pool owner is:
- A domain account in a domain that has a "domain functional level" of Windows 2003 or greater
- Has "act as part of the operating system" privilege on the local box
- Has "impersonate a client after authentication" privilege on the local box
(Note: if anyone can figure out how to get around the issue where the current account must be in the same domain as the impersonated account I am all ears.)
Claims Accounts
I would like to do the same with Claims / WIF accounts. These accounts are not necessarily associated with AD accounts (I need to assume they are not).
Is there a way to tell the STS that I want to impersonate a particular account and for it to give me the appropriate token for that account? I won't have the password of the user I am impersonating.
Quoting SharePoint Brew I have to contend with my code which runs on a SharePoint web front end (WFE) that calls a Query Processor via a WCF call. I want that WCF call to be in the context of the impersonated user.
The WFE's (Server1) search web part talks to service application proxy. The associated search service application proxy calls the local STS to get a SAML token for the user. Once SAML token is collected, the search service application proxy then calls a server running the Query Processor via WCF call. I'll call this server, "Server 2". Server 2 receives the incoming request and validates the SAML token against its local STS. Once validated, Server 2 connects to various components to gather, merge, and security trims search results. Server 2 sends the trimmed search results back to Server 1 which are then presented to the user.
A little more research is leading me towards looking at ActAs and OnBehalfOf. I believe I would want to use OnBehalfOf, but I'm not certain that either would work yet. Some references I have found are listed below. Any guidance is appreciated.
I spent several months working on trying to solve this problem and after spending a long time working with Microsoft SharePoint and WIF engineers came to the conclusion that this is not possible. It appears that the issue is basically what Kirk alludes to. When creating an impersonated session using Claims (e.g. creating an SPClaim and converting into a SPUser), SharePoint is not actually creating a completely impersonated session. The session that is created is really only understood by the object model. That means that when you step outside of the boundary of the web application and into search you are effectively performing a double hop because you stepping into another application domain/process space.
I tried to do something similar to what eppesuig suggests and could not get it to work. Perhaps if you wrote a whole new STS that could generate a trusted claim token that SharePoint would accept then you might be able to work around this using the ActAs token (SharePoint absolutely will not accept the OnBehalfOf token). However, the security implications of doing that are rather concerning. Theoretically it should work but getting the custom STS and SharePoint to intermingle/trust proved to be outside of my ability. I would love to see someone else try it, though.