Лучшие практики в моделировании пользовательских ограничений в веб-приложении? - PullRequest
Новая
       24

Лучшие практики в моделировании пользовательских ограничений в веб-приложении?

4 голосов
/ 26 октября 2009

Я создаю веб-приложение с контролем доступа на основе ролей с использованием безопасности Acegi (Spring). Так что у меня есть разные пользователи с ролями: ROLE_ADMIN, ROLE_USER и т. Д.
Однако мне нужно реализовать различные пользовательские ограничения.

Давайте рассмотрим пример:

Предположим, есть сайт, где пользователи могут смотреть фильмы онлайн. Есть пользователи с ролями ROLE_STANDARD_USER и ROLE_VIP_USER. Обычные пользователи могут смотреть 3 фильма в неделю, а пользователи VIP могут смотреть 10 фильмов в неделю, а также имеют некоторые другие привилегии. И есть один пользователь в стандартной группе пользователей, которому я хочу давать дополнительно 2 фильма в неделю. Количество разрешенных фильмов может иногда меняться.
Кроме того, существуют различные категории фильмов: фэнтези, комедии, классика, новые фильмы и т. Д. И я хочу, чтобы некоторые пользователи, независимо от их роли, имели доступ только к определенным категориям. Категории могут быть созданы и удалены динамически.

Существуют ли какие-либо стандартные практики для реализации такого типа пользовательских ограничений?
Можно ли это сделать, используя роли и разрешения Spring Security?
Или мне нужно добавить в приложение движок на основе правил?

Спасибо.

Edit:
Приведенный выше пример вымышленный, мой проект связан с предоставлением удаленного доступа к различным сетевым (и другим) оборудованию для студентов. Однако типы пользовательских ограничений могут быть одинаковыми.
К сожалению, Модель для доступа и ограничений пользователей не является полной и стабильной. В ближайшем будущем мне могут предложить ввести различные дополнительные ограничения для пользователей, которые пока неизвестны.
Поэтому я хотел бы сейчас выбрать путь, который облегчит добавление или изменение новых пользовательских ограничений в будущем и не потребует значительного пересмотра внутренней модели или структуры базы данных. Если это вообще возможно.

Редактировать 2

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

Спасибо за все предложения!

Ответы [ 5 ]

4 голосов
/ 26 октября 2009

Я бы не ожидал, что декларативная система безопасности на основе ролей обеспечит детальный контроль, который вы ищете. Вы уже описали довольно много элементов управления доступом на основе бизнес-правил, которые вы хотите реализовать, и мы можем ожидать, что со временем эти правила станут более сложными. Таким образом, вам нужна комбинация информации из подсистемы безопасности (кто является пользователем для этого запроса? Какие роли у них есть?), Но затем программно объединить это с бизнес-данными и правилами (этот пользователь имеет право на 2 бесплатных фильма, если на сегодняшний день находится в этом диапазоне).

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

1 голос
/ 27 октября 2009

Если вы рассматриваете Spring Security, я вижу, что это один из способов реализовать ваше решение. Реализуйте AccessDecisionVoter, чтобы принять решение о доступе пользователя. Взгляните на справочный источник здесь

Также посмотрите на [javadoc] [2] для AccessDecisionVoter. Вы можете реализовать свои правила с помощью метода vote. 

int vote(Authentication authentication,
         Object object,
         ConfigAttributeDefinition config)

Пусть Spring обрабатывает доступ (аутентификация и авторизация). Если процесс принятия решений усложняется, можно использовать механизм правил. Позвольте методу голосования вызвать механизм правил. Это обеспечивает четкое разделение обязанностей. Пусть Spring Security обрабатывает доступ, и пусть механизм правил вычисляет правила.

[2]: http://static.springsource.org/spring-security/site/apidocs/org/springframework/security/vote/AccessDecisionVoter.html#vote(org.springframework.security.Authentication, java.lang.Object, org.springframework.security.ConfigAttributeDefinition)

1 голос
/ 26 октября 2009

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

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

Пример Модель для ваших нужд:

  • Ограничить количество обычных фильмов в неделю в соответствии с суммой :
    • Роль (3 или 10)
    • бонус за пользователя (по умолчанию 0, если не указан)
  • Обновите эти номера при необходимости
  • Ограничить фильмы списком категорий:
    • если для пользователя указан список, используйте его
    • в противном случае используйте список, предоставленный для роли

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

  • после обновления номера, лимит изменяется немедленно.
  • нет памяти о недельных лимитах, вы не можете спросить об этом в прошлом (например, для статистики)
  • ...

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

0 голосов
/ 26 октября 2009

Звучит так, будто у вас есть потребности в аутентификации и авторизации - часто люди путают их и / или объединяют. К счастью, Spring Security хорошо их разграничивает. Ваш пользователь будет проходить проверку подлинности через цепочку безопасности (будь то форма logj, openID, SSL X509), а затем, когда он будет авторизован вашими избирателями в вашей компании (в ваших AccessDecisionManagers), чтобы узнать, видели ли они уже выделенный номер фильмов. Если позже необходимо добавить новую бизнес-логику, это просто вопрос написания новых / большего числа избирателей и добавления их в вашего менеджера.

0 голосов
/ 26 октября 2009
...