Кевин Лаахс (kevin.laahs@hp.com) - специалист по стратегическим технологиям в HP Enterprise Services

Доступ к контенту с авторизацией, предусмотренный в Microsoft SharePoint, рассматривался в статье «Основы безопасности SharePoint», опубликованной в Windows IT Pro/RE № 11 за 2012 год. Для присвоения прав доступа SharePoint должен уметь идентифицировать пользователя, который пытается получить доступ к контенту. Таким образом, идентификация пользователя является критичной для работы служб, таких как User Profile: идентификация пользователя управляет тем, что они могут делать с персональными домашними страницами и функциями социальных сетей.

Аутентификация – это часть общего процесса идентификации пользователя. В ходе аутентификации пользователи предоставляют особый ключ, чтобы SharePoint определил, кто они такие. Далее SharePoint использует этот ключ для связывания пользователя с внутренним объектом (называемым SPUser), который далее применяется при авторизации доступа к контенту.

В предыдущих версиях SharePoint этот ключ мог быть стандартным ключом системы безопасности Windows, представляющим собой либо пользовательский объект или группу безопасности Active Directory (AD), либо ключ, сгенерированный провайдером членства и ролей ASP.NET. Хотя он все еще поддерживает классическую идентификацию Windows, SharePoint 2010 также поддерживает и вариант идентификации на основе заявок, который приводит к некоторым дополнительным возможностям. Например, SharePoint может принимать участие в инфраструктуре аутентификации, которая не основана на Windows, получая в качестве преимуществ простое делегирование идентификации во внутренних приложениях, а также упрощенную и цельную среду для разработчиков решений.

.

Идентификация, основанная на заявках

При использовании заявок идентичность пользователя определяется рядом атрибутов, которые описывают пользователя: электронный почтовый адрес, полное имя, группа, к которой пользователь может принадлежать, страна проживания и даже могут быть более личные сведения, такие как номер паспорта или водительских прав. Служба выдачи этих сведений Active Directory Federation Services (ADFS), которой вы полностью доверяете, выдает по заявкам эти атрибуты и их значения.

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

Упоминание безусловного доверия важно. Без него системы идентификации, основанные на заявках, были бы невозможны. Ваше приложение должно выбрать центр идентификации, заявкам которого будет доверять. Рассмотрим такой атрибут, как возраст. Вы можете довериться людям, когда они указывают свой возраст, если его использование внутри вашего приложения служит для чисто информационных целей. Например, на самом деле неважно, ввожу ли я свой реальный возраст на страничке Facebook. Но если целью является верификация того, что кому-то законом разрешено покупать алкоголь, вы захотите получить ответ от более достоверного источника – некоего центра, который может подтвердить информацию, такого как отдел регистрации актов гражданского состояния.

SharePoint 2010 является приложением, использующим заявки, а это означает, что он на самом деле не беспокоится об аутентификации пользователя. Он беспокоится о получении ключа Security Assertion Markup Language (SAML), предоставляющего значения атрибутов, которые могут применяться для идентификации пользователя. Эта возможность позволяет SharePoint быть развернутым в средах, которые могут потребовать больше методов аутентификации, доступных через Интернет, чем может предоставить обычная система Windows. Это также означает, что вы можете вносить изменения в доступные методы аутентификации без изменения, повторной компиляции либо повторной настройки SharePoint или любых решений на его базе.

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

  1. Когда вы подходите к выходу на посадку, вы предъявляете посадочный талон – в бумажном или электронном виде – сотрудникам аэропорта.
  2. Сотрудники удостоверяются, что пропуск на посадку не является подделкой (используя штрих-код или магнитную ленту) и что он был выдан авиакомпанией.
  3. Поскольку сотрудники доверяют авиакомпании, они доверяют деталям (то есть заявкам), таким как номер места, имя и номер рейса, которые есть на посадочном талоне.
  4. Сотрудники разрешают вам посадку на самолет.

У вас есть разные способы получить посадочный талон, такие как регистрация по Интернету или на стойке регистрации. Независимо от того, как вы получили посадочный талон, вы должны предоставить некоторую учетную информацию (номер регистрации, паспорт или водительские права) для того, чтобы подтвердить свою личность, прежде чем талон будет выписан на вас.

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

В терминах программного обеспечения, набор заявок называется ключом безопасности. Издатель подписывает каждый ключ. Приложение, основанное на заявках, считает, что пользователь аутентифицирован, если он предоставит действующий подписанный ключ безопасности от доверенного издателя. Неважно, какой был использован протокол аутентификации. Приложение получает ключ безопасности в простом стандартном формате (например, SAML), который приложение может, соответственно, использовать для определения аутентификации и уровней разрешений для конкретного пользователя. Также приложение может разрешить доступ к своим ресурсам, используя заявки, которые представляет пользователь.

