Xpoint
   [напомнить пароль]

Модель расчета динамических ролей(рантайм опредение связей)

Метки: [без меток]
2006-02-20 19:00:14 [обр] docker(0/1)[досье]

Планируется оптимальная архитектура разграничения прав для некоторого подобия ERP-системы. А именно такой специфический security-level, который был бы универсальным для различного рода объектов системы и который сам бы проверял все права, вытекающие как из статических, так и динамических ролей пользователя(свя).

Статическая роль – то что принято считать: роль, которая обеспечивает для ее пользователей повсеместный доступ для объектов определенного класса ВНЕ зависимости от свойств этих объектов. Например, роль «Администратор заказов» — значит то, что пользователи этой роли имеют доступ к любому объекту заказ.

Динамическая роль – здесь доступ к объекту рассчитывается исходя из свойств самих объектов(рантайм определение связей между объектами-субъектами). Например: роль «Ответственный за заказы» — будет иметь доступ не ко всем заказам, а только к тем, у которых он поставлен ответственным, т.е. к тем объектам-заказам у которых в свойстве «ответственный» указан id этого пользователя.

Обычно права вот этих динамических ролей разруливаются в различного рода менеджерах объектов, т.е. в дополнительном слое, вышестоящем над dal-ом и security-level. Т.е. для расчета доступа к объекту(ам) сначала стандартным образом security-level проверяет статичные роли, если там нет доступа, то делает запросы к БД для выяснения того, должен ли у этого пользователя быть доступ к данному объекту(ам) на основании каких-либо динамических ролей. Например для того же «Ответственного за заказы» — это будет дополнительный запрос в БД, который даст нам: совпадает ли id ответственного у данного заказа с id текущего пользователя.

Так вот, это же получается то, что вот эти вот права динамических ролей, их расчет мы выносим из security-level и уже в другом, более высокоуровневом слое, вручную проверяем дополнительными запросами к БД.

И вот вопрос в том, как спланировать архитектуру этого security-level, чтобы это все инкапсулировать в нем. Т.е. мы говорим ему просто: «От имени текущего пользователя – выбрать объекты такого-то класса». Он сам смотрит сначала статические права, потом каким-то образом проверяет нет ли у пользователя доступа к объекту по каким-то его динамическим ролям – и выдает результат. Например, для админа заказов – этот запрос должен будет выдать все объекты-заказы, для Ответсвенных за заказы – все заказы, у которых ответственный == текущему пользователю и т.д.

Вся проблема в том, как построить такую архитектуру, которая позволит легко и универсально добавлять, удалять динамические роли вместе со стратегиями их вычисления в этот security level.

Можно например, иметь в базе справочник динамических ролей и к каждому id этой роли жестко привязать код правила который будет определять доступность объектов по этой роли.

Как еще можно разрулить такую ситуацию? Не хотелось бы изобретать велосипед, т.к. подозреваю, что я далеко не первый кто над этим задумался и пытается реализовать. Кто как реализовал подобные ситуции? Где почитать о реализации таких моделей безопасности? Куда копать ?
    

спустя 42 минуты [обр] Александр aka Efreeti(3/111)[досье]
docker[досье]
  1. на чём пишите?
  2. какие нагрузки должна выдерживать система?
спустя 39 минут [обр] docker(0/1)[досье]
  1. Oracle 10g: PL/SQL + Java ( Oracle JVM ).
Слой отображения пока на PHP5, в скором времени возможна реализация толстого клиента.
  1. ~7000 активных пользователей системы. Параллельно с системой работают ~400.
спустя 2 часа 46 минут [обр] Александр aka Efreeti(3/111)[досье]
docker[досье]
400 - это сейчас. А что будет потом?
Просто есть уравнение: скорость = a/универсальность. Т.е. чем более система универсальна, тем медленнее она работает (а - коэффицент крутости программиста;)
Вам стоит искать что-то среднее, а не по принципу - "ща напишу мега штуку, а потом в 2 клика буду реализовывать любые связи". Программировать всё равно придётся, просто стоит максимально упростить процесс, т.е. сделать какой-то framework и повышать reusing кода.
спустя 2 часа 1 минуту [обр] docker(0/1)[досье]
Да, что-то среднее, это все верное и логично.
Но, послушайте, ведь же задача достаточно растпрастранена? Ее наверное ежедневно решают то и дело программисты на своих проектах.
Неужели не существует какого-нибудь паттерна/модели/подхода для данного случая? Может какая-нибудь не слишком медленная и связная модель простого разрешения таких ситуаций или чего-то в этом роде.
Каждый более меннее опытный программист когда-то в скором времени решает задачу о таких динамических правах, мне кажется...
???
спустя 10 часов [обр] Thirteensmay(0/157)[досье]
А как по мне - так Ваша динамическая роль не что иное как просто кусок функциональности отдельно взятого метода/процедуры. Какой смысл выделять это в отдельный механизм ? - от этого появятся только дополнительные ограничения/расходы потому как уж больно разнообразны эти динамические роли. Тем более что кода тут немного. Просто оформите это удобно - одним блоком с комментариями ;) Уж о своем опыте не мне судить, но я предпочитаю заниматься оптимизацией простых самодостаточных инструментов а не универсаализацией мегаядер...
спустя 1 день 2 часа [обр] Александр Жешев(0/50)[досье]

Кажется, самый распространенный вариант - организация таблицы прав доступа. В записи прописывается id документа, id юзера и что он может с ней делать. Далее эти права наследуются (при наличии какой-либо подчиненной структуры). Так проще и роли расставлять, и правами управлять. В общем, классика.

Единственный минус - при доступе к какому-либо ноду (если не прописывать права каждому юзеру при создании нода) приходится лезть вверх по дереву и выяснять, имеет ли этот юзер права на родителя, или на "дедушку".

спустя 13 часов [обр] docker(0/1)[досье]

> В записи прописывается id документа, id юзера и что он может с ней делать. Далее эти права наследуются (при наличии какой-либо подчиненной структуры). Так проще и роли расставлять, и правами управлять. В общем, классика.

ну а появится еще 10 связей по правам: не только пользователь-документ, но и пользователь-заказ, пользователь-сообщение и т.д. И что? Новые таблицы связки в базу добавлять, дублировать эту структуру по указанию прав, да еще как-то там их наследование аналогично разруливать/дописывать в соответствующих классах... Ну это то, что называется решение в лоб, здесь и думать никак не надо, самый банальный способ...

А вот так, чтобы это все множество связей в одной таблице как-нибудь разрулить, чтобы добавлять эти права без введения дополнительных таблиц связей и проч.. - должны же быть какие-то паттерны/модели на этот счет?

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

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

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

спустя 3 дня [обр] Александр Жешев(0/50)[досье]
Эм... не вижу разницы между предложенной классикой и вашей "новой идеей"... Кроме того, я вроде как сказал, как реализуется наследование.
Powered by POEM™ Engine Copyright © 2002-2005