Поделиться через

Планирование способов проверки подлинности (SharePoint Server 2010)

  • Статья

 

Применимо к: SharePoint Foundation 2010, SharePoint Server 2010

Последнее изменение раздела: 2016-11-30

В этой статье описаны методы и режимы проверки подлинности, поддерживаемые в Microsoft SharePoint Server 2010. Проверка подлинности — это процесс проверки личности пользователя. После проверки личности пользователя процесс проверки прав доступа определяет сайты, контент и другие возможности, к которым пользователь может получить доступ. Режимы проверки подлинности определяют параметры внутреннего использования учетных записей в SharePoint Server 2010.

Содержание:

  • Поддерживаемые методы проверки подлинности

  • Режимы проверки подлинности — классический или на основе утверждений

  • Реализация проверки подлинности Windows

  • Реализация проверки подлинности на основе форм

  • Реализация проверки подлинности на основе маркеров SAML

  • Выбор метода проверки подлинности для сред LDAP

  • Планирование зон для веб-приложений

  • Архитектура поставщиков, основанных на маркерах SAML

Поддерживаемые методы проверки подлинности

В SharePoint Server 2010 поддерживаются представленные в предыдущих версиях методы проверки подлинности, а также реализована проверка подлинности на основе маркеров SAML. В следующей таблице перечислены поддерживаемые методы проверки подлинности.

Метод Примеры Примечания

Windows

  • NTLM

  • Kerberos

  • Анонимная

  • Стандартная

  • Дайджест-проверка

На данный момент проверка подлинности на основе сертификатов Windows не поддерживается.

Проверка подлинности на основе форм

  • Протокол LDAP

  • База данных SQL или другая

  • Настраиваемые и сторонние поставщики членства, а также поставщики ролей

Проверка подлинности на основе маркеров SAML

  • Службы федерации Active Directory (AD FS) 2.0

  • Сторонний поставщик удостоверений

  • Протокол LDAP

Поддерживается только SAML 1.1 на основе профиля WS-Federation Passive.

Режимы проверки подлинности — классический или на основе утверждений

В SharePoint Server 2010 теперь поддерживается проверка подлинности на основе утверждений, построенная на базе Windows Identity Foundation (WIF). Совместно с проверкой подлинности на основе утверждений можно использовать любой из поддерживаемых методов проверки подлинности. Также можно воспользоваться классическим режимом проверки подлинности, который поддерживает проверку подлинности Windows.

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

Проверка подлинности на основе утверждений или в классическом режиме

При выборе классического режима можно реализовать проверку подлинности Windows, и учетные записи пользователей будут обрабатываться в SharePoint Server 2010 как учетные записи доменных служб Active Directory (AD DS).

При выборе проверки подлинности на основе утверждений SharePoint Server 2010 автоматически заменяет все учетные записи пользователей на удостоверения утверждений, в результате чего каждому пользователю назначается маркер утверждений. Маркер утверждений содержит относящиеся к пользователю утверждения. Учетные записи Windows преобразуются в утверждения Windows. Пользователи с членством на основе форм преобразуются в утверждения для проверки подлинности на основе форм. Утверждения, входящие в маркеры SAML, можно использовать в SharePoint Server 2010. Кроме того, разработчики и администраторы SharePoint могут включать в маркеры пользователей дополнительные утверждения. Например, учетные записи пользователей Windows и учетные записи на основе форм можно дополнить утверждениями, используемыми в SharePoint Server 2010.

На следующем рисунке показана поддержка типов проверки подлинности для каждого режима проверки подлинности.

Тип Классический режим проверки подлинности Проверка подлинности на основе утверждений

Windows

  • NTLM

  • Kerberos

  • Анонимная

  • Стандартная

  • Дайджест-проверка

Да

Да

Проверка подлинности на основе форм

  • LDAP

  • База данных SQL или другая

  • Настраиваемые и сторонние поставщики членства, а также поставщики ролей

Нет

Да

