Федеративная проверка подлинности SAML с помощью SharePoint 2010 и Azure Access Control Service. Часть 1

Artikel
06/29/2011

Исходная статья опубликована в пятницу 6 мая 2011 г.

ПРИМЕЧАНИЕ. Форматирование на этом сайте обычно не отличается высоким качеством. Для удобства прочтения рекомендуется загрузить документ Word, который доступен в приложении к этой записи блога.

Недавно я более подробно рассматривал Windows Azure Access Control Service (ACS) и возможности использования различных параметров интеграции. Проверка подлинности на основе утверждений в SharePoint 2010 и способы интеграции ADFS, Windows Live, Facebook и т. д. всегда были популярной темой для обсуждения. Служба ACS (истинные приверженцы Azure и специалисты по маркетингу обычно называют ее AppFabric ACS) достаточно эффективна, так как содержит "соединители" для этих общих поставщиков готовых удостоверений. При настройке пространства имен ACS (рассматривайте его как учетную запись с соединителями и параметрами конфигурации) подключение к ADFS 2.0, Windows Live, Yahoo, Google и Facebook упрощается и стандартизируется. Как истинно ленивый программист я подумал: "Ого, должно быть, там что-то такое происходит!" — и решил рассмотреть этот вопрос с разных сторон. Первый из аспектов рассматривается в этой записи блога.

Для этого сценария я хотел просто установить отношения доверия непосредственно между SharePoint 2010 и ACS. Я хотел иметь возможность использовать учетные записи ADFS, Windows Live, Yahoo и Google для проверки подлинности и входа на сайт SharePoint. Я не упомянул Facebook, так как социальные сети — не мой конек (этот блог — единственное, в чем я преуспел в этой области). У меня нет учетных записей Facebook или Twitter, поскольку я не очень стремлюсь постоянно делиться с окружающим миром несущественной информацией (" Мурка только что родила троих котят. Какая прелесть!! "). Я НЕ буду объяснять, как зарегистрировать учетную запись Windows Azure, создать пространство имен Access Control Service, осуществлять управление ACS и т. д. — в сети наверняка есть масса информации, предоставленной специалистами по Windows Azure, так что я не собираюсь повторяться, рассказывая об этом.

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

Откройте страницу управления контролем доступа
1. Войдите в учетную запись портала управления Windows Azure. Щелкните меню "Шина обслуживания", "Контроль доступа" и "Кэширование" в области слева. Щелкните "Контроль доступа" в верхней части области слева (в разделе "AppFabric"), выберите свое пространство имен в области справа и нажмите кнопку "Access Control Service" в разделе "Управление" на ленте. После этого отобразится страница "Управление контролем доступа".
Добавьте поставщика удостоверений для ADFS
1. Выберите пункт "Поставщики удостоверений" в меню "Отношения доверия" в области слева.
2. Щелкните ссылку "Добавить"
3. Переключатель "Поставщик удостоверения WS-Federation" должен быть выбран по умолчанию. Выберите его, если он еще не выбран. Именно этот параметр используется для ADFS 2.0. Нажмите кнопку "Далее".
4. Введите данные в разделе "Параметры поставщика удостоверений"
  1. Укажите отображаемое имя, например "Мой сервер ADFS"
  2. Что касается метаданных WS-Federation, если доступ к серверу ADFS осуществляется через Интернет, достаточно просто ввести URL-адрес конечной точки метаданных федерации. По умолчанию используется URL-адрес: https://yourAdfsServer.com/FederationMetadata/2007-06/FederationMetadata.xml. Если доступ к серверу ADFS через Интернет невозможен, введите указанный URL-адрес в адресной строке локального браузера. Откройте браузер и сохраните страницу в локальной файловой системе в формате XML. Затем, в разделе "Параметры поставщика удостоверений" в ACS нажмите кнопку рядом с полем редактирования "Файл" и воспользуйтесь кнопкой "Обзор", чтобы найти сохраненный XML-файл метаданных федерации.

Вот, собственно, и все, что потребуется для создания поставщика удостоверений в ACS.

3. Добавьте проверяющую сторону для SharePoint

