Посоветуйте, какая должна быть архитектура ПО. Т.е. есть таблица пользователей, есть роли, роли выполняют определенные функции. Как делать проверку на роли и т.п. при выполнении функций...
приложение будет написано на J2EE, сервер Tomcat, технология XSLT + сервлеты.
Я в своё время сделал так
Элементарные права (чтение или запись конкретного свойства конкретного типа объектов) объединял в роли.
Пользователей объединял в группы. Группы могли в себя включать другие группы, но без циклических зависимостей.
Роли назначал группам.
В целом весьма гибко, но если изначально не создать вменяемые роли установка прав доступа превратится в кошмар.
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, _me_, Вы писали:
A>Я в своё время сделал так A>Элементарные права (чтение или запись конкретного свойства конкретного типа объектов) объединял в роли. A>Пользователей объединял в группы. Группы могли в себя включать другие группы, но без циклических зависимостей. A>Роли назначал группам.
A>В целом весьма гибко, но если изначально не создать вменяемые роли установка прав доступа превратится в кошмар.
А как делать проверку на роль при выполнении каких либо операций? где это делать? в контроллере если у меня шаблон MVC.
Здравствуйте, _me_, Вы писали:
__>А как делать проверку на роль при выполнении каких либо операций?
При попытке выполнения какого-либо действия проверяется, разрешает ли это действие какая-либо из ролей, назначенных группам в которые входит пользователь. В целях оптимизации после логина запоминается список всех групп в которых состоит пользователь.
__>где это делать? в контроллере если у меня шаблон MVC.
Я счёл разумным предположить, что в многопользовательской системе модель сама по себе не бывает, а бывает только в контексте какого-либо пользователя. Это достаточно очевидно, если вспомнить, что разные пользователи могут иметь разный доступ даже на чтение и каким-то конкретным пользователям какие-то конкретные данные могут быть "не видны". Таким образом проверка прав доступа и соответствующая фильтрация данных производится в модели. Модель при этом удобно разбить на слой непосредственно доступа к данным и слой безопасности, потенциально отклоняющий и модифицирующий запросы. Производить проверку в контролёре я считаю неразумным, так как контролёров для одной и той же может быть много. Кроме того, проверка в модели оптимальнее, так как у базового хранилища запрашиваются уже отфильтрованные данные.
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, _me_, Вы писали:
__>>А как делать проверку на роль при выполнении каких либо операций?
A>При попытке выполнения какого-либо действия проверяется, разрешает ли это действие какая-либо из ролей, назначенных группам в которые входит пользователь. В целях оптимизации после логина запоминается список всех групп в которых состоит пользователь.
__>>где это делать? в контроллере если у меня шаблон MVC.
A>Я счёл разумным предположить, что в многопользовательской системе модель сама по себе не бывает, а бывает только в контексте какого-либо пользователя. Это достаточно очевидно, если вспомнить, что разные пользователи могут иметь разный доступ даже на чтение и каким-то конкретным пользователям какие-то конкретные данные могут быть "не видны". Таким образом проверка прав доступа и соответствующая фильтрация данных производится в модели. Модель при этом удобно разбить на слой непосредственно доступа к данным и слой безопасности, потенциально отклоняющий и модифицирующий запросы. Производить проверку в контролёре я считаю неразумным, так как контролёров для одной и той же может быть много. Кроме того, проверка в модели оптимальнее, так как у базового хранилища запрашиваются уже отфильтрованные данные.
Не надо забывать, что помимо разграничения доступа к данным, есть и разграничение доступа к операциям или функциональным возможностям. Такие проверки разумно выполнять именно в контроллере.
Обычно подсистема авторизации выделяется в отдельный модуль. Желательно чтобы она была жестко инкапсулирована и не оставляла никаких возможностей проверки прав доступа минуя свой public интерфейс.
Здравствуйте, stump, Вы писали:
S>Не надо забывать, что помимо разграничения доступа к данным, есть и разграничение доступа к операциям или функциональным возможностям. Такие проверки разумно выполнять именно в контроллере. S>Обычно подсистема авторизации выделяется в отдельный модуль. Желательно чтобы она была жестко инкапсулирована и не оставляла никаких возможностей проверки прав доступа минуя свой public интерфейс.
Stateless функциональные возможности большая редкость. Обычно всё так или иначе сводится к возможности писать или читать те или иные данные. Что касается системы авторизации, то да, она должна быть не только жёстко инкапсулирована, но и защищена. Скажем в клиент-серверной системе она должна обязательно в полном объёме присутствовать и на сервере.
Здравствуйте, _me_, Вы писали:
__>Посоветуйте, какая должна быть архитектура ПО. Т.е. есть таблица пользователей, есть роли, роли выполняют определенные функции. Как делать проверку на роли и т.п. при выполнении функций...
__>приложение будет написано на J2EE, сервер Tomcat, технология XSLT + сервлеты.
Как раз место для аспектов — советую посмотреть перед реализацией на AspectJ / Spring AOP и книжки типа AOP in Action (есть пример, ну и в сети что-то было — поищите). Смысл примерно такой — вы просто пишете код без проверки всяких там прав. Затем пишете код проверки прав доступа, определяете точки расширения и подключаете аспект.
Здравствуйте, _me_, Вы писали:
__>Посоветуйте, какая должна быть архитектура ПО. Т.е. есть таблица пользователей, есть роли, роли выполняют определенные функции. Как делать проверку на роли и т.п. при выполнении функций...
__>приложение будет написано на J2EE, сервер Tomcat, технология XSLT + сервлеты.
Права объединены в роли, которые назначаются пользователям, где каждому пользователю можно дополнительно добавить или убрать право из его списка прав(List rights = User.getRights()) ...
Все права в идеале должны проверяться на сервере, по возможности и на клиенте что бы не допускать лишних запросов и действий, но возможны и какие то другие частные варианты ...
В первом случае с каждым объектом модели ассоциируется т.н. Discretionary Access Control List — cписок разрешений. Каждое разрешение, ACE (Access Control Entry) либо разрешает, либо запрещает некоему субъекту определенное действие. Субъектом обычно выступает пользователь, группа, либо специальный субъект типа CREATOR_OWNER.
Такая схема позволяет очень гибко настраивать правила доступа, но требует значительных приседаний, чтобы настройки по умолчанию более-менее соответствовали ожиданиям, и администратору не приходилось вручную настраивать списки для каждого объекта.
Во втором случае обычно поступают так: готовится фиксированный список ролей; привилегированные действия требуют наличия некоторой (как правило, одной) роли.
Управление безопасностью сводится к назначению этих фиксированных ролей пользователям.
Эта значительно менее гибкая схема тем не менее позволяет добиться, во-первых, высокой эффективности операций (проверка IsUserInRole обычно дешевле, чем сканирование DACL с учетом наследования и прочих особенностей), а во-вторых — понятности для человека. Не нужно вычислять effective permissions для подозрительной пары объект/субъект, достаточно посмотреть в список ролей пользователя.
Теперь о реализации. Проверка прав доступа обычно делается в "пограничном слое".Желательно разделить все функции на "внутренние", в которых никаких проверок не осуществляется, и "внешние". Внутренние функции не должны быть видны из внешнего кода; внешние функции должны выполнить авторизацию и вызвать нужные внутренние.
Такое устройство позволяет избежать избыточных проверок. Это улучшает производительность, и позволяет обойти острые углы: к примеру, если у пользователя нет права на изменение объекта, но есть право на действие, которое внутри изменяет состояние объекта.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, _me_, Вы писали:
__>Посоветуйте, какая должна быть архитектура ПО. Т.е. есть таблица пользователей, есть роли, роли выполняют определенные функции. Как делать проверку на роли и т.п. при выполнении функций... __>приложение будет написано на J2EE, сервер Tomcat, технология XSLT + сервлеты.
Возможно вам будет интересно поглядеть книгу
Rockford Lhotka — Expert C# 2005 Business Objects — книга о построении целого Framework'а для использования при разработки бизнес-приложений. С примерами.
