Alex Rivera | Logout

How do I perform WIF/claims impersonation without the claim being mapped to an AD account?

Asked 2011-03-02T17:59:20.333
35

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 cal

sharepoint claims-based-identity windows-identity wif
Edit
Report

2 Answers

9

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.

answered 2011-12-02T14:44:49.453
0

From what I understand, you cannot use directly any other identity but yours. If you want to use function like to OnBehalfOf, you need an STS that is able to handle delegation. so the STS will check your identity and then permit to use delegated identities.

answered 2011-11-17T12:03:02.867

Your Answer