Как я могу выполнить олицетворение WIF/претензий без требования сопоставления с учетной записью AD?

Мне нужно выполнить олицетворение поиска в SharePoint 2010 для пользователей претензий. Чтобы выразить это в контексте, я хотел бы сначала указать, как я получаю это, чтобы работать с учетными записями Windows, а затем обсуждать Claims/WIF.

Учетные записи Windows

Я могу сделать это для "классических" пользователей Windows Integrated Authenticated, используя:

WindowsImpersonationContext wic = null;
try
{  
    WindowsIdentity impersonatedUser = new WindowsIdentity("[email protected]");
    wic = impersonatedUser.Impersonate();

    // do impersonated work here...
    // in my case this is a SharePoint KeywordQuery
}
finally
{
    if (wic != null)
    {
        wic.Undo();
    }
}

Чтобы получить вышеприведенное действие, выданная учетная запись должна находиться в том же домене, что и текущий пользователь, и я должен убедиться, что владелец пула приложений:

  • Учетная запись домена в домене с "функциональным уровнем домена" Windows 2003 или выше
  • Имеет привилегию "действовать как часть операционной системы" в локальном поле
  • Имеет привилегию "выдавать себя за клиента после аутентификации" в локальном поле

(Примечание: если кто-нибудь может понять, как обойти проблему, в которой текущая учетная запись должна находиться в том же домене, что и личная учетная запись, я все уши.)

Учетные записи

Я хотел бы сделать то же самое с аккаунтами Claims/WIF. Эти учетные записи не обязательно связаны с учетными записями AD (мне нужно предположить, что они не являются).

Есть ли способ сообщить STS, что я хочу олицетворять конкретную учетную запись и чтобы она предоставила мне соответствующий токен для этой учетной записи? У меня не будет пароля пользователя, которому я выдаю себя.

Цитата SharePoint Brew Мне нужно бороться с моим кодом, который работает на веб-интерфейсе веб-сайта SharePoint (WFE), который вызывает процессор запросов через вызов WCF. Я хочу, чтобы вызов WCF выполнялся в контексте пользователя-пользователя.

Веб-часть поиска WFE (Server1) говорит о прокси-сервере службы. Связанный прокси-сервер приложения службы поиска вызывает локальную STS для получения токена SAML для пользователя. После того, как токен SAML будет собран, прокси-сервер приложения службы поиска затем вызывает сервер, на котором выполняется процессор запросов через вызов WCF. Я позвоню этому серверу "Сервер 2". Сервер 2 принимает входящий запрос и проверяет токен SAML на свой локальный STS. После проверки сервер 2 подключается к различным компонентам для сбора результатов поиска, объединения и безопасности. Сервер 2 отправляет обрезанные результаты поиска обратно на Сервер 1, которые затем предоставляются пользователю.

Немного больше исследований приводит меня к рассмотрению ActAs и OnBehalfOf. Я считаю, что хотел бы использовать OnBehalfOf, но я не уверен, что все еще будет работать. Ниже приведены некоторые ссылки, которые я нашел. Любые рекомендации приветствуются.

Ответы

Ответ 1

Я провел несколько месяцев, пытаясь решить эту проблему, и, долгое время работая с Microsoft SharePoint и инженерами WIF, пришел к выводу, что это невозможно. Похоже, проблема в том, о чем упоминает Кирк. При создании выданного сеанса с использованием претензий (например, создание SPClaim и преобразование в SPUser) SharePoint фактически не создает полностью выданный сеанс. Созданная сессия действительно понятна только объектной модели. Это означает, что при выходе за пределы веб-приложения и в поиске вы эффективно выполняете двойной прыжок, потому что вы переходите в другое пространство приложения/пространство процесса.

Я попытался сделать что-то похожее на то, что предлагает eppesuig, и не мог заставить его работать. Возможно,, если вы написали новую новую STS, которая могла бы генерировать доверенный маркер заявки, который будет принимать SharePoint, тогда вы сможете обойти это с помощью токена ActAs (SharePoint абсолютно не принимает токен OnBehalfOf). Тем не менее, последствия для безопасности, связанные с этим, скорее касаются. Теоретически это должно работать, но получение пользовательских STS и SharePoint для взаимодействия/доверия оказалось не в моих силах. Мне бы хотелось, чтобы кто-то еще попробовал это.

Ответ 2

Из того, что я понимаю, вы не можете использовать напрямую какую-либо другую личность, кроме своей. Если вы хотите использовать функцию, например OnBehalfOf, вам нужна STS, способная обрабатывать делегирование. поэтому STS проверит вашу личность и разрешит использовать делегированные идентификаторы.