35

クレームユーザーのSharePoint2010で検索の偽装を実行する必要があります。これをコンテキストに入れるために、最初にこれをWindowsアカウントで機能させる方法を説明し、次にクレーム/WIFについて説明します。

Windowsアカウント

これは、次を使用して「従来の」Windows統合認証ユーザーに対して実行できます。

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

上記を機能させるには、偽装されたアカウントが現在のユーザーと同じドメインにある必要があり、アプリケーションプールの所有者が次のとおりであることを確認する必要があります。

  • Windows2003以上の「ドメイン機能レベル」を持つドメインのドメインアカウント
  • ローカルボックスで「オペレーティングシステムの一部として機能する」特権を持っている
  • ローカルボックスで「認証後にクライアントになりすます」権限を持っている

（注：現在のアカウントが偽装されたアカウントと同じドメインになければならないという問題を回避する方法を誰かが理解できれば、私はすべての耳です。）

クレームアカウント

クレーム/WIFアカウントでも同じことをしたいと思います。これらのアカウントは、必ずしもADアカウントに関連付けられているとは限りません（関連付けられていないと想定する必要があります）。

特定のアカウントになりすまして、そのアカウントに適切なトークンを提供するようにSTSに通知する方法はありますか？偽装しているユーザーのパスワードはありません。

SharePointBrewの引用WCF呼び出しを介してクエリプロセッサを呼び出すSharePointWebフロントエンド（WFE）で実行されるコードと競合する必要があります。そのWCF呼び出しを、偽装されたユーザーのコンテキストで実行する必要があります。

WFE（Server1）の検索Webパーツは、サービスアプリケーションプロキシと通信します。関連する検索サービスアプリケーションプロキシは、ローカルSTSを呼び出して、ユーザーのSAMLトークンを取得します。SAMLトークンが収集されると、検索サービスアプリケーションプロキシは、WCF呼び出しを介してクエリプロセッサを実行しているサーバーを呼び出します。このサーバーを「サーバー2」と呼びます。サーバー2は着信要求を受信し、ローカルSTSに対してSAMLトークンを検証します。検証されると、サーバー2はさまざまなコンポーネントに接続して、検索結果を収集、マージ、およびセキュリティ調整します。サーバー2は、トリミングされた検索結果をサーバー1に送り返し、サーバー1はユーザーに表示されます。

もう少し調査を行うことで、ActAsとOnBehalfOfを検討するようになりました。OnBehalfOfを使いたいと思いますが、どちらもまだ機能するかどうかはわかりません。私が見つけたいくつかの参考文献を以下に示します。任意のガイダンスをいただければ幸いです。

4

2 に答える 2

9

私はこの問題の解決に数か月を費やし、Microsoft SharePointとの作業に長い時間を費やした後、WIFエンジニアはこれは不可能であるという結論に達しました。問題は基本的にカークがほのめかしていることのようです。クレームを使用して偽装されたセッションを作成する場合（SPClaimの作成やSPUserへの変換など）、SharePointは実際には完全に偽装されたセッションを作成していません。作成されるセッションは、実際にはオブジェクトモデルによってのみ理解されます。つまり、Webアプリケーションの境界の外に出て検索に入ると、別のアプリケーションドメイン/プロセススペースに足を踏み入れるため、効果的にダブルホップを実行していることになります。

eppesuigが提案するのと同じようなことをしようとしましたが、うまくいきませんでした。おそらく、SharePointが受け入れる信頼できるクレームトークンを生成できるまったく新しいSTSを作成した場合、ActAsトークンを使用してこれを回避できる可能性があります（SharePointはOnBehalfOfトークンを絶対に受け入れません）。ただし、それを行うことのセキュリティへの影響はかなり懸念されます。理論的には機能するはずですが、カスタムSTSとSharePointを混在/信頼させることは私の能力の範囲外であることがわかりました。でも、誰か他の人に試してもらいたいです。

于 2011-12-02T14:44:49.453 に答える
0

私が理解していることから、あなたはあなた以外の他のアイデンティティを直接使用することはできません。OnBehalfOfのような関数を使用する場合は、委任を処理できるSTSが必要です。そのため、STSはIDを確認してから、委任されたIDの使用を許可します。

于 2011-11-17T12:03:02.867 に答える