Comment effectuer l'emprunt d'identité WIF/réclamations sans que la réclamation soit mappée à un compte AD?

Question

Je dois effectuer une emprunt d'identité de recherche dans SharePoint 2010 pour les utilisateurs de Claims. Pour replacer cela dans son contexte, je voudrais d'abord expliquer comment cela fonctionne avec les comptes Windows, puis discuter de Claims/WIF.

comptes Windows

Je peux le faire pour « classiques » les utilisateurs authentifiés Windows intégrée en utilisant:

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(); 
    } 
} 

Pour obtenir ce qui précède pour travailler le compte personnifié doit être dans le même domaine que le courant L'utilisateur et moi-même devons nous assurer que le propriétaire du pool d'applications est:

• Un compte de domaine dans un domaine qui a un «niveau fonctionnel de domaine» de Windows 2003 ou supérieur
• a « acte dans le cadre du système d'exploitation » sur la boîte locale
• a « usurper l'identité d'un client après l'authentification » privilège sur la boîte locale

(Note: si quelqu'un peut comprendre comment contourner le problème où le compte courant doit être dans le même domaine que le compte personnifié Je suis toutes les oreilles.)

Claims comptes

Je voudrais faire la même chose avec les comptes Claims/WIF. Ces comptes sont et non nécessairement associés aux comptes AD (je dois supposer qu'ils ne le sont pas).

Existe-t-il un moyen de dire au STS que je veux usurper l'identité d'un compte particulier et qu'il me donne le jeton approprié pour ce compte? Je n'aurai pas le mot de passe de l'utilisateur que j'utilise.

Citation SharePoint Brew Je dois faire face à mon code qui s'exécute sur un frontal Web SharePoint (WFE) qui appelle un processeur de requête via un appel WCF. Je veux que l'appel WCF soit dans le contexte de l'utilisateur emprunté.

Le composant WebPart Recherche (WPE1) de WFE communique avec le proxy d'application de service. Le proxy d'application de service de recherche associé appelle le STS local pour obtenir un jeton SAML pour l'utilisateur. Une fois le jeton SAML collecté, le proxy d'application du service de recherche appelle un serveur exécutant le processeur de requêtes via un appel WCF. Je vais appeler ce serveur, "Serveur 2". Le serveur 2 reçoit la demande entrante et valide le jeton SAML par rapport à son STS local. Une fois validé, le serveur 2 se connecte à divers composants pour rassembler, fusionner et sécuriser les résultats de recherche. Le serveur 2 envoie les résultats de recherche rognés au serveur 1, qui sont ensuite présentés à l'utilisateur.

Un peu plus de recherche me mène vers la recherche et à ActAsOnBehalfOf. Je crois que je voudrais utiliser OnBehalfOf, mais je ne suis pas certain que cela fonctionnerait encore. Quelques références que j'ai trouvées sont énumérées ci-dessous. Toute orientation est appréciée.

• .NET Framework Developer Center - Act As vs. On BehalfOf
• Pablo M. Cibraro (aka Cibrax) blog - ActAs and OnBehalfOf support in WIF
• Programming Windows Identity Foundation (j'ai le livre)

Answer 1

J'ai passé plusieurs mois à essayer de résoudre ce problème et après avoir passé beaucoup de temps à travailler avec Microsoft SharePoint et les ingénieurs de WIF, je suis arrivé à la conclusion que ce n'était pas possible. Il semble que la question soit essentiellement ce à quoi Kirk fait allusion. Lors de la création d'une session usurpée à l'aide de revendications (par exemple, création d'un SPClaim et conversion en SPUser), SharePoint ne crée pas réellement une session complètement empruntée. La session créée n'est réellement comprise que par le modèle objet. Cela signifie que lorsque vous sortez de la limite de l'application Web et que vous effectuez une recherche, vous effectuez un saut double car vous entrez dans un autre domaine d'application/espace de processus.

J'ai essayé de faire quelque chose de similaire à ce que suggère eppesuig et je n'ai pas réussi à le faire fonctionner. Peut-être Si vous avez écrit un nouveau STS qui pourrait générer un jeton de revendication de confiance que SharePoint accepterait, vous pourrez peut-être contourner ce problème en utilisant le jeton ActAs (SharePoint n'acceptera absolument pas le jeton OnBehalfOf). Cependant, les implications sur le plan de la sécurité sont plutôt préoccupantes. Théoriquement, cela devrait fonctionner, mais obtenir le STS et SharePoint personnalisé pour s'entremêler/confiance s'est avéré être hors de ma capacité. J'aimerais voir quelqu'un d'autre l'essayer, cependant.

Answer 2

D'après ce que je comprends, vous ne pouvez pas utiliser directement une autre identité, mais le vôtre. Si vous voulez utiliser la fonction like OnBehalfOf, vous avez besoin d'un STS capable de gérer la délégation. Le STS vérifie donc votre identité et autorise ensuite l'utilisation d'identités déléguées.