1. Теперь необходимо добавить SharePoint в качестве проверяющей стороны для ACS, так же как и при одновременной настройке SharePoint и ADFS. Для начала перейдите по ссылке "Приложения проверяющей стороны", расположенной под меню "Отношения доверия" в области слева.
2. Щелкните ссылку "Добавить".
3. Введите данные в раздел "Параметры приложений проверяющей стороны"
  1. Укажите отображаемое имя, например "SharePoint 2010"
  2. Используйте режим по умолчанию или введите настройки вручную
  3. В поле редактирования "Область" укажите соответствующую область и сохраните эти сведения, так как они будут использоваться повторно при создании элемента SPTrustedIdentityTokenIssuer в SharePoint. В этом примере в качестве области используется "sharepoint:acs".
  4. В качестве URL-адреса возврата используйте тот же формат, что и при настройке SharePoint в качестве проверяющей стороны в ADFS: https://yourSiteName/_trust/.
  5. В раскрывающемся списке формата маркеров выберите значение "SAML 1.1"
  6. Для времени жизни маркера можно задать любое значение (в секундах). По умолчанию используется значение 10 минут; я предпочитаю установить значение "3600", то есть 1 час.
4. Введите данные в разделе "Параметры проверки подлинности"
  1. Установите все флажки в разделе "Поставщики удостоверений". После этого должен отобразиться поставщик удостоверения ADFS, созданный в предыдущем шаге.
  2. В разделе "Группы правил" оставьте выбранным параметр по умолчанию — "Создать новую группу правил".
5. В разделе "Параметры подписи маркера" можно оставить выбранным параметр по умолчанию, то есть "Использовать сертификат пространства имен службы (стандартный)".
6. Нажмите кнопку "Сохранить", чтобы сохранить изменения и создать проверяющую сторону

4. Создайте правила для проверяющей стороны

1. Предполагается, что набор правил в ACS не был создан ранее, так что в настоящее время создается новая группа правил. Если вы хотите повторно использовать какую-то из групп, в предыдущем шаге необходимо было установить флажок рядом с группой (группами), которые будут использованы для проверяющей стороны вместо параметра по умолчанию "Создать новую группу правил". Но, поскольку мы создаем новую группу, перейдите по ссылку "Группы правил" в меню "Отношения доверия" в области слева
2. Отобразится группа правила примерно с таким именем: "Группа правил по умолчанию для проверяющей стороны с таким-то именем". Щелкните ссылку этого имени группы правил
3. На этом этапе проще всего щелкнуть ссылку "Создать". При этом автоматически создается набор правил, в котором перечисляются все утверждения, получаемые от каждого поставщика удостоверений, после чего создается правило для всех поставщиков, передающих проверяющей стороне это значение утверждения с тем же типом утверждения
4. На странице "Создание правил" просто установите флажок рядом с каждым поставщиком удостоверений и нажмите кнопку "Создать". При этом будут созданы описанные ранее правила. По завершении процедуры вы будете переадресованы на страницу "Редактировать группу правил", на которой отображаются все перечисленные правила. В большинстве случаев этого достаточно, однако здесь следует отметить одну особенность. В SharePoint этот адрес электронной почты мы собирались использовать в качестве идентификационного утверждения. Забавно, что адрес электронной почты присылают (и для этого создаются соответствующие правила) все поставщики удостоверений, кроме Windows Live. Таким образом, в этом примере я имитирую ту часть, которая относится к Windows Live. Я имею в виду, что собираюсь использовать то предоставленное утверждение "nameidentifier" для создания правила, передающего утверждение обратно. Однако утверждение будет передано обратно как утверждение электронной почты. Не стоит прямо сейчас начинать ненавидеть Стива — это просто способ запустить демо-среду, используя для этого сравнительно небольшое число механизмов (некоторое количество уже используется). Теперь добавим это конечное правило
5. Щелкните ссылку "Добавить"
6. В раскрывающемся списке "Поставщик удостоверения" выберите "Windows Live ID"
7. В разделе "Тип входящего утверждения" нажмите кнопку рядом с пунктом "Выбор типа":. Windows Live ID поддерживает только один тип утверждения, поэтому он уже выбран (идентификатор имени "nameidentifier")
8. Прокрутите страницу до раздела "Тип исходящего утверждения" и нажмите кнопку рядом с пунктом "Выбор типа":
9. В раскрывающемся списке найдите и выберите пункт https://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress
10. При необходимости введите описание и нажмите кнопку "Сохранить", чтобы сохранить изменения и создать правило
11. Вы будете перенаправлены на страницу "Редактировать группу правил". После этого нажмите кнопку "Сохранить", чтобы сохранить все изменения. Настройка конфигурации ACS завершена, однако, не следует пока закрывать браузер, так как нам потребуется представленная в нем дополнительная информация при создании и настройке остальных компонентов.

