Модель безопасности веб-приложения?

Question

[divanikus]

В очередной раз захотелось сочинить что-нибудь эдакое, чтобы с одной стороны было гибко, а с другой относительно просто и не громоздко. Долго смотрел на механизмы ACL и им подобные, придумалось вот чего:

сделать для каждого объекта сайта наследуемые дискрипторы безопасности. Ну т.е. сам дискриптор это всего лишь набор «пользователь/группа -> привелегии». Вся загвоздка в наследовании и эффективном хранении и применении.


Ну т.е. вот возьмем пример, форум: у нас есть разделы, есть темы и есть посты. Стоит заметить, что это 3 разные сущности и напрямую наследовать привелегии над форумом на пост нельзя: понятно, что если у меня есть право редактировать форум, то у меня есть право редактировать пост, но наоборот неверно в общем случае. Тогда возникает вопрос — от чего наследовать права на еще не созданные сущности разных видов?


Плюсы тут я полагаю очевидны, ведь всякие фишки вроде премодерации (снимаем флаг чтение для юзеров) или куратор темы (добавляем конкретного пользователя с повышенными привелегиями для конкретной темы) вообще не требуют допилов, а просто возможны by design.


Минусы собственно в механизме наследования и эффективного применения дескрипторов: от кого наследовать вновь создаваемые сущности? С точки зрения эффективности — как делать выборки на основе дескрипторов, ну чтобы не вытаскивать лишние данные из базы с последующей дообработкой движком.


Реализацию планирую на Kohana3.


Кто-нибудь видел реализации подобных вещей? Под сабж или просто отдельно. Если есть сравнимая по гибкости альтернатива — подскажите пожалуйста куда копать?

Comments

[divanikus]

Короче, ближайшая аналогия, это права доступа на fs в винде или линухе. Но там более однородные объекты…

Answer 1

[werdender]

Как-то все запутано, но надеюсь я правильно уловил смысл.
Если говорить в контексте KO3, то имхо, ее модуль Auth вполне расширяется в описанную сторону.
Там пользователю назначаются роли. Тогда группе пользователей с ролью login можно назначить определенные права в каждой модели.

Comments

[divanikus]

Ну это понятно что оно там есть, но что касается наследования и т.п. — нету, пишите сами.
Кстати, контроль доступа по идее же надо в контроллере проверять, а не в модели, ведь так?

[werdender]

Ну да, логика же в контроллере вся.
Можно в before() базового контроллера назначать права роли для $this->request->controller() или action().

Answer 2

[ProtoPlex]

Обычно ж вроже так:

Группы юзеров — для них базовые настройки безопасности
Юзеры — индивидуальные настройки, делегируемые с групп, юзер может состоять в нескольких группах

Дерево действий — иерархическая хрень, от корня к веткам свои галочки в безопасности. Новая ветка — наследование от корня и т.д.

Сделать быстро можно используя рекурсию и кеширование.

Comments

[divanikus]

Ну в качестве набора привелегий так обычно и есть. Но так обычно глобально на все приложение разрешения ставят.
Вот если посмотрим в современных ОС: есть пользователи и группы, пользователи состоят в группах. У пользователей и групп есть наборы привелегий, ну по типу комп там выключить или т.п. Т.е. вот эта часть обычно и реализуется.

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

Answer 3

[Вадим]

Можно попробовать акл вешать на роуты, имхо. У меня АКЛ, не на уровне записи, а на уровне доступа к роуту+екшн, и привязка идет к набору групп в которых состоит пользователь. Есть 3 дефолтовых группы, Админы, Авторизированые пользователи, Анонимные пользователи. Потом есть ф-я которая получает на вход роут, и список групп, и выдает есть доступ или нет. В общем вешать права на группу и только, т.к. если вешать и на группу и персонально на пользователя, много геморроя. И такой функционал, где нужно персонально пользователю надо что-то уникальное запретить, встречается крайне редко. А если и появится, сделать для него группу, и занести его туда.

Comments

[Иван]

В Kohana v3.3, кстати, для этого очень даже фильтры (filters()) подойдут. И не придется влезать в системные классы.

[Вадим]

Ну у меня Kohana постарше, поэтому есть базовый контроллер от которого все наследуются, а в нем в методе before описан вызов ACL.

[divanikus]

Подождите, так это все равно безопасность на какой-то класс, я так понимаю, а не на конкретный инстанс с наследованием… Блин, может отказаться от этой идеи, как-то сложновато…

[Вадим]

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

[divanikus]

Идея вроде интересная, только вот мне кажется разными путями пойдут роуты… Ну т.е. тот же форум это например /forum/295, а топик в нем — /topic/5273 — явного наследования тут не видно вроде. Ну в смысле топик от топика-то понятно, а вот топик от форума… Или надо видимо сами роуты как-то посложнее организовать.

[Вадим]

/forum/ — Контроллер форума
/forum/topic/ — Контроллер топиков

Иерархия роутов, такая как иерархия сущностей в приложении