Модель безопасности в MODX

Модель безопасности в MODX не самая очевидная. Хотя в MODX присутствуют примитивы, присущие, например, модели безопасности SQL, их предназначение в MODX несколько отличается.

При настройке безопасности конечной целью является дать каждому пользователю соответвующий набор привилегий – разрешить ему совершать определенные действия в системе. Действия могут совершаться над различными объектами: страницами (resource), контекстами (context), чанками (chunk), переменными шаблонов (TV) и т.д. Сами действия могут быть очень разными, в простейшем случае это создание, просмотр, редактирование и удаление. Таким образом, задача настройки безопасности сводится к заданию отношений между пользователями, объектами и привилегиями.




Группы пользователей

Предположим, мы хотим дать пользователю partner доступ к странице «Проекты» на редактирование. В этом примере объектом является страница «Проекты», привилегией – редактирование, а пользователем – partner. Но для того, чтобы реализовать такую схему безопасности, потребуется создать группу пользователей. Дело в том, что в MODX права назначаются именно группе, а не пользователю. Группа – это множество пользователей, обладающих схожими правами. Разумеется, пользователь может состоять в нескольких группах.

Группы страниц

Дать доступ непосредственно к странице «Проекты» тоже не удастся, т.к. система безопасности MODX оперирует только с группами страниц (resource groups), а не с отдельными страницами. Если точнее, то управлять доступом можно на уровне следующих объектов:

• контексты,
• группы страниц,
• категории элементов,
• медиа источники (media source).

Политики доступа

Не будет большой неожиданностью, что и привилегии в MODX объединяются в группы. Группы привилегий называются политиками доступа (access policy). Например, политика доступа может состоять из таких привилегий:

• создание страниц
• чтение страниц
• редактирование страниц
• удаления страниц.

Чтобы дать доступ на редактирование, потребуется создать политику доступа с привилегией «редактирование страниц». Конечно, чтобы пользователь смог редактировать страницу, ему понадобится и привилегия «чтение страниц».

Учитывая всё вышесказанное, алгоритм настройки доступа в MODX можно представить так:

1. выделить объекты, доступ к которым необходимо предоставить;
2. если доступом к данным объектам нельзя управлять напрямую (например, это страница или чанк), создать группу страниц или категорию элементов и добавить туда интересующий объект;
3. создать пользователя;
4. создать группу, которая будет носителем прав доступа к интересующим объектам, и добавить пользователя в эту группу;
5. создать политику доступа с набором привилегий, которые необходимо предоставить;
6. присвоить политику доступа группе пользователей.

Шаблоны политик доступа

В MODX порядка 200 разных привилегий. Некоторые привилегии логически связаны, например, привилегии регулирующие доступ к страницам или привилегии, регулирующие доступ к чанкам. Для того, чтобы ориентироваться в таком количестве привилегий было проще, в MODX существуют шаблоны политик доступа. Шаблон состоит из набора привилегий, с которыми часто приходится работать вместе, например, если нужно дать доступ на просмотр страницы, велика вероятность, что понадобятся и привилегии на редактирование и создание.

При создании политики доступа в MODX требуется указать шаблон политики доступа. Шаблон отличается от политики доступа тем, что шаблон только группирует привилегии, чтобы с ними было удобно работать в панели администрирования. Шаблон не даёт никаких привилегий, он лишь ограничивает количество привилегий, которые можно назначить политике. Сделано это для удобства: чтобы приходилось искать нужные привилегии не в списке из сотен пунктов, а в списке из пары десятков. Теоретически можно создать шаблон со всеми возможными привилегиями и пользоваться им, но на практике это не очень удобно.

Стоит отметить, что каждая привилегия применима к определённому виду объектов. Например, привилегия на просмотр страниц не может быть использована для предоставления доступа на просмотр контекста, для этого есть отдельная привилегия. Шаблон объединяет привилегии относящиеся к одному типу объектов и, как следствие, определяет, к каким объектам будет применима политика доступа.

Роли

До сих пор мы не касались понятия роли, однако, на практике при попытке настроить права доступа, вы обязательно столкнётесь с ролями. В простых конфигурациях безопасности можно игнорировать роли и везде указывать одну и ту же роль (например, «Super User»), но разобраться в принципе работе ролей всё же стоит. Роли позволяют ограничивать привилегии пользователя внутри группы. Образно говоря, роли позволяют создать внутри группы пользователей «уровни доверия».

Каждая роль имеет ранг: чем меньше числовое значение ранга, тем больше доверия соответствует этой роли. По сути, роль и ранг – почти одно и то же, роль – это ранг, которому присвоено некоторое имя, например «Super User». Когда пользователь добавляется в группу, ему назначается определённая роль. Если ранг роли равен нулю, пользователю оказывается максимально возможное для этой группы доверие, он получает доступ ко всем привилегиям группы.

У каждой политики доступа, назначенной группе пользователей, задаётся минимальная роль, которой должен обладать пользователь, чтобы получить привилегии из этой политики. Здесь есть небольшая путаница: под минимальной ролью имеется в виду, что роль пользователя должна иметь ранг не выше указанного, чтобы он имел доступ к привилегиям из данной политики.

Предположим, есть два пользователя partner и bestpartner с почти идентичным набором привилегий, но bestpartner помимо всех привилегий partner, может ещё редактировать страницу «О компании». Можно просто скопировать настройки доступа partner и присвоить копию пользователю bestpartner, добавив туда недостающую привилегию:

1. создать группу bestpartner-group;
2. назначить новой группе те же самые политики доступа, что были у группы partner-group;
3. создать новую политику с недостающими привилегиями и назначить её группе bestpartner-group.

Используя роли, можно решить эту задачу так:

1. назначить partner роль Member в группе пользователей partner-group;
2. назначить bestpartner роль Super User в группе пользователей partner-group;
3. для политик доступа, которые нужно назначить обоим партнёрам, установить минимальную роль Member;
4. для политики доступа, специфичной для bestpartner, установить роль Super User.

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