Основанная на требованиях аутентификация является гибкой структурой, базирующейся на маркерах Security Assertion Markup Language (SAML) и построенной на основе Windows Identity Foundation (WIF). Маркеры содержат подтверждения идентичности пользователя, которые генерируются доверенными провайдерами аутентификации, включающими Windows Authentication, например в режиме Classic Mode Authentication, а также основанную на формах аутентификацию FBA и стандартные маркеры SAML, выданные такими доверенными центрами, как Windows Live ID или Active Directory Federated Services 2.0 (ADFS 2.0). Расширяя области влияния доверенных провайдеров аутентификации, основанная на требованиях аутентификация дает возможность выполнять аутентификацию во всех основанных на Windows и других системах. Такая аутентификация становится чрезвычайно эффективной, когда маркеры содержат другие пользовательские атрибуты, такие как демографическая информация или данные об организации. Эти атрибуты могут создаваться в организации пользователя, других организациях или в Интернете.

Если вы незнакомы с основанной на требованиях аутентификацией, то приведенное здесь описание может показаться вам сложным. Но на самом деле базирующаяся на требованиях аутентификация есть стандартизованная, расширяемая реализация концепций, с которыми вы уже сталкивались, если занимаетесь поддержкой Active Directory. В этой статье речь пойдет о реализации основанной на требованиях аутентификации в Microsoft SharePoint 2010, но ее концептуальная база поможет вам и в освоении других основанных на требованиях средств аутентификации, включая Active Directory Federated Services (ADFS) 2.0.

Обзор аутентификации Windows

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

Когда вам требуется доступ к системе, например к файловому серверу, система должна установить, кто вы, прежде чем предоставить доступ к ресурсам. Было бы нелегко управлять списком имен пользователей и паролей на каждой системе. Для решения проблемы вы создаете домен Windows, развертывая Active Directory Domain Services (AD DS). Внутри домена все системы доверяют механизму аутентификации домена — службам Kerberos, работающих на контроллерах домена, — для того, чтобы проверить идентичность пользователя. Поэтому, когда вы получаете доступ к файловому серверу, ему не нужно аутентифицировать вас. Вместо этого вы даете серверу билет службы Kerberos, который позволяет осуществить идентификацию. Билет был создан с использованием процессов, включающих шифрование, при котором используются ключи, известные лишь серверу и домену. Сервер знает, что билет действителен, и использует его, чтобы выяснить, кто вы. Сервер принимает утверждение билета, идентифицирующее вас, поскольку доверяет источнику билета — Kerberos Key Distribution Center (KDC) домена AD DS. Поскольку сервер доверяет внешнему провайдеру аутентификации, ему не нужно проводить ее самому.

Билет службы Kerberos также содержит список групп безопасности домена, в которых вы состоите. И опять, поскольку источником билета является доверенный издатель, сервер использует этот список групп. Сервер строит маркер, который содержит ваш идентификатор — SID учетной записи, а также SID различных групп, к которым вы принадлежите. Локальная подсистема безопасности использует маркер для того, чтобы определить, есть ли у вас доступ к файлу. Это делается через сравнение различных SID в списке ACL файла с идентификаторами SID в вашем маркере. Этот маркер безопасности представляет вас локальному серверу.

В прошлом, когда разработчик хотел создать надежный веб-сайт, он строил компонент аутентификации. В SharePoint, в режиме Classic Mode Authentication, ваш маркер системы безопасности Windows трансформируется в объект, который представляет вас внутри SharePoint. Этот объект называется объектом SPUser. Объект SPUser в веб-приложении SharePoint является концептуальным эквивалентом вашего маркера безопасности системы Windows. Объект представляет вас во время соединения с веб-приложениями.

Аутентификация с помощью требований

Требование — это набор утверждений (то есть информации о пользователе). На основном концептуальном уровне билет службы Kerberos является требованием, которое, среди прочего, утверждает идентичность пользователя и членство в группах. Когда вы получаете доступ к веб-приложению SharePoint, которое использует основанную на требованиях аутентификацию, оно принимает требование и транслирует его в объект SPUser, который представляет вас при соединении с веб-приложениями.

Это первое различие между Classic Mode Authentication и аутентификацией, основанной на требовании. В Classic Mode Authentication веб-приложение полагается на Microsoft IIS, для того чтобы передать ваш маркер безопасности Windows веб-приложению. В аутентификации, основанной на требованиях, веб-приложение полагается на службу Security Token Service (STS) в ферме для передачи маркера с требованием, включая требование о вашей идентичности. STS является обязательным служебным приложением, которое формируется автоматически, когда вы создаете ферму. Это приложение нельзя удалять. Его задача — создавать маркеры требований.

