Для начинающих SharePoint представляется чем-то большим и непонятным. А между тем, SharePoint – обычное ASP.NET приложение, работающее на IIS. Это, безусловно, отражается и на системе безопасности, важным элементом которой является аутентификация пользователей.

Способы аутентификации в SharePoint

Аутентификация – это процесс проверки личности пользователя. SharePoint поддерживает 3 основных способа аутентификации:

Windows – является основным и наиболее распространенным способом. Данная аутентификация работает аналогично стандартным механизмам сетевой безопасности Windows и выполняется контроллером домена. Данный тип аутентификации настраивается на уровне IIS. Различают четыре основных реализации данной аутентификации:

Анонимный доступ — позволяет пользователям иметь доступ к сайтам без предоставления имени пользователя и пароля. По умолчанию для анонимного доступа используется учетная запись IUSR_<имя_компьютера>.
Базовая HTTP аутентификация – при данном способе аутентификации сервер запрашивает у пользователя логин и пароль, которые передаются по сети в незашифрованном виде. Является простым способом получения сведений об имени пользователя и пароле, однако обеспечивает незначительную защиту от несанкционированного доступа, т.к. пароли передаются в кодировке Base-64, которую легко раскодировать. Данный метод аутентификации поддерживается большинством браузеров.
Digest HTTP аутентификация – аналогична базовой HTTP аутентификации, однако при этом пароли пересылаются по сети в зашифрованном виде. Данный способ аутентификации доступен только с Windows 2003 SP2.
Интегрированная аутентификация Windows — является одним из самых безопасных способов аутентификации. При включенной встроенной проверке подлинности обозреватель на компьютере пользователя доказывает знание пароля через криптографический обмен с веб-сервером с использованием хеширования. Встроенная безопасность доступна только в Internet Explorer. IIS, и SharePoint соответственно, поддерживает два протокола для осуществления интегрированной аутентификации:
- NTLM – протокол сетевой аутентификации, разработанный Microsoft для Windows NT. Протокол работает по принципу запрос-ответ, при этом пароль на сервер не отправляется, а отправляется хэш, созданный с использованием возвращенного сервером ключа и данных учетной записи пользователя. Далее сервер проверяет переданный хэш локально и соответственно разрешает либо нет доступ к ресурсу.
- Kerberos – предлагает механизм взаимной идентификации клиента и сервера перед установлением связи между ними. Он основан на использовании маркеров, билетов (tickets). При использовании данного протокола клиент сначала передает логин и пароль на сервер аутентификации. В ответ сервер возвращает маркер аутентификации. Далее данный маркер может быть использован при доступе к ресурсам в сети, при этом не будет необходимости пересылать данные учетной записи (имя пользователя/пароль) по сети и заново производить аутентификацию.
  
  Протокол Kerberos является более безопасным и быстрым, чем NTLM, однако требует дополнительного конфигурирования, зачастую довольно трудоемкого и требующего детального планирования.

Более подробно процесс аутентификации запросов в IIS рассмотрен здесь: http://groff.habrahabr.ru/blog/78242/

ASP.NET формы — в этом случае используются не windows полномочия пользователя, а учетные данные, введенные форму и проверенные с помощью настроенного провайдера. Данный способ реализуется с помощью функциональных возможностей ASP.NET и построен на модели провайдеров. Модель провайдеров позволяет использовать сторонние системы и хранилища данных для аутентификации и проверки полномочий пользователя. По умолчанию ASP.NET включает провайдеры для LDAP и SQL. В случае необходимости могут быть разработаны кастомные провайдеры.

Служба единого входа (Single Sign-On) – служба, которая позволяет пользователям переходить из одной системы в другую без повторной аутентификации. Это избавляет пользователя от многократного ввода данных своей учетной записи при данном переходе. Часто системы или программные продукты содержат свой механизм проверки учетных данных пользователей. Роль SSO заключается в преобразовании полномочий пользователя в одной системе к полномочиям в другой.

Многие компании используют специализированные системы для хранения и проверки учетных данных пользователей, отличные от Microsoft SSO. В случае если подобные системы планируется использовать в связке с SharePoint, и при этом необходимо отказаться от хранения учетных данных сразу в двух местах, существует возможность создать кастомный SSO провайдер. SSO доступно только в Microsoft Office SharePoint Server 2007 и недоступно в WSS 3.0

Какой способ аутентификации выбрать?

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

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

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

'Double-hop' проблема

Также Kerberos аутентификация используется для решения ‘double-hop’ проблемы. Суть проблемы заключается в необходимости доступа к какому-то сетевому ресурсу или серверу из кода с использованием учетных данных пользователя, вызвавшего код.

Рассмотрим пример. Мы пишем веб часть, которая отображает данные из сторонней базы данных, например Oracle. Причем, должны быть отображены только данные, которые доступны пользователю, открывшему страницу с нашей веб частью, согласно его правам доступа. Т.е. при доступе к базе данных должна использоваться учетная запись windows пользователя, открывшего веб часть.

Сразу напрашивается использование имперсонации ASP.NET. Это логично, но работать будет только в том случае, если база данных Oracle будет находиться на том же компьютере, на котором установлен и настроен веб сервер с нашей веб частью. Причиной этому является протокол NTLM, который не позволяет передавать учетные данные имперсонированного пользователя через сеть. Одним из способов решения данной проблемы является использование Kerberos аутентификации в домене и настройки делегирования между сервером базы данных и веб сервером.

Вторым решением данной проблемой является использование Win32 API для имперсонации пользователя перед обращением к серверу базы данных. Такой подход реализуется с помощью Single Sign-On.

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

Базовая HTTP аутентификация практически не используется по причине невысокого уровня безопасности.

Где и как настроить аутентификацию?

Все настройки аутентификации SharePoint применяются на уровне веб приложений. Поэтому отправной точкой для настройки аутентификации является центр администрирования SharePoint фермы, а конкретнее страница Управление приложениями > Поставщики проверки подлинности.

Настройки аутентификации могут быть применены вручную, путем редактирования web.config файла и задания параметров в консоли администрирования IIS. Однако рекомендуется использовать именно интерфейс центра администрирования, потому что при данном способе заданные через интерфейс настройки автоматически применятся на все веб сервера фермы.

Между тем бывают случаи, когда без ручного конфигурирования не обойтись. В частности, если необходимо использовать digest HTTP аутентификацию, потребуется настраивать каждый IIS сервер фермы. Также ручная настройка понадобится в случае использования аутентификации с помощью форм — придется подключить необходимые провайдеры во все web.config файлы фермы.

Зоны веб приложений

Зоны используются для поддержания нескольких способов аутентификации веб приложения. Это может быть полезно, например, в случае если доступ к сайту помимо служащих компании (Windows аутентификация), должны иметь доступ и клиенты (аутентификация с помощью форм). В таком случае для одних используется зона, созданная по умолчанию, и для неё настраивается интегрированная windows аутентификация, а для клиентов создается новая зона на базе существующей и для неё конфигурируется аутентификация с помощью форм.

SharePoint позволяет для одного веб приложения использовать следующие зоны:

Зона по умолчанию
Зона интрасети
Зона Интернет
Пользовательская зона
Зона экстрасети

Настройки аутентификации для всех зон по умолчанию одинаковы (NTLM с отключенным анонимным доступом). Поэтому, всю необходимую настройку необходимо сделать вручную.

Ссылки по теме

Описание NTLM авторизации
NTLM в Firefox
Описание 'Double-hop' проблемы
Описание роли Kerberos в SharePoint
Настройка Kerberos для SharePoint
Конфигурирование SSO для SharePoint
Конфигурирование аутентификации с помощью форм для SharePoint

Безопасность SharePoint — Часть 2. Аутентификация пользователей