Аутентификация, основанная на заявках

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

Первый способ известен как классическая аутентификация. Этот метод задействует идентификацию Windows для проверки пользователей и поддерживает только одного провайдера аутентификации: Windows (или AD). Второй метод известен как аутентификация, основанная на заявках. Этот метод использует заявки для идентификации пользователей и поддерживает трех провайдеров аутентификации — Windows (или AD), аутентификацию на базе форм и доверенных провайдеров идентичности. Все они могут быть использованы для одного и того же веб-приложения. Все эти провайдеры приводят к генерации ключа SAML и его последующего представления SharePoint, когда дается доступ к ресурсам.

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

  • вы хотите предоставить контролируемый доступ по Интернету тем, у кого нет учетных записей в вашем домене AD;
  • возможно, произошло слияние с другой организацией, и у вас еще нет доверительных взаимоотношений между разными лесами доменов, поэтому аутентификация Windows невозможна;
  • вам нужно провести интеграцию с внутренним приложением, которое не запускается на Windows, и необходим способ делегировать идентификацию пользователей из SharePoint во внутреннее приложение.

SharePoint 2010 использует платформу Microsoft Windows Identity Foundation (WIF – бывшее кодовое имя Geneva Framework) для реализации идентификации, основанной на заявках. WIF представляет собой набор классов Microsoft. NET Framework, которые делают возможным создание приложений на базе запросов аутентификации WS-Federation. WS-Federation является протоколом аутентификации, который строится на двух других стандартных протоколах: WS-Trust и WS-Security. WS-Federation поддерживает архитектуру аутентификации, основанную на ключах, которая позволяет веб-приложению запрашивать секретный ключ для доступа к ресурсам с аутентификацией.

С идентификацией, основанной на заявках, SharePoint становится непривязанным к определенным провайдерам идентификации, таким как провайдеры аутентификации AD и ASP.NET, которые были единственными доступными провайдерами в SharePoint 2007. Вместо этого вы можете задействовать любого провайдера идентификации, который был спроектирован и реализован в соответствии со стандартами системы безопасности WS-*. Это означает, что вы можете использовать таких провайдеров идентификации, как Windows LiveID, OpenID (например, Google, Yahoo) и ADFS.

Но SharePoint на самом деле идет гораздо дальше. Помимо принятия запросов на аутентификацию от WS-Federation, SharePoint теперь принимает запросы Windows и запросы, основанные на формах аутентификации, и конвертирует их в заявку. Такое требование впоследствии может быть использовано внутри SharePoint для коммуникации со служебными приложениями и делегирования другим сторонним приложениям, которые поддерживают заявки. Более того, SharePoint также предоставляет заявки для службы Claims to Windows Token Service (c2WTS), которая может конвертировать заявку обратно в запрос Kerberos для интеграции с приложениями, которые не основаны на заявках.

Служба секретного ключа SharePoint

Чтобы отправить провайдеру идентификации неаутентифицированные запросы на ресурсы SharePoint и конвертировать возвращаемые секретные ключи в заявки (например, ключи SAML), в SharePoint предусмотрена собственная служба секретного ключа Security Token Service (STS).

STS является веб-службой, которая вступает в игру с любым веб-приложением, которое было активировано на аутентификацию, основанную на заявках.

На рисунке показаны высокоуровневые шаги, выполняемые при попытке пользователя получить доступ к ресурсу SharePoint.

 

STS в действии
Рисунок. STS в действии
  1. Делается неразрешенный запрос HTTP по URL ресурса SharePoint.
  2. SharePoint отвечает, показывая, что запрос не аутентифицирован, и выдает вызывающему приложению URL, по которому надо перейти для выполнения аутентификации. Этот процесс зависит от провайдеров аутентификации, которые активированы в SharePoint; например, вызов может быть перенаправлен на страницу регистрации Windows LiveID. Если доступно более одного провайдера аутентификации, тогда URL будет к странице регистрации, которая позволяет пользователю выбрать тип провайдера идентификации, с помощью которого он хочет выполнить аутентификацию.
  3. Провайдер идентификации аутентифицирует пользователя для доступа к соответствующему ресурсу, будь то AD для Windows, провайдер членства в группе и роли для аутентификации, основанной на формах, или система, основанная на SAML, такая как ADFS или Windows LiveID.
  4. Провайдер идентификации возвращает секретный ключ, который является особым для каждого метода аутентификации.
  5. Этот специфичный для провайдера аутентификации секретный ключ предоставляется SharePoint STS. STS верифицирует, что он доверяет издателю секретного ключа и превращает ключ в ключ SAML, который подходит для использования внутри SharePoint (если провайдер идентификации вернул ключ SAML, тогда STS перегенерирует этот ключ). Заметьте, что реальные атрибуты в ключе SAML зависят от провайдера идентификации. На этом шаге ключ SAML может быть расширен за счет вашего собственного провайдера заявок, и это произойдет перед тем как вы передадите его вызывающему пользователю. Это расширение полезно для того, чтобы заявки для других приложений, таких как внутренние приложения (например, CRM), были уже включены в список заявок пользователя.
  6. Ключ SAML возвращается пользователю.
  7. Запрос HTTP с присоединенным ключом SAML делается к исходному URL. Далее SharePoint использует ключ SAML для определения того, разрешено ли пользователю получить доступ к требуемому ресурсу.