5. Создайте проверяющую сторону для ACS в ADFS

1. ADFS является поставщиком удостоверения для ACS, а ACS выступает как проверяющая сторона для ADFS. Это означает, что необходимо настроить проверяющую сторону в ADFS, чтобы при перенаправлении ACS запроса на проверку подлинности в ADFS можно было установить отношения доверия, позволяющие ADFS отправлять отклик. Для начала перейдите на сервер ADFS и откройте консоль управления AD FS 2.0
2. Перейдите в раздел "Службы федерации Active Directory 2.0...", затем в раздел "Отношения доверия...", в узел "Отношения доверия для проверяющей стороны" и щелкните ссылку "Добавить отношения доверия проверяющей стороны..." в области справа
3. Нажмите кнопку "Пуск", чтобы запустить мастер
4. Используйте параметр по умолчанию для импорта данных о проверяющей стороне, опубликованных в Интернете. Для этого используйте URL-адрес портала управления ACS. Вернитесь в браузер, в котором открыта страница портала, и щелкните ссылку "Интеграция приложения" в меню "Отношения доверия" в области слева
5. Скопируйте URL-адрес, отображаемый для метаданных WS-Federation, и вставьте его в строку для адреса метаданных интеграции (имя или URL-адрес узла): откройте поле редактирования в мастере ADFS, после чего нажмите кнопку "Далее"
6. Введите отображаемое имя и примечания (если есть), после чего нажмите кнопку "Далее"
7. Оставьте выбранным параметр по умолчанию "Разрешить доступ к проверяющей стороне для всех пользователей" и нажмите кнопку "Далее"
8. Нажмите кнопку "Далее", чтобы создать проверяющую сторону
9. По завершении создания проверяющей стороны откройте редактор правил в ADFS, чтобы создать новые правила для передачи значений утверждения в ACS
10. Выберите вкладку "Правила преобразования выдачи" и нажмите кнопку "Добавить правило..."
11. Оставьте выбранным шаблон по умолчанию "Отправить атрибуты LDAP как утверждения" и нажмите кнопку "Далее".
12. Введите остальные сведения о правиле:
  1. Введите имя правила утверждения
  2. В раскрывающемся списке "Хранилище атрибутов" выберите "Active Directory"
  3. В разделе "Сопоставление атрибутов LDAP" сопоставьте
    1. адреса электронной почты атрибута LDAP с адресом электронной почты типа исходящего утверждения
    2. Группы-маркеры атрибута LDAP — неполные имена для роли типа исходящего утверждения
  4. Нажмите кнопку "Готово", чтобы сохранить правило. Настройка ADFS завершена.

6. Настройте отношения доверия SharePoint с ACS

1. Это многоэтапный процесс, на начальной стадии которого выполняется получение сертификата для подписи маркера из ACS. К счастью, сертификат включен в файл FederationMetadata.xml, поэтому сертификат будет получен оттуда и сохранен локально на сервере SharePoint. На сервере SharePoint откройте браузер и откройте страницу управления контролем доступа, как описано выше
2. Щелкните ссылку "Интеграция приложения" под меню "Отношения доверия" в области слева; скопируйте URL-адрес, отображаемый для метаданных WS-Federation и вставьте его в адресную строку браузера. Файл службы ACS FederationMetadata.xml отобразится в браузере.
3. Найдите раздел, который имеет следующий вид (примерно второй по величине раздел в верхней части страницы):

<X509Certificate>MIIDEDCCAfiblahblahblah</X509Certificate>

</X509Data>

