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

В 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.

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

Проверка подлинности на основе форм представляет собой систему управления удостоверениями, основанную на членстве в 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.

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

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

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

История изменений

Дата Описание

7 февраля 2012 г.

2012/02/06

28 июня 2011 г.

2011/06/20

02 сентября 2010 г.

2010/08/30

05 августа 2010 г.

2010/08/02

2010/05/12

Первоначальная публикация