В Classic Mode Authentication IIS при выполнении аутентификации полагается на AD. IIS может получать билеты несколькими способами (например, NTLM, Kerberos, Basic, Digest). В случае аутентификации NTLM, Basic и Digest IIS проверяет учетные записи в AD. В случае аутентификации Kerberos билет службы содержит учетные данные, которые уже проверены.

В основанной на требованиях аутентификации, как показано на рисунке, STS на самом деле не выполняет аутентификацию. Он полагает, что доверенный провайдер сделал это в графическом интерфейсе пользователя. Данный провайдер называется провайдером аутентификации. Провайдер аутентификации может быть Windows (AD) или одним из других провайдеров. Если основанная на требованиях аутентификация использует провайдера аутентификации Windows, STS, по существу, выполняет те же функции, которые берет на себя IIS в Classic Mode Authentication. Если доступен Kerberos, билет службы обрабатывается и превращается в набор требований, говорящих об идентичности пользователя и членстве в группах. Если применяется аутентификация NTLM, Basic или Digest, пользовательские учетные записи проверяются в AD, а маркер NT переводится в набор требований, говорящих об идентичности пользователя и членстве в группах. Итоговые требования передаются веб-приложению в виде маркера, который транслируется в объект SPUser внутри веб-приложения.

 

Рисунок. Основанная на требованиях аутентификация против Classic Mode Authentication

 

К этому моменту вы должны уяснить, что есть компонент под названием STS, который выполняет задачу построения маркеров, содержащих требования. Роль STS в создании маркеров для SharePoint концептуально является эквивалентом роли KDC в выдаче билетов Kerberos на Windows DC. Кроме того, если вы используете только аутентификацию Windows, надо иметь в виду, что существует небольшая разница между Classic Mode Authentication и аутентификацией, основанной на требованиях.

А что если вы хотите, чтобы веб-приложение было доступно партнерам, но не собираетесь добавлять их учетные записи в свой домен AD DS? До того как был реализован провайдер аутентификации. NET, веб-разработчик должен был написать компонент для аутентификации пользователей и администрирования идентификаторов пользователей. Теперь вы можете задействовать провайдер FBA, чтобы аутентифицировать пользователей, а не учетные данные, хранящиеся в AD DS, в Active Directory Lightweight Directory Services (AD LDS), в базе данных, такой как база данных Microsoft SQL Server, или в хранилище данных LDAP, таких как Novell eDirectory, Novell Directory Services (NDS) или Sun ONE. Либо можно применять SAML для аутентификации пользователей с помощью учетных данных, которые хранятся в маркере, поставляемом ADFS 2.0, Windows Live ID или надежным доверенным центром аутентификации.

Аутентификация, основанная на требованиях, позволяет расширять веб-приложение SharePoint на разные множества пользователей, домены, леса и среды, отличные от Windows. Вы можете менять провайдера аутентификации или методы аутентификации без изменения самого веб-приложения, пока оно принимает и понимает требования.

Доверие

Как строятся требования? Когда вы пытаетесь получить доступ к веб-приложению, которое использует основанную на требованиях аутентификацию, вы незаметно перенаправляетесь на страницу регистрации STS, где аутентифицируетесь. В некоторых случаях, таких как аутентификация Windows, вы можете никогда не увидеть эту транзакцию, если задаете настройки безопасности браузера так, чтобы он незаметно аутентифицировал вас на надежных сайтах, и в том случае, если веб-сайт находится в доверенной зоне. В других случаях, например в FBA, вы увидите реальную страницу, на которой нужно ввести имя пользователя и пароль. STS аутентифицирует вас и дает маркер вашему браузеру. Затем браузер возвращается к исходному веб-сайту, пересылает маркер, а после этого веб-приложение узнает, кто вы.

Этот процесс использует серию стандартов, называемых стандартами WS-*, которые гарантируют, что маркер может быть использован веб-приложением. Веб-приложение настроено так, чтобы доверять STS. Доверие подразумевает обмен сертификатами, которые используются для шифрования маркера. Если веб-приложение может дешифровать маркер, оно «знает», что маркер сгенерирован доверенным STS.

Доверие — это сердце любой системы безопасности. В домене AD DS каждый компонент Windows доверяет локальной подсистеме безопасности, которая доверяет домену, а тот, в свою очередь, доверяет другим доменам в лесу, а это доверие может быть впоследствии распространено на другие домены или леса. В SharePoint все веб-приложения и службы в ферме доверяют Security Token Service (STS) данной фермы.