Скопируйте данные из элемента X509Certificate и вставьте его в блокнот. Сохраните данные в файл с расширением CER (необходимо использовать кодировку ANSI); в рамках этого примера предположим, что вы выполняете вызов файла C:\AcsTokenSigning.cer. Это файл представляет собой сертификат для подписи маркера для ACS.

1. Добавьте сертификат для подписи маркера ACS в список надежных центров сертификации в SharePoint. Можно воспользоваться процедурой, описанной на странице https://blogs.technet.com/b/speschka/archive/2010/07/07/managing-trusted-root-authorities-for-claims-authentication-in-sharepoint-2010-central-admin.aspx, или добавьте сертификат с помощью PowerShell следующим образом:

$cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("c:\AcsTokenSigning.cer")

New-SPTrustedRootAuthority -Name "ACS Token Signing" -Certificate $cert

1. Далее необходимо создать новый объект SPTrustedIdentityTokenIssuer. Я уже писал об этом ранее — можно использовать https://blogs.technet.com/b/speschka/archive/2010/07/30/configuring-sharepoint-2010-and-adfs-v2-end-to-end.aspx в качестве начальной точки (просто прокрутите вниз до раздела, отображаемого ПОСЛЕ сведений о настройке ADFS). Необходимо учесть следующее:
  1. Типы утверждений name и nameidentifier являются зарезервированными типами утверждений в SharePoint, поэтому несмотря на то, что тип nameidentifier является единственным общим утверждением у стандартных поставщиков удостоверений в ACS, не следует выбирать его для утверждения удостоверения. Вместо этого я рекомендовал бы сейчас просто вернуться к адресу электронной почты и добавить соответствующие правила в ACS, как описано ранее
  2. Параметр SignInUrl для New-SPTrustedIdentityTokenIssuer должен указывать на экземпляр службы ACS. (например, https://myAcsNamespace.accesscontrol.windows.net:443/v2/wsfederation. ) Этот экземпляр можно найти в проверяющей стороне, заданной в ADFS для службы ACS. Откройте диалоговое окно свойств проверяющей стороны, перейдите на вкладку "Конечные точки" и используйте URL-адрес, отображаемый для пассивной конечной точки WS-Federation для привязки POST (она должна быть единственной).
2. На последнем этапе следует создать веб-приложение, настроить его для использования проверки подлинности утверждений и объекта SPTrustedIdentityTokenIssuer, созданного для ACS, а также создать семейство веб-сайтов в веб-приложении и начать тестирование.

На этом этапе следует подготовиться к запуску сайта и проверить его возможности. Необходимо помнить о том, что для входа на сайт вы должны обязательно настроить администратора семейства сайтов как один из адресов электронной почты, возвращаемый одним из поставщиков удостоверения. После входа на сайт можно добавить адреса электронной почты или утверждения роли из поставщиков в группы SharePoint, как вы поступили бы в обычных случаях.

Опять же, не забывайте о сделанном ранее предупреждении, качающемся Windows Live ID. Как говорилось ранее в этой записи блога, на самом деле у вас еще нет действующего адреса электронной почты для Windows Live, поэтому необходимо добавить PUID в группу SharePoint. В рамках тестирования проще всего получить такой идентификатор, выполнив вход с использованием Windows Live ID; после этого вы будете перемещены на страницу в SharePoint с уведомлением о том, что вы выполнили вход с учетными данными "foo” и доступ запрещен. Здесь можно скопировать PUID, войти в систему с учетными данными администратора, добавить PUID в группу SharePoint и спокойно выполнить вход. Я даже не посмотрел, какие параметры каталога доступны (если доступны) для Windows Live ID (думаю, что таких параметров нет). Но это только начало, поэтому можно продолжить проверку данной концепции. Теперь вот так выглядит вход на мой сайт с использованием каждого из следующих поставщиков удостоверений:

Страница входа

ADFS

Google

Yahoo

Windows Live ID

Это локализованная запись блога. Исходная статья находится по адресу: Federated SAML Authentication with SharePoint 2010 and Azure Access Control Service Part 1

Freigeben über

Федеративная проверка подлинности SAML с помощью SharePoint 2010 и Azure Access Control Service. Часть 1

Zusätzliche Ressourcen