Проверка подлинности на основе маркеров SAML

  • Службы федерации Active Directory (AD FS) 2.0

  • Windows Live ID

  • Сторонний поставщик удостоверений

  • LDAP

Нет

Да

В одной ферме SharePoint Server 2010 могут быть размещены веб-приложения, использующие различные режимы проверки подлинности. Службы не делают различия между традиционными учетными записями пользователей Windows и учетными записями на основе утверждений Windows. Следовательно, пользователь, относящийся к сайтам, настроенным на использование обоих режимов проверки подлинности, будет получать результаты поиска со всех сайтов, к которым у него есть доступ, независимо от режима, настроенного для веб-приложений. Пользователь не рассматривается как две отдельных учетных записи. Это происходит потому, что для взаимодействия между фермами службы и приложения-службы используют удостоверения утверждений независимо от режима, выбранного для веб-приложений и пользователей.

Однако пользователи, относящиеся к нескольким репозиториям, распознаваемым веб-приложениями SharePoint Server, рассматриваются как отдельные учетные записи, в зависимости от того, какое удостоверение использовалось для входа в систему.

Приведенные ниже рекомендации помогут выбрать подходящий режим проверки подлинности.

  • Для новых реализаций SharePoint Server 2010 используйте проверку подлинности на основе утверждений. При выборе этого режима веб-приложениям будут доступны все поддерживаемые типы проверки подлинности. Для новых развертываний не имеет смысла выбирать классический режим проверки подлинности, даже если в среде используются только учетные записи Windows. Реализация проверки подлинности Windows не зависит от выбранного режима. При использовании режима проверки подлинности на основе утверждений дополнительные действия для реализации проверки подлинности Windows выполнять не требуется.

  • При обновлении решения предыдущей версии, включающего только учетные записи Windows, до SharePoint Server 2010 можно воспользоваться классическим режимом проверки подлинности. Это позволит сохранить прежнюю структуру зон и URL-адресов.

  • При обновлении решения, требующего проверки подлинности на основе форм, единственно возможный вариант действий — выполнить обновление до проверки подлинности на основе утверждений.

При обновлении с предыдущей версии до SharePoint Server 2010 и выборе проверки подлинности на основе утверждений необходимо учитывать указанные ниже особенности.

  • Может потребоваться обновление настраиваемого кода. Веб-части и другой настраиваемый код, основанный на удостоверениях Windows, необходимо обновить. Если в настраиваемом коде используются удостоверения Windows, используйте классический режим проверки подлинности до тех пор, пока код не будет обновлен.

  • Преобразование множества пользователей Windows в удостоверения утверждений занимает продолжительное время. При переключении во время обновления веб-приложения с классического режима в режим на основе утверждений необходимо преобразовать удостоверения Windows в удостоверения утверждений с помощью Windows PowerShell. Это может занять продолжительное время. При обновлении выделите на выполнение этой задачи достаточно времени.

  • Для проверки подлинности на основе утверждений оповещения поиска в настоящее время не поддерживаются.

Проверка подлинности на основе утверждений реализована на базе WIF. WIF представляет собой набор классов .NET Framework, используемых для реализации удостоверений на основе утверждений. Проверка подлинности на основе утверждений основана на таких стандартах, как WS-Federation и WS-Trust, и таких протоколах, как SAML. Дополнительные сведения о проверки подлинности на основе утверждений см. в указанных ниже ресурсах.

Для использования в SharePoint Server 2010 проверки подлинности на основе утверждений не нужно быть архитектором утверждений. Однако для реализации проверки подлинности на основе маркеров SAML требуется взаимодействие с администраторами среды, построенной на базе утверждений, как показано ниже.

Реализация проверки подлинности Windows

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

Встроенная проверка подлинности Windows — Kerberos и NTLM

