Как использовать продвинутые концепты СКД

Целью этой статьи является дать вам более глубокое понимание системы СКД, а также объяснить некоторые решения, стоящие за ней.

Концепты дизайна

Возможности безопасности экземпляра объекта Symfony основываются на концепте Списка Контроля Доступа. Каждый экземпляр объекта домена имеет свой собственный СКД. Экземпляр СКД содержит детальный список Записей Контроля Доступа (ЗКД), которые используются для принятия решений доступа. Система СКД Symfony фокусируется на двух главных задачах:

  • предоставление доступа эффективного извлечения большого количества СКД/ЗКД для ваших объектов домена и их модифицирование;
  • предоставление способа с лёгкостью принимать решения о том, позволено ли пользователю выполнять действие с объектом домена или нет.

Как обозначено в первом пункте, одна из основных возможностей системы СКД Symfony - высокопроизводительный способ извлечения СКД/ЗКД. Это крайне важно, так как каждый СКД может иметь несколько ЗКД, и древовидно наследовать из другого СКД. Поэтому, не используется ORM, а вместо этого реализация взаимодействует с вашим соединением напрямую, используя Doctrine DBAL.

Идентичности объекта

Система СКД полностью отделена от ваших объектов домена. Они даже не должны храниться в одной БД или на одном сервере. Чтобы достичь этого разделения, в системе СКД ваши объекты представлены через объекты идентичности объекта. Каждый раз, когда вы хотите извлечь СКД для объекта домена, система СКД вначале создаст идентичность объекта из вашего объекта домена, а потом передаст её в поставщика СКД для дальнешней обработки.

Идентичности безопасности

Это анало идентичности объекта, но представляющий пользователя или роль в вашем приложении. Каждая роль или пользователь имеют собственную идентичность безопасности.

Caution

Для пользователей, идентичность безопасности основывается на имени пользователя. Это означает, что если по какой-либо причине имя пользователя изменилось, вы должны убедиться, что идентичность безопасности пользователя тоже обновлена. Метод MutableAclProvider::updateUserSecurityIdentity() существует для обработки обновления.

Структура таблицы БД

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

  • acl_security_identities: Эта таблица записывает все идентичности безопасности (ИДБ, SID), которые содержат ЗКД. Реализация по умолчанию поставляется с двумя идентичностями: RoleSecurityIdentity и UserSecurityIdentity.
  • acl_classes: Эта таблица связывает имена классов с уникальным ID, на который можно сослаться из других таблиц.
  • acl_object_identities: Каждая строка в этой таблице представляет один экземпляр объекта домена.
  • acl_object_identity_ancestors: Эта таблицапозволяет эффективным способом определить всех предшественников СКД.
  • acl_entries: Эта таблица содержит все ЗКД. Обычно эта таблица имеет наибольшее количество строк. Она может содержать десятки миллионов строк, незначительно влияя на производительность.

Область действия записей контроля доступа

Записи контроля доступа могут иметь разные области действия применения. В Symfony, их по сути существует две:

  • Область действия класса: Эти записи применяются ко всем объектам одного класса.
  • Область действия объекта: Использовалась на протяжении всей предыдущей статьи и применяется только к одному конкретному объекту.

Иногда вам может понадобиться применить ЗКД только к конкретному полю объекта. Представьте, что вы хотите, чтобы ID можно было просмотреть только администратору, но не службе работы с пользователями. Чтобы решить эту распространённую проблему, были добавлены две под-области действия:

  • Область действия поля класса: Эти записи применяются ко всем объектам одного класса, но только к определённому полю объектов.
  • Облась действия поля объектя: Эти записи применяются к конкретному объекту и только к определённому полю этого объекта.

Решения предварительной авторизации

Для решений предварительной авторизации (то есть решений, принятых до того, как вызвается любой безопасный метод или действие), используется испытанный сервис AccessDecisionManager. AccessDecisionManager также используется для достижения решений авторизации, основанных на ролях. Так же, как и роли, система СКД добавляет несколько новых атрибутов, которые могут быть использованы для проверки разных разрешений.

Встроенная карта разрешений

Атрибут Предназначенное значение Целочисленная битовая маска
VIEW Разрешено ли кому-то просматривать объект домена. VIEW, EDIT, OPERATOR, MASTER, или OWNER
EDIT Разрешено ли кому-то делать изменения в объекте домена. EDIT, OPERATOR, MASTER, или OWNER
CREATE Разрешено ли кому-то воздавать объект домена. CREATE, OPERATOR, MASTER, или OWNER
DELETE Разрешено ли кому-то удалять объект домена. DELETE, OPERATOR, MASTER, или OWNER
UNDELETE Разрешено ли кому-то восстанавливать ранее удалённый объект домена. UNDELETE, OPERATOR, MASTER, или OWNER
OPERATOR Разрешено ли кому-то выполнять все действия, описанные выше. OPERATOR, MASTER, или OWNER
MASTER Разрешено ли кому-то выполнять все действия, описанные выше, и ещё предоставлять их другим. MASTER или OWNER
OWNER Владеет ли кто-то объектом домена. Владелец может выполнять все действия, описанные выше, и предоставлять разрешения владения. OWNER

Атрибуты разрешений проти битовых масок атрибутов

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

Расширяемость

Приведенная выше карта разрешений ни в коем случае не является статичной, и в теории может быть при желании полностью заменена.Однако, она должна покрыть большинство проблем, с которыми вы столкнётесь, а что касается возможности взаимодействия с другими пакетами, придерживайтесь значений, которые предусмотрены для них.

Решения пост-авторизации

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

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

Процесс принятия решений авторизации

Класс СКД предоставляет два метода для определения того, имеет ли идентичность безопасности требуемые битовые маски isGranted() и isFieldGranted(). Когда СКД получает запрос авторизации через один из этих методов, он делегирует этот запрос реализации PermissionGrantingStrategy. Это позволяет вам заменять способ достижения решений доступа, не изменяя сам класс СКД.

Вначале PermissionGrantingStrategy проверяет все ваши ЗКД с объектой областью действия. Если применимых не будет найдено, будут проверены ЗКД с классовой областью действия. Если применимых не будет найдено, то процесс будет повторен с ЗКД родительского СКД. Если родительского СКД не существует, будет вызвано исключение.

Эта документация является переводом официальной документации Symfony и предоставляется по свободной лицензии CC BY-SA 3.0.