Как разрешить конфликт прав Zend_Acl для пользователя с несколькими ролями? - PullRequest
0 голосов
/ 17 марта 2011

Я пытаюсь создать RBAC с Zend_Acl. У меня вопрос: я хочу, чтобы пользователи могли иметь несколько ролей, но я не уверен, как разрешать конфликты разрешений между различными ролями? В случаях, когда есть как разрешить, так и запретить, должно ли разрешение всегда отменять запрет? Как всегда, большое спасибо за то, что нашли время проверить мой вопрос. Ура!

Ответы [ 4 ]

2 голосов
/ 18 марта 2011

Думай об этом как о своем доме.

  • отрицать | лицо
  • отрицать | кто-нибудь из России
  • разрешить | член семьи
  • разрешить | Друг

Скажем, у вас плохие чувства к русским. Считаете ли вы, что вы должны лишить своего хорошего друга доступа к вашему дому только потому, что он русский? Нет. Он доказал какое-то качество, которое дало ему статус «друга». Разрешение должно переопределить запретить IMO.

Не в обиду россиянам: P

1 голос
/ 03 октября 2011

В рекомендациях по безопасности указывается, что при возникновении конфликта возникает отказ.

При этом, исходя из практического опыта, я строю безопасность следующим образом (когда речь идет о RBAC):

У каждого пользователя есть набор прав;права пользователя заменяют права группы. Каждый пользователь может иметь одно или несколько прав группы. Каждая группа имеет приоритетный уровень приложения;как правило, администратор применяется там, где последнее примененное право. Я очень редко применяю несколько групп для нескольких людей;и большинство людей, которые имеют права применять права, не могут сделать это, за исключением основного администратора (вместо этого я создаю новую группу).Я использую Negative (группы с правами Deny) ОЧЕНЬ экономно.После применения групповых прав к человеку, я провожу проверку системы на наличие конфликтов и уведомляю человека, который его применяет.В дополнение к стандартным ролям RBAC у меня также есть флаг предоставления просмотра другим, предоставления редактирования другим и т. Д.

Кроме того, используйте множество других механизмов, таких как токен сеанса sha256, используйте таблицы базы данных для временной проверки на бездействиесеансы + повторные атаки, требуют, чтобы IP-адрес пользователя оставался постоянным и т. д.

1 голос
/ 18 марта 2011

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

Другой подход заключается в определении роли пользователя, например user123

$ acl-> addRole ('user123', массив ('admin', 'banned'));

Я не знаю поведения ролей с несколькими родительскими ролями, так что проверьте это сами

0 голосов
/ 17 марта 2011

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

...