Kerberos и NTLM являются встроенными методами проверки подлинности Windows, что позволяет клиентам выполнять проверку подлинности без ввода учетных данных. Пользователи, получающие доступ к сайтам SharePoint через Internet Explorer, проходят проверку подлинности с использованием учетных данных, с которыми был запущен процесс Internet Explorer. По умолчанию это учетные данные пользователя, вошедшего в систему на компьютере. Службы и приложения, получающие доступ к SharePoint Server в режиме встроенной проверки подлинности Windows, проходят проверку с использованием учетных данных запущенного потока, которые по умолчанию представляют собой удостоверение процесса.

NTLM — это самый простой в реализации вариант проверки подлинности Windows. Просто выберите этот параметр при создании веб-приложения.

Kerberos — это надежный протокол, поддерживающий проверку подлинности на основе билетов. Для использования протокола Kerberos требуется дополнительная настройка среды. Чтобы использовать проверку подлинности Kerberos, компьютеры сервера и клиента должны иметь доверенное подключение к домену центра распределения ключей. Настройка протокола Kerberos включает задание имен участников-служб в службах AD DS перед установкой SharePoint Server 2010.

Далее приводится сводка по процессу настройки проверки подлинности Kerberos:

  1. Настройте проверку подлинности Kerberos для соединений SQL, создав имена участников-служб в службах AD DS для учетной записи службы SQL Server.

  2. Создайте имена участников-служб для веб-приложений, которые будут использовать проверку подлинности Kerberos.

  3. Установите ферму SharePoint Server 2010.

  4. Укажите для конкретных служб в ферме, какие учетные записи они должны использовать.

  5. Создайте веб-приложения, которые будут использовать проверку подлинности Kerberos.

Дополнительные сведения см. в статье Планирование реализации проверки подлинности Kerberos (SharePoint Server 2010).

Кроме того, для веб-приложений, использующих проверку подлинности на основе утверждений, для утверждений в службе маркеров Windows должно быть задано ограниченное делегирование. Ограниченное делегирование необходимо для преобразования утверждений в маркеры Windows. В средах с несколькими лесами для использования утверждений в службе маркеров Windows необходимо двустороннее доверие между лесами. Дополнительные сведения о настройке этой службы см. в статье Configure Kerberos authentication for the claims to Windows token service (SharePoint Server 2010).

Проверка подлинности Kerberos позволяет при делегировании учетных данных клиента обращаться к внутренним системам обработки данных, для чего требуется дополнительная настройка в зависимости от варианта использования. См. примеры в следующей таблице.

Сценарий Дополнительная настройка

Делегирование удостоверения клиента внутреннему серверу.

Отображение RSS-канала для прошедшего проверку подлинности контента.

Настройте ограниченное делегирование Kerberos для учетных записей компьютеров и служб.

Делегирование удостоверений для отчетов Microsoft SQL Server (SSRS)

Настройте имена участников-служб для учетных записей Службы SQL Server Reporting Services.

Настройте делегирование для Службы SQL Server Reporting Services.

Делегирование удостоверений для Службы Excel в SharePoint

Настройте ограниченное делегирование для серверов, на которых выполняется служба Службы Excel.

Настройте ограниченное делегирование для учетной записи службы Службы Excel.

Дополнительные сведения о настройке проверки подлинности Kerberos, включая шаги настройки для распространенных сценариев, см. в статье Настройка проверки подлинности Kerberos для продуктов и технологий Microsoft SharePoint 2010 (технический документ) (Возможно, на английском языке) (https://go.microsoft.com/fwlink/?linkid=197178&clcid=0x419) (Возможно, на английском языке).

Проверка подлинности на основе дайджеста и базовая проверка подлинности

Для реализации базовой проверки подлинности и проверки подлинности на основе дайджеста необходимо настроить эти методы проверки подлинности непосредственно в службах IIS.

Реализация подлинности на основе форм

Проверка подлинности на основе форм представляет собой систему управления удостоверениями, основанную на членстве в ASP.NET и проверке подлинности поставщика ролей. В SharePoint Server 2010 проверка подлинности на основе форм доступна только при использовании проверки подлинности на основе утверждений.

Проверка подлинности на основе утверждений может использоваться для учетных данных, хранящихся в службе AD DS, в базе данных, например, SQL Server, или в источнике данных LDAP, таком как Novell eDirectory, Novell Directory Services (NDS) или Sun ONE. Проверка подлинности на основе форм позволяет проверять учетные данные, введенные в форму входа в систему. Запросы, не прошедшие проверку подлинности, перенаправляются на страницу входа, где пользователю необходимо указать допустимые учетные данные и отправить форму. Если проверка подлинности проходит успешно, система создает cookie-файл с ключом для восстановления удостоверения при последующих запросах.

Чтобы использовать проверку подлинности на основе форм для проверки подлинности пользователей во внешней или не основанной на технологиях Windows системе управления удостоверениями, необходимо зарегистрировать поставщик членства и диспетчер ролей в файле Web.config. Требование к регистрации диспетчера ролей появилось в SharePoint Server 2010 впервые. В предыдущей версии она была необязательной. В SharePoint Server 2010 используется стандартный интерфейс диспетчера ролей ASP.NET для сбора сведений о группе текущего пользователя. Каждая роль ASP.NET обрабатывается процессом авторизации SharePoint Server 2010 как доменная группа. Диспетчеры ролей в файле Web.config регистрируются также, как регистрируются поставщики членства для проверки подлинности.

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

Дополнительные сведения о настройке проверки подлинности на основе форм см. в следующих ресурсах:

Реализация проверки подлинности на основе маркеров SAML

Проверка подлинности на основе маркеров SAML требует координации с администраторами среды проверки подлинности на основе утверждений, независимо от того, является ли она внутренней или партнерской средой. Примером среды проверки подлинности на основе утверждений является AD FS 2.0.

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

ВSharePoint Server 2010 используются утверждения из маркеров, предоставляемых службой маркеров безопасности поставщика удостоверений для авторизации пользователей. В средах проверки подлинности на основе утверждений приложение, которое принимает маркеры SAML, называется проверяющей стороной службы маркеров безопасности. Приложение проверяющей стороны принимает маркер SAML и издает внутреннее утверждение, чтобы решить, следует ли предоставлять клиенту доступ к запрошенному ресурсу. В Продукты SharePoint 2010 каждое веб-приложение, в котором настроено использование поставщика SAML, добавляется на сервер службы маркеров безопасности поставщика удостоверений в качестве отдельной записи проверяющей стороны службы маркеров безопасности. Ферма SharePoint может содержать несколько записей проверяющей стороны службы маркеров безопасности.

Для реализации проверки подлинности на основе маркеров SAML в Продукты SharePoint 2010 выполните следующие действия, для которых требуется предварительное планирование:

  1. Экспортируйте сертификат для подписи маркера из службы маркеров безопасности поставщика удостоверений. Этот сертификат называется ImportTrustCertificate. Скопируйте сертификат на компьютер сервера в ферме SharePoint Server 2010.

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

  3. Определите дополнительные сопоставления утверждений. Определите, какие дополнительные утверждения из входящего маркера будут использоваться в ферме SharePoint Server 2010. Роли пользователя являются примером утверждения, которое можно использовать для предоставления разрешения на ресурсы в ферме SharePoint Server 2010. Все утверждения из входящего маркера, для которых нет сопоставления, отклоняются.

  4. Создайте новую службу проверки подлинности, импортировав сертификат для подписи маркера с помощью Windows PowerShell. В результате будет создан объект SPTrustedIdentityTokenIssuer. Во время этого процесса нужно указать идентификационное утверждение и дополнительные сопоставленные утверждения. Также необходимо создать и указать область, связанную с первыми веб-приложениями SharePoint, для которых настраивается использование проверки подлинности на основе маркеров SAML. После создания объекта SPTrustedIdentityTokenIssuer можно создать и добавить дополнительные области для других веб-приложений SharePoint. Таким образом в нескольких веб-приложениях задается использование одного объекта SPTrustedIdentityTokenIssuer.

  5. Для каждой области, добавленной в SPTrustedIdentityTokenIssuer, необходимо создать запись проверяющей стороны службы маркеров безопасности в службе маркеров безопасности поставщика удостоверений. Это можно сделать до создания веб-приложения SharePoint. Независимо от этого, запланировать URL-адрес необходимо до создания веб-приложений.

  6. Создайте новое веб-приложение SharePoint и настройте в нем использование только что созданной службы проверки подлинности. Служба проверки подлинности будет появляться в качестве варианта в центре администрирования при выборе режима утверждений для веб-приложения.

Можно настроить несколько служб проверки подлинности на основе маркеров SAML. Однако использовать сертификат для подписи маркера в ферме можно только один раз. Все настроенные службы появятся в качестве вариантов в центре администрирования. Утверждения из разных доверенных сред службы маркеров безопасности не конфликтуют.

Если проверка подлинности на основе маркеров SAML реализуется совместно с партнерской компанией и используемая среда включает службу маркеров безопасности поставщика удостоверений, рекомендуется связаться с администратором внутренней среды проверки подлинности на основе утверждений, чтобы установить доверенное отношение между внутренней службой маркеров безопасности поставщика удостоверений и службой маркеров безопасности партнера. При таком подходе добавлять дополнительную службу проверки подлинности в ферму SharePoint Server 2010 не нужно. Он также позволяет администраторам среды утверждений управлять всей средой.

Примечание

При использовании проверки подлинности на основе маркеров SAML с AD FS в ферме SharePoint Server 2010, в которой находится несколько веб-серверов в конфигурации с балансировкой нагрузки, она может оказать негативное влияние на производительность и функциональность представлений клиентских веб-страниц. Когда AD FS предоставляет клиенту маркер проверки подлинности, этот маркер передается SharePoint Server 2010 для каждого элемента страницы с ограниченными разрешениями. Если в решении с балансировкой нагрузки не используется сходство, каждый защищаемый элемент проходит проверку подлинности на нескольких серверах SharePoint Server 2010, что может привести к отклонению маркера. После отклонения маркера SharePoint Server 2010 перенаправляет клиент для повторной проверки подлинности обратно на сервер AD FS. После этого сервер AD FS может отклонить несколько запросов, сделанных в короткий период времени. Такое поведение определено специально для защиты от атак типа "отказ в обслуживании". При снижении производительности или неполной загрузке страниц можно установить балансировку сетевой нагрузки в режим с одиночным сходством. Это позволяет изолировать запросы маркеров SAML к одному веб-серверу.

Дополнительные сведения о настройке проверки подлинности на основе маркеров SAML см. в следующих ресурсах:

Выбор метода проверки подлинности для сред LDAP

Среды LDAP можно реализовывать с помощью проверки подлинности на основе форм или на основе маркеров SAML. Рекомендуется использовать проверку подлинности на основе форм, поскольку она проще. Однако если среда поддерживает спецификацию WS-Federation 1.1 и SAML Token 1.1, рекомендуется использовать SAML. Для поставщиков LDAP, не связанных с ADFS 2.0, синхронизация профилей не поддерживается.

Планирование зон для веб-приложений

Зоны представляют собой разные логические пути для получения доступа к одним сайтам в веб-приложении. Каждое веб-приложение может включать до пяти зон. При создании веб-приложения создается зона по умолчанию. Дополнительные зоны создаются путем расширения веб-приложения и выбора одной из оставшихся зон: интрасеть, экстрасеть, Интернет или другая.

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

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

  • Классический режим — как и в предыдущих версиях для одной зоны можно реализовать только один тип проверки подлинности. Тем не менее в текущей версии при выборе классического режима можно реализовать только проверку подлинности Windows. Соответственно, несколько зон можно использовать только для реализации нескольких типов проверки подлинности Windows или проверки подлинности Windows одного типа для разных хранилищ Active Directory.

  • Проверка подлинности на основе утверждений — в одной зоне можно реализовать несколько служб проверки подлинности. Также можно использовать несколько зон.

Реализация нескольких типов проверки подлинности в одной зоне

Если при использовании проверки подлинности на основе утверждений реализуется несколько типов проверки подлинности, рекомендуется реализовать несколько типов проверки подлинности в зоне по умолчанию. Это позволяет предоставлять один URL-адрес для всех пользователей.

При реализации нескольких типов проверки подлинности в одной зоне применяются следующие ограничения:

  • В одной зоне можно реализовать только один экземпляр проверки подлинности на основе форм.

  • Центр администрирования позволяет одновременно использовать встроенную и базовую проверку подлинности Windows. В других случаях реализовывать в одной зоне более одного типа проверки подлинности Windows нельзя.

Если для фермы задано несколько служб проверки подлинности на основе маркеров SAML, при создании веб-приложения или новой зоны можно выбрать одну из них. В одной зоне можно настроить несколько поставщиков SAML.

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

Несколько типов проверки подлинности в зоне

На схеме пользователи из разных хранилищ службы каталогов обращаются к партнерскому веб-сайту с помощью одного URL-адреса. Штриховая рамках вокруг партнерских компаний показывает отношение между каталогом пользователя и типом проверки подлинности, заданным для зоны по умолчанию. Дополнительные сведения о примере такого проекта см.. в разделе Пример проекта: корпоративное развертывание (SharePoint Server 2010).

Планирование для обхода контента

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

Реализация нескольких зон

Если в веб-приложении планируется реализация нескольких зон, придерживайтесь следующих рекомендаций:

  • Для реализации наиболее безопасных параметров проверки подлинности используйте зону по умолчанию. Если запрос невозможно связать с определенной зоной, применяются параметры проверки подлинности и другие политики безопасности зоны по умолчанию. Зона по умолчанию — это зона, созданная при первоначальном создании веб-приложения. Обычно наиболее безопасные параметры проверки подлинности предназначены для доступа конечных пользователей. Таким образом, конечные пользователи, как правило, будут использовать зону по умолчанию.

  • Используйте минимальное число зон, которое требуется для обеспечения доступа пользователей. Каждая зона связана с новым сайтом и доменом IIS для доступа к веб-приложению. Новые точки доступа следует добавлять только при необходимости.

  • Убедитесь, что хотя бы одна зона настроена на использование проверки подлинности NTLM для компонента обхода контента. Не следует без необходимости создавать выделенную зону для компонента индексирования.

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

Одна зона для каждого типа проверки подлинности

На схеме зона по умолчанию используется для удаленных сотрудников. У каждой зоны имеется свой связанный с ней URL-адрес. Сотрудники используют разные зоны в зависимости от того, работают они из офиса или на выезде. Дополнительные сведения о примере такого проекта см.. в разделе Пример проекта: корпоративное развертывание (SharePoint Server 2010).

Архитектура для поставщиков проверки подлинности на основе маркеров SAML

Архитектура для реализации поставщиков проверки подлинности на основе маркеров SAML включает следующие компоненты:

Служба маркеров безопасности SharePoint   Эта служба создает маркеры SAML, которые используются в ферме. Служба автоматически создается и запускается на всех серверах в ферме серверов. Служба используется для взаимодействия между фермами, поскольку для любой связи между фермами используется проверка подлинности на основе утверждений. Эта служба также используется для методов проверки подлинности, реализованных для веб-приложений с проверкой подлинности на основе утверждений, включая проверку подлинности Windows, проверку подлинности на основе форм и маркеров SAML. Во время развертывания необходимо настроить службу маркеров безопасности. Дополнительные сведения см. в разделе Настройка службы маркеров безопасности (SharePoint Server 2010).

Сертификат для подписи маркера (ImportTrustCertificate)   Это сертификат, экспортированный из службы маркеров безопасности поставщика удостоверений. Сертификат копируется на один сервер в ферме. После использования этого сертификата для создания объекта SPTrustedIdentityTokenIssuer, использовать его для создания другого объекта нельзя. При необходимости использовать сертификат для создания другого объекта SPTrustedIdentityTokenIssuer сначала нужно удалить первый объект. Перед удалением необходимо отменить его связи со всеми веб-приложениями, которые могут его использовать.

Идентификационное утверждение   Идентификационное утверждение — это утверждение из маркера SAML, являющееся уникальным идентификатором пользователя. Только владелец службы маркеров безопасности поставщика удостоверений знает, какое значение в маркере всегда будет уникальным для каждого пользователя. Идентификационное утверждение создается в качестве обычного сопоставления во время процесса сопоставления всех нужных утверждений. Идентификационное утверждение объявляется при создании объекта SPTrustedIdentityTokenIssuer.

Другие утверждения   Эти утверждения состоят из дополнительных утверждений из билета SAML, которые описывают пользователей. Среди них могут быть указание ролей пользователей, групп пользователей и другие виды утверждений, например, указание возраста. Все сопоставления утверждений создаются в виде объектов, которые заменяются на серверах в ферме SharePoint Server.

Область   В архитектуре утверждений SharePoint URI или URL-адрес, связанный с веб-приложением SharePoint, использующим службу проверки подлинности на основе маркеров SAML, представляет область. При создании службы проверки подлинности на основе маркеров SAML в ферме по одной указываются области (URL-адреса веб-приложения), которые должны распознаваться службой маркеров безопасности поставщика удостоверений. Первая область указывается при создании объекта SPTrustedIdentityTokenIssuer. Дополнительные области можно включить после создания SPTrustedIdentityTokenIssuer. Области создаются с использованием синтаксиса вида: $realm = "urn:sharepoint:mysites". После добавления области в объект SPTrustedIdentityTokenIssuer необходимо создать отношение доверия для проверяющей стороны службы маркеров безопасности в области на сервере службы маркеров безопасности поставщика удостоверений. Это включает указание URL-адреса для веб-приложения.

SPTrustedIdentityTokenIssuer   Это объект, который создается в ферме SharePoint и включает значения, необходимые для взаимодействия со службой маркеров безопасности поставщика удостоверений и получения от нее маркеров. При создании SPTrustedIdentityTokenIssuer указывается сертификат для подписи маркера, который нужно использовать, первая область, идентификационное утверждение и все дополнительные утверждения. Сертификат для подписи маркера из службы маркеров безопасности можно связать только с одним объектом SPTrustedIdentityTokenIssuer. Однако после создания SPTrustedIdentityTokenIssuer можно добавить дополнительные области для других веб-приложений. После добавления области в SPTrustedIdentityTokenIssuer ее также необходимо добавить в службу маркеров безопасности поставщика удостоверений в качестве проверяющей стороны. Объект SPTrustedIdentityTokenIssuer реплицируется на серверах в ферме SharePoint Server.

Проверяющая сторона службы маркеров безопасности   В SharePoint Server 2010, каждое веб-приложение, в котором настроено использование поставщика SAML, добавляется на сервер службы маркеров безопасности поставщика удостоверений в качестве записи проверяющей стороны службы маркеров безопасности. Ферма SharePoint Server может содержать несколько записей проверяющей стороны службы маркеров безопасности.

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

На следующем рисунке показана архитектура утверждений в Продукты SharePoint 2010.

Компоненты проверки подлинности SharePoint на основе утверждений

Объект SPTrustedIdentityTokenIssuer создается с использованием нескольких параметров. На следующей схеме показаны основные параметры.

Структура SPTrustedIdentityTokenIssuer

Как показано на схеме, SPTrustedIdentityTokenIssuer может содержать только одно идентификационное утверждение, один параметр SignInURL и один параметр Wreply. Тем не менее он может включать несколько областей и сопоставлений утверждений. Параметр SignInURL указывает URL-адрес, на который перенаправляется запрос пользователя для проверки подлинности в службе маркеров безопасности поставщика утверждений. Некоторые серверы службы маркеров безопасности поставщика утверждений требуют наличия параметра Wreply, который может принимать значение true или false и по умолчанию имеет значение false. Используйте параметр Wreply, только если он требуется службой маркеров безопасности поставщика утверждений.