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

Мне нужно выполнить олицетворение поиска в SharePoint 2010 для пользователей утверждений. Чтобы поместить это в контекст, я хотел бы сначала заявить, как заставить это работать с учетными записями Windows, а затем обсудить Claims / 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();
    }
}

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

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

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

Счета претензий

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

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

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

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

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

Источник

2 ответа

Решение

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

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

Источник

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

Источник
Другие вопросы по тегам