SharePoint STS является веб-службой, называемой SecurityTokenServiceApplication, и устанавливается на внешних серверах, на веб-сайте Microsoft IIS, который называется SharePoint Web Services.

Настройка аутентификации, основанной на заявках

Вы задаете настройки основанной на заявках аутентификации, когда создаете веб-приложение. Заметьте, что SharePoint не позволяет вам изменять режим аутентификации (основанный на заявках или классический) в разделе Central Administration после создания приложения. Вы можете использовать Windows PowerShell для конвертирования из классического режима в основанный на заявках, но не наоборот. Просмотрите статью TechNet под названием «Migrate from classic-mode to claims-based authentication (SharePoint Server 2010)» (http://technet.microsoft.com/en-us/library/gg251985.aspx), если хотите узнать детали. Настройка основанной на заявках аутентификации — несколько более сложный процесс, чем настройка классического режима, потому что вы должны подумать и о провайдерах идентификации. Задайте параметры ключевых настроек нового веб-приложения, которые относятся к основанной на заявках аутентификации.

  1. На странице Manage Web Applications в Central Administration выберите новую задачу, пункт New в ленте меню.
  2. На следующей странице выберите кнопку Claims Based Authentication вверху страницы.
  3. В разделе Claims Authentication Types выберите провайдеров идентификации, которых намерены поддерживать (например, Windows, FBA или Trusted IP).
  4. 4. Если вы определяете более одного провайдера идентификации, раздел Sign In Page URL предложит возможность замены страницы регистрации по умолчанию.

На экранах 1, 2 и 3 показана аутентификация с заявками в действии. Экран 1 показывает, что происходит, когда пользователь пытается зарегистрироваться на сайте SharePoint, на котором задана аутентификация с заявками как Windows, так и основанной на формах аутентификации (LDAP). Домашняя страница на сайте SharePoint имеет часть Web Part, которая показывает итоговые заявки запрашивающего пользователя. Эта Web Part была написана Стивом Пешкой, как указано в статье MSDN «Claims Walkthrough: Writing Claims Providers for SharePoint 2010» (http://msdn.microsoft.com/en-us/library/ff699494.aspx).

 

Страница регистрации с выбором аутентификации Windows или Forms
Экран 1. Страница регистрации с выбором аутентификации Windows или Forms

 

Домашняя страница аутентификации с?использованием провайдера аутентификации, основанного на формах LDAP
Экран 2. Домашняя страница аутентификации с?использованием провайдера аутентификации, основанного на формах LDAP

 

Домашняя страница аутентификации с?провайдером Windows
Экран 3. Домашняя страница аутентификации с?провайдером Windows

Разница между заявками, которые показаны на экранах 2 и 3 может быть вызвана различными IP, которые были задействованы при аутентификации пользователя. Хотя и применялся один и тот же источник данных (то есть тот же пользовательский объект в AD) в обоих сценариях, аутентификация Windows возвращает другой набор атрибутов, нежели аутентификация LDAP.

Гибкость в эксплуатации и возможности

Аутентификация, основанная на заявках, дает больше гибких возможностей для развертывания, чем классический режим, открывая дополнительные возможности для интеграции со средами, основанными не на Windows. Помните, что Windows является основанным на заявках провайдером, поэтому вы можете применять ту же самую идентификацию Windows, которую вы используете при регистрации. Кроме того, вы выигрываете от новых возможностей, которые дает основанная на заявках аутентификация. Чтобы определиться, внедрять ли классическую или основанную на заявках аутентификацию, почитайте статью TechNet «Plan for claims-based authentication or classic-mode authentication (SharePoint 2010)» (http://technet.microsoft.com/en-us/library/hh706161.aspx)