Freigeben über

Использование утверждений SAML в SharePoint 2010 с сайтами заголовков узлов

  • Artikel

Дата публикации исходной статьи: воскресенье, 19 июня 2011 г.

Однажды кто-то прислал мне интересный вопрос о том, можно ли использовать утверждения SAML с сайтами заголовков узлов в SharePoint 2010.  Сначала я подумал, что можно, но потом решил изучить этот вопрос глубже.  Я выяснил, что ответ действительно положительный, но не все так просто, как я надеялся.  Для своего небольшого примера я создал веб-приложение на сайте https://hh.vbtoys.com и два сайта заголовков узлов:  https://ash.vbtoys.com и https://josh.vbtoys.com.  Хотя это не совсем укладывается в классическую модель сайтов заголовков узлов (я имею в виду запоминающиеся URL-адреса), запомните, что одним из ограничений утверждений SAML и SharePoint является обязательное использование этими сайтами протокола SSL.  Поэтому вместо того, чтобы трудиться над созданием сертификата SSL с дополнительными именами субъектов (SAN), я решил упростить задачу, чтобы можно было использовать сертификат с подстановочными знаками.  Этого достаточно, чтобы доказать работоспособность и показать необходимые настройки, но надеюсь, что это напоминание окажется полезным для тех, кто захочет использовать сайты заголовков узлов и проверку подлинности SAML.

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

  1. Создал новую проверяющую сторону в службах федерации Active Directory, которая использовала https://hh.vbtoys.com/_trust/в качестве конечной точки WS Fed и URN urn:sharepoint:hh.
  2. Добавил область поставщика в свой существующий объект SPTrustedIdentityTokenIssuer следующим образом:

$ap = Get-SPTrustedIdentityTokenIssuer -identity "ADFS IdP"
$uri = new-object System.Uri("https://hh.vbtoys.com")
$ap.ProviderRealms.Add($uri, "urn:sharepoint:hh")
$ap.Update()

Сначала я попробовал обратиться к https://hh.vbtoys.com, и все было хорошо — я зашел на сайт без проблем.  Затем — в реальном тесте идеального сценария — я обратился к https://ash.vbtoys.com.  К сожалению, надежды не оправдались.  Я был перенаправлен на совершенно другой объект SPTrustedIdentityTokenIssuer, поэтому я предположил, что SharePoint выполнил поиск в своем списке областей поставщиков, не смог найти соответствия для https://ash.vbtoys.com и просто захватил первый объект SPTrustedIdentityTokenIssuer из моего списка.

Однако не все еще было потеряно... Как вы, возможно, догадываетесь, в этот момент я мог заставить заработать оба сайта заголовков узлов, но для этого я должен был создать:

  1. Новую проверяющую сторону в службах федерации Active Directory для каждого семейства сайтов заголовков узлов
  2. Новую область поставщика для каждого семейства сайтов заголовков узлов (и добавить их в свой объект SPTrustedIdentityTokenIssuer).  Для этого я использовал точно такую же команду PowerShell, как и приведенная выше, но изменил Url и Urn для каждого сайта.  Например, вот как я добавил поддержку для сайта https://ash.vbtoys.com:

$ap = Get-SPTrustedIdentityTokenIssuer -identity "ADFS IdP"
$uri = new-object System.Uri("https://ash.vbtoys.com")
$ap.ProviderRealms.Add($uri, "urn:sharepoint:ash")
$ap.Update()

Суть этого подхода заключается в добавлении новой проверяющей стороны и области поставщика (Uri и Urn) для каждого семейства сайтов заголовков узлов. После этого я смог входить на все сайты, использующие проверку подлинности SAML.

Это локализованная запись блога. Исходная статья доступна по адресу Using SAML Claims in SharePoint 2010 with Host Header Sites