Требования

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

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

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

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

Также можно назначить разрешения на контент, основываясь на требованиях. Например, вы можете определить, что пользователи должны иметь должность вице-президента или выше для того, чтобы получить доступ к контенту. Кроме того, вы можете применять требования для поиска пользователей. Например, вы хотите назначить пользователю задачу, но можете вспомнить только менеджера пользователя. Элемент управления может сделать видимым атрибут менеджера пользователей, которые принадлежат сайту. Разработчикам особенно понравятся возможности, которые реализованы в требованиях SharePoint 2010.

Федерация

Давайте представим, что доступ к определенному контенту в веб-приложении могут получить только пользователи, которые являются сотрудниками вашей компании — Contoso или компании партнера — Litware. Дублировать копии всех учетных записей пользователей Litware в ваш домен AD DS или в отдельную базу данных и потом обеспечивать синхронизацию изменений нежелательно. Проще положиться на администраторов в Litware, чтобы обслуживать их пользовательские учетные записи и доверять аутентификации, производимой Litware.

При помощи доменов Windows можно задавать доверительные отношения: домен Contoso доверяет домену Litware. Однако сетевые экраны могут помешать правильной установке и поддержанию отношений доверия, а во многих организациях есть политики, которые запрещают Windows доверять внешним организациям.

Аутентификация, основанная на требованиях, поддерживает федерацию (обеспечиваемую такими решениями, как ADFS от Microsoft или Ping-Federate от Ping Identity), которая расширяет концепцию доверия и требований на независимые компании. Например, вам нужно настроить ADFS 2.0, для того чтобы ADFS 2.0 аутентифицировал пользователей обоих доменов, без необходимости установки отношений доверия. Вы задаете настройки STS в SharePoint, чтобы он доверял STS, представленному ADFS 2.0. Таким образом, STS в SharePoint становится доверяющим партнером STS (RP STS), а STS в ADFS 2.0 — идентифицирующим партнером STS (IP STS).

Когда пользователь предпринимает попытку получить доступ к веб-сайту, сайт перенаправляет его к IP STS для аутентификации. Маркер SAML, выпущенный IP STS (ADFS 2.0 в этом примере), представляет RP STS (STS в SharePoint), который может усилить маркер дополнительными требованиями до того, как пользователю выдается маркер, направляемый веб-приложению.

Другой пример федеративной идентичности — это аутентификация Windows Live ID. Вы можете задать настройки STS в SharePoint, чтобы она доверяла маркерам, которые выданы Windows Live ID.

Маркеры SAML

Маркеры SAML могут включать любое количество требований о пользователе, таких как имя пользователя, группы, к которым он принадлежит, и другие атрибуты. Приложение доверяющей стороны получает маркер SAML и использует требования внутри, для того чтобы решить, предоставлять ли пользователю доступ к нужному ресурсу. Следовательно, одно из требований в маркере должно однозначно идентифицировать пользователя. Оно называется требованием идентичности. IP-STS не нужно создавать требование идентичности с именем пользователя, когда тот регистрируется у IP-STS. Например, у AD FS нет необходимости в создании требования идентичности с именем пользователя домена. Вместо этого IP-STS может создавать требование идентичности, используя другой уникальный идентификатор. Во многих случаях реализации требований используется атрибут почтового адреса в качестве требования идентичности. RP-STS должны знать, какому требованию необходима уникальность для маркеров, созданных IP-STS.

