Несколько уровней авторизации, не только на основе ролей

Question

Наше приложение использует несколько способов авторизации доступа к данному ресурсу. Хотя это работает, это грязно и ... ну, это не кажется правильным.

1) Ролевая авторизация

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

На данный момент ресурсами являются просто действия MVC, отображенные в таблице базы данных как module, controller и action.

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

2) Авторизация пользователя

Помимо авторизации на основе ролей, пользователи могут иметь более или менее доступ к подмножеству ресурсов другой роли. Например:.

RoleA : ресурсы a , b , c , d
RoleB : ресурсы x , y , z
RoleC : ресурсы 1 , 2 , 3
Пользователь1 : имеет RoleA , но ему необходим доступ к ресурсу y
Пользователь2 : имеет RoleB и RoleC , но не имеет доступа к ресурсу z

Это реализовано в виде таблицы user_resources с записями для дополнительных ресурсов, к которым у пользователя есть доступ или в которых ему отказано (обозначено флажком).

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

3) Авторизация состояния модели

Если этого недостаточно, некоторые действия могут быть выполнены только тогда, когда модель находится в определенном состоянии (каждая модель знает, когда что-то можно сделать). Например: заказ может быть отредактирован, только если у пользователя есть доступ к ресурсу edit (с помощью шагов # 1 или # 2) и объект Order можно редактировать.

Пример Anoter: пользователь может получить доступ к Customer, если у него есть доступ к ресурсу /customer/view, и он владеет этим клиентом (он является контактной информацией для этого клиента) .

4) Отображение информации в пользовательском интерфейсе

Роль, группа ролей или отдельные пользователи могут видеть более или менее информацию о модели в зависимости от ее состояния.

Как я могу упростить этот процесс авторизации, не теряя при этом гибкости в предоставлении или ограничении доступа к ресурсам?

Есть какой-то шаблон, который мне здесь не хватает, чтобы объединить все эти полномочия в одном месте?

Answer 1

Спустя долгое время я наконец нашел ответ, который удовлетворяет всем моим требованиям: http://lostechies.com/derickbailey/2011/05/24/dont-do-role-based-authorization-checks-do-activity-based-checks/.

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

В этом подходе хорошо то, что проверка разрешений выполняется для самого действия, а не для ролей.

Answer 2

Я реализовал управление доступом, используя шаблон спецификации , который, как мне кажется, подходит для этого. Центральный метод - isSatisfiedBy. X разрешено делать y, если оно удовлетворяется z. Например, пользователю разрешено просматривать «страницу администратора», если она удовлетворена «имеет роль администратора». Посмотрите, как isSatisfiedBy может быть очень общим (например, «это пользователь с идентификатором 324», «авторизовался в течение 30 минут», «является членом группы foo», ...). Правила становятся следующими общего вида:

allow X to do Y if X satisfies Z