Федеративные аутентификаций с ASP.NET MVC для SharePoint

Question

Сценария:

• Нашего текущий стеком является веб-приложению SharePoint 2013
• Пользователей войти в SP2013 с использованием ADFS претензии на основе федеративной аутентификации: Когда пользователь нажимает кнопку «Вход» на сайте SP, они перенаправляются через ADFS поставщику идентификаторов, который проверяет подлинность пользователя и использует SP, встроенные в поддержку федеративной аутентификации, мы получаем токен SAML, который хранится в службе безопасного токена SharePoints. Браузер пользователя получает cookie FedAuth, который (если я правильно понимаю) ссылаюсь на токен, хранящийся в SharePoint.
• Мы хотим постепенно перейти от SP к стеку ASP.NET MVC
• Ключевым моментом является постепенная миграция: мы хотим перенести страницы и службы REST из SP в новую систему по частям.

Например, URL /thisurl/ должны обрабатываться приложением SP унаследованной и /migratedurl/ должны быть обработаны с помощью нового приложения ASP.NET MVC.

я следующие вопросы/проблемы:

• Вопрос 1: Как мы обрабатываем проверку подлинности в новой установке? Я полагаю, что аутентификация (т. Е. Обращение пользователя, щелкнувшего ссылку «Вход», перенаправление на ADFS -> поставщик удостоверений) все равно будет обрабатываться устаревшим сайтом SP. В этом случае, как новое приложение ASP.NET MVC может получить доступ к претензиям для аутентифицированного пользователя?
• Вопрос 2: Каков наилучший способ его развертывания? Должно ли новое приложение ASP.NET MVC быть веб-приложением IIS на веб-сайте SharePoint? Или это будет новый веб-сайт IIS? Имейте в виду, что приложение ASP.NET MVC должно выполнять вызовы AJAX на сайт SP и наоборот.

Мое понимание SharePoint, федеративной идентификации, ADFS и т.д., в лучшем случае ограничено, поэтому мое описание нашей системы может отсутствовать, может быть то, что я неправильно, может быть терминологии, что я не получаю право и т. д. Пожалуйста, дайте мне знать, если есть какие-то изменения, которые я могу внести в вопрос, чтобы сделать его более ясным.

Answer 1

Что у вас есть в терминах ADFS - это две отдельные партии поддержки (RP), а именно: сайт SP и новое приложение MVC.

ADFS применяет SSO через них.

Ваше новое приложение. будет основано на требованиях, т. е. вам нужно добавить функциональность WS-Fed через WIF (старше) или OWIN (новый и блестящий).

Refer: Use the OWIN Security Components in ASP.NET to Implement Web Sign On with ADFS для хорошего примера OWIN/ADFS.

Так что происходит, что пользователь входит в SP. Теперь у них есть и пакеты cookie с SP и ADFS. Теперь они входят в приложение MVC. У них нет приложения. чтобы они были перенаправлены в ADFS. ADFS/OWIN видит, что у них есть файлы cookie ADFS, поэтому создается приложение. файлы cookie и пользователь плавно вошли.

Самый чистый метод развертывания - это сделать приложение. новый веб-сайт IIS.

Это имеет два преимущества:

• зависимостей от SP
• Очень легко перейти к Azure в будущем (просто нужно некоторые изменения web.config)

Answer 2

Если ответ мой вопрос в комментариях - это «да», тогда ваш стек MVC должен иметь доступ к файловому файлу FedAuth и запрашивать федеративный сайт для нового токена.

Это означает, что стек MVC будет размещен ниже SharePoint на одном уровне в IIS. Это ответ на ваш Q2 я думаю :)

Пожалуйста, см Sample Federation, delegation and authentication scenarios in SharePoint 2013

конкретно сценарий Федеративные;

1. Клиент в домене доверия Fabrikam отправляет запрос в приложение-доверенное лицо в домене доверия Contoso.

2. Предполагающая сторона перенаправляет клиента в STS в домене доверия Contoso. Этот STS не знает клиента.

3. Contoso STS перенаправляет клиента в STS в домене доверия Fabrikam, с которым доверительный домен Contoso имеет доверительные отношения.

4. Fabrikam STS проверяет личность клиента и выдает маркер безопасности в STS Contoso.

5. Contoso STS использует маркер Fabrikam для создания своего собственного токена, который он отправляет полагающейся стороне.

6. Относящаяся сторона извлекает претензии клиента из токена безопасности и принимает решение об аутентификации.