По этой причине настройка среды требований, использующей аутентификацию на маркерах SAML, требует сотрудничества между администраторами RP-STS и IP-STS. Ими должны быть согласованы следующие элементы.

  • В продуктах SharePoint 2010 каждое веб-приложение, которое имеет настройки для использования провайдера SAML, добавляется на сервер IP-STS в виде отдельной записи RP-STS. Эту задачу выполняет владелец RP-STS. Каждое веб-приложение идентифицируется как область, которая является просто пространством имен, ассоциирующихся с веб-приложением доверяющей стороны (например, https://portal.contoso.com).
  • Только владелец IP-STS знает, какое значение в маркере будет уникальным для каждого пользователя, поэтому на данный маркер можно полагаться как на требование идентичности. Эта информация должна быть предоставлена владельцу IP-STS.
  • Маркеры подписаны с использованием сертификатов, сгенерированных IP-STS. Этот сертификат должен быть передан от IP-STS к RP-STS.

Развертывание аутентификации, основанной на маркере SAML, с продуктами SharePoint 2010 состоит из следующих шагов.

  1. Экспортируйте сертификат, подписывающий маркер, из IP-STS. Этот сертификат известен как ImportTrustCertificate.
  2. Скопируйте сертификат на сервер в ферме SharePoint Server 2010. Оставшиеся шаги выполняются на этом же сервере.
  3. Определите требование, которое будет использовано как уникальный идентификатор пользователя. Определение уникального идентификатора пользователя является частью процесса сопоставления требований. Для выполнения сопоставления используется PowerShell.
  4. Определите дополнительные сопоставления требований (например, другие значения в маркере, который будет использовать RP-STS). Многие маркеры включают параметр, определяющий роли пользователя, которые могут применяться для получения разрешения в ферме SharePoint 2010. Требования из исходящего маркера, у которых нет сопоставления, будут отбракованы.
  5. Создайте новый провайдер аутентификации, используя PowerShell. Данный процесс создает SPTrustedIdentityTokenIssuer. Во время этого процесса вы пересылаете ImportTrustCertificate, сопоставление требований и дополнительные сопоставления требований. Также необходимо создать и определить область — пространство имен URL, которое ассоциируется с первыми веб-приложениями SharePoint, настройки которых вы задаете для аутентификации, основанной на маркере SAML.
  6. После создания SPTrustedIdentity­TokenIssuer вы можете создать и добавить больше областей для других веб-приложений SharePoint, как будто вы настраиваете несколько веб-приложений, чтобы они использовали тот же самый SPTrusted­Identity­Token­Issuer. Для каждой области, которую вы добавляете в SPTrusted-Identity­Token­Issuer, необходимо создать запись RP-STS на IP-STS.
  7. Создайте новое приложение SharePoint и задайте настройки так, чтобы оно использовало вновь созданного провайдера аутентификации. Провайдер аутентификации появится как вариант в Central Administration, когда вы будете выбирать режим требований для веб-приложения.

Вы можете настроить множество провайдеров аутентификации, использующих маркер SAML. Однако можно использовать подписывающий маркер сертификат в ферме только один раз. Все настроенные провайдеры появятся как варианты в Central Administration. Требования из различных доверенных сред STS не будут конфликтовать.

Если вы реализуете основанную на маркере SAML аутентификацию с компанией-партнером, а ваша среда включает в себя IP-STS, я рекомендую вам работать с администратором внутренней среды требований для установления доверительных взаимоотношений между внутренним IP-STS и STS партнера. Результат выглядит как цепочка доверия и аутентификации, где ваши приложения SharePoint доверяют IP-STS партнера. Таким образом обеспечивается гарантия того, что аутентификация (то есть поддержание идентичности пользователей) управляется каждой организацией по отдельности. Этот подход не требует добавления другого провайдера аутентификации к вашей ферме SharePoint Server 2010. Кроме того, он позволяет администраторам управлять всей средой требований.

Замечу, что если вы используете основанную на маркере SAML аутентификацию с AD FS на ферме SharePoint Server 2010, которая имеет множественные серверы в варианте с балансировкой нагрузки, она может влиять на производительность и функциональность клиентских представлений веб-страницы. Когда AD FS дает маркер аутентификации клиенту, этот маркер передается SharePoint Server 2010 для каждого элемента страницы, защищенного разрешениями. Если механизм балансировки нагрузки не использует режим Affinity, каждый защищенный элемент аутентифицируется несколькими серверами SharePoint, и это может привести к отклонению маркера. После отклонения маркера SharePoint перенаправляет клиента на повторную аутентификацию к серверу AD FS. Затем сервер AD FS может отклонить множественные запросы, которые делаются за короткий промежуток времени. Такое поведение должно предотвращать атаку типа DoS. Если страдает производительность или страницы не загружаются полностью, задайте для балансировщика нагрузки принадлежность к единственной группе. Это изолирует запросы на маркеры SAML на одном веб-сервере. Более детально эти процедуры рассматриваются в SharePoint 2010 Technical Library (technet.microsoft.com/en-us/library/ee806886.aspx).

Аутентификация, основанная на требованиях, позволяет расширять как аутентификацию, так и коллекцию информационных атрибутов о пользователе для других приложений и доменов. Многие ИТ-специалисты впервые будут работать с требованиями в SharePoint 2010, другие в AD FS 2.0, некоторые — в Azure, но, без сомнения, в ближайшие годы роль аутентификации с требованиями в области управления идентичностью будет расти.

Дэн Холм (danh@intelliem.com) — директор консалтинговой службы Intelliem, которая организовывает консультации для предприятий, внедряющих SharePoint, Office, Windows и Active Directory