Аналог группы “NT Authority/Authenticated Users” при использовании FBA в Sharepoint. Обзор способов реализации

Как вы возможно знаете в Sharepoint одно веб приложение может быть расширено (extended) на несколько аутентификационных зон. При этом можно определить максимум 5 зон для одного веб приложения:

  • Default
  • Intranet
  • Extranet
  • Internet
  • Custom

Администратор может определить тип аутентификации для каждой зоны: Windows или FBA (через Central Administration > Application Management > Authentication providers). Таким образом, внутренние пользователи интрасети смогут входить на портал, используя их учетные записи Windows, в то время как внешние пользователи, которые заходят на портал через интернет, будут использовать аутентификацию с использованием форм (FBA). При использовании Windows аутентификации у администраторов имеется удобный инструмент для управления всеми аутентифицированными пользователями – специальная группа “NT Authority/Authenticated Users”. Эта группа представляет всех пользователей, аутентифицированных в Windows, которые имеют доступ к вашей сети (см. этот пост для более подробной информации). Почему это удобно? Потому что с этой группой администраторы могут назначать права сразу всем пользователям системы, которые заходят в нее с использованием Windows аутентификации.

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

Как вы возможно знаете FBA в ASP.Net реализован с помощью membership и role провайдеров (я не придумал более менее удачного перевода для этих терминов) – наследников стандартных классов MembershipProvider и RoleProvider из сборки System.Web.dll (я не рассматриваю случаи собственной реализации FBA в данной статье). Конкретная реализация этих провайдеров зависит от физического хранилища пользовательских учетных записей (наиболее распространенные это Sql базы данных и Active Directory). При использовании стандартной базы данных aspnet_db в качестве backend хранилища аккаунтов, следующие стандартные классы доступны для использования:

  • System.Web.Security.SqlMembershipProvider
  • System.Web.Security.SqlRoleProvider

Если же используется Active Directory, то вы также можете использовать стандартные провайдеры:

  • Microsoft.Office.Server.Security.LdapMembershipProvider
  • Microsoft.Office.Server.Security.LdapRoleProvider

Но, как я упомянул выше, какие бы провайдеры вы ни использовали, в FBA нет стандартного аналога группе “NT Authority/Authenticated Users”. Есть несколько способов реализовать такую функциональность. Но все они в конечном счете сводятся к одной общей идее: есть некая специальная FBA группа (или роль) AllUsers. Администраторы используют эту группу для управления настройками безопасности в Sharepoint (т.е. назначают права на защищаемые объекты (securable objects) в Sharepoint). Но как пользователи FBA попадут в эту группу? Рассмотрим несколько способов:

  1. Если вы полностью контролируете процесс создания пользовательских учетных записей (напр. в вашем приложении одна единственная страница, на которой пользователи сами регистрируются в системе), то вы можете кастомизировать процесс регистрации путем добавления кода, который добавит новую учетную запись в группу AllUsers;
  2. Если у вас нет полного контроля над процессом создания аккаунтов (например если пользователи создаются автоматически с через BizTalk интеграцию с внешней CRM системой), вы можете реализовать Sharepoint job, который будет запускаться по расписанию и добавлять пользователей в группу AllUsers (которая должна быть предварительно создана в хранилище учетных записей). Преимущество этого подхода в том, что вы будете по-прежнему использовать стандартные провайдеры и реальную группу FBA, т.е. не требуется никаких кастомизаций. Но с другой стороны, пользователи не будут членами указанной группы сразу после создания. Должно пройти некоторое время, пока Sharepoint job не будет выполнен и не добавит новые учетные записи в группу AllUsers;
  3. Если у вас нет полного контроля над процессом создания учетных записей и предыдущий вариант с асинхронным добавлением пользователей в группу вас не устраивает, то вы можете реализовать специализированный role provider, который “сымитирует” группу AllUsers;
  4. Можно еще упомянуть способ с использованием триггеров БД. Этот метод будет работать, только если вы используете БД для хранилища данных. Идея довольно простая: вы создаете триггер на создание новых записей в таблице apnet_Users и каждый раз при добавлении новой учетной записи – вы добавляете связанную запись в таблицу aspnet_UsersInRoles, с помощью которой пользователи связываются с группами. Но из всех перечисленных методов, вариант с триггером мне нравится меньше всего. Во-первых, он не подойдет если у вас используется Active Directory, а во-вторых, мне не очень нравятся триггеры из-за сложностей с поддержкой.

В данной статье (преимущественно во второй части) я подробно рассмотрю третий способ и покажу, как реализовать кастомный role provider в случае использования БД в качестве хранилища учетных записей (стандартная БД aspnet_db). Но это не будет ограничением, если вам нужно использовать провайдеры для Active Directory, т.к. идеи представленные здесь общие для всех типов хранилищ.

Идея следующая: так как мы используем стандартную базу данных asp.net_db, то мы по-прежнему можем использовать возможности, предоставляемые стандартным провайдером SqlRoleProvider. Для того чтобы добавить нашу “виртуальную” группу FBA AllUsers нам нужно унаследовать наш кастомный провайдер от SqlRoleProvider и добавить логику в перегруженные методы. Для этого нужно из публичного интерфейса класса SqlRoleProvider выделить те методы, которые используются для работы с группами (ролями) и которые связывают пользователей и группы. Их мы и должны будем переопределить в нашем классе:

public class SqlRoleProvider : RoleProvider
{
    public override string[] FindUsersInRole(string roleName, string usernameToMatch);
    public override string[] GetAllRoles();
    public override string[] GetRolesForUser(string username);
    public override string[] GetUsersInRole(string roleName);
    public override bool IsUserInRole(string username, string roleName);
    public override bool RoleExists(string roleName);
    ...
}

Эти методы нам нужно переопределить для реализации специализированного провайдера. Если вы используете AD, то вам нужно унаследоваться от LdapRoleProvider и переопределить те же 6 методов. Про конкретную реализацию кастомного провайдера я расскажу во второй части статьи.

 

Реклама

Об авторе sadomovalex

Старший инженер, team lead, консультант. Работаю в стеке .Net. Последние несколько лет занимаюсь разработкой enterprise приложений под Sharepoint, чему и будет в основном посвящена тематика этого блога. Также активно использую и интересуюсь ASP.Net MVC, DDD, TDD, Agile. Активно участвую в жизни многих профессиональных сообществ, SPb .Net UG, SPb ALT.Net, rsdn, Finland SP UG и др.
Запись опубликована в рубрике FBA, Security, Sharepoint. Добавьте в закладки постоянную ссылку.

2 комментария на «Аналог группы “NT Authority/Authenticated Users” при использовании FBA в Sharepoint. Обзор способов реализации»

  1. Уведомление: Аналог группы “NT Authority/Authenticated Users” при использовании FBA в Sharepoint. Реализация собственного провайдера ролей | Алексей Садомов – техбл

  2. Уведомление: Реализация собственного провайдера ролей при использовании FBA в Sharepoint | Алексей Садомов – техблог

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s