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

Question

Я работаю над веб-приложением Rails, и в настоящее время он используется примерно 20 пользователями.

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

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

С другой стороны, пользователи видят ссылки на действия, для которых у них есть недопустимые привилегии. Например, те, кто находится в отделе продаж, видят ссылку на финансовые записи в главном меню, но когда они нажимают на нее, ничего не происходит. Это связано с тем, что AFAIK не имеет эффективного способа запроса прав пользователя с помощью act_as_authenticated.

Я хочу изменить это двумя способами:

1. Я хочу представить более мелкозернистой авторизации. В настоящее время авторизация выполняется на уровне контроллера. Я хочу сделать это на уровне действия или модели. Например, я хочу, чтобы сотрудники отдела продаж могли создавать и обновлять платежи, но не удалять их.

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

Как вы считаете, самый элегантный способ реализовать это?

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

Наконец, вот как она реализована в настоящее время:

def authorized? 
    current_user.role.foo? or current_user.role.bar? 
end 

И вот моя первоначальная идея, которую я думаю, что это не самый лучший способ решить эту проблему:

 
+------------+------------+---------+ 
| department | controller | action | 
+------------+------------+---------+ 
| accounting | payments | index | 
| accounting | payments | new  | 
| accounting | payments | create | 
| accounting | payments | edit | 
| accounting | payments | update | 
| accounting | payments | destroy | 
| sales  | payments | new  | 
| sales  | payments | create | 
| sales  | payments | edit | 
| sales  | payments | update | 
+------------+------------+---------+ 

или

 
+------------+----------+-------+--------+------+--------+--------+ 
| department | model | list | create | read | update | delete | 
+------------+----------+-------+--------+------+--------+--------+ 
| accounting | payments | TRUE | TRUE | TRUE | TRUE | TRUE | 
| sales  | payments | FALSE | TRUE | TRUE | TRUE | FALSE | 
+------------+----------+-------+--------+------+--------+--------+ 

Answer 1

Основная концепция авторизации, как я ее понимаю, - это роль. роль может выражать различные вещи:

1. отношение пользователя к системе в целом
2. отношение пользователя к какому-то сущностей (например, (например, быть администратором системы.). быть модератором комментариев)
3. отношение пользователя к определенному объекту (например, для владельца какого-либо ресурса)
4. какое-либо другое сложное отношение (например, быть другом пользователя, являющегося владельцем некоторый ресурс)
5. у пользователя есть некоторые атрибуты или он отвечает на какое-то сообщение в какой-то части r (например. быть подростком)

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

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

Способ, который работает для меня в Rails, заключается в определении ролей на уровне модели и выходе из механизма авторизации (установка разрешенных ролей для частей кода, которые я хочу получить авторизованным, и спрашивать, разрешена ли текущему пользователю роль для запуска части) полностью для контроллеров/представлений.

Для этого я использую tweaked rails-authorization-plugin, который имеет все возможности, о которых я только что упомянул, построенный прямо (различные роли, много ролей для одного пользователя, авторизация на контроллере и уровень просмотра).

Answer 2

вам может потребоваться ввести понятие «функциональные точки» или «функции» в вашу модель в качестве контрольных точек для acc ESS; «функция» может иметь необязательную «родительскую функцию» для формирования иерархии. Вы решаете, что такое, а что нет, и программно проверяйте разрешения. Это также должно позволить вам проверить доступ на уровне объектов до рисования меню, чтобы пользователи никогда не видели ссылки на страницы, к которым им не разрешен доступ.

аналогичная ситуация/решение описывается here

Answer 3

Из двух ваших предложений, первый вариант выглядит немного лучше, так как это позволяет добавлять действия, которые не могут быть действия модели на уровне. Я предполагаю, что вы столкнетесь с тем случаем, когда вторая модель не делает достаточно, и вам нужно либо изменить схему, либо запустить процедуру разрешений на все ваши приложения (например,«Пользователи, не„создать“доступ также не может запустить метод ххх»)

Я думаю, что причина решение не выглядит очень DRY, что есть повторение:

1. В названиях отделов и
2. в возможностях отдела

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

Что касается №2, я согласен с первым комментарием. Вероятно, вы можете сгруппировать различные контроллеры и действия в функциональные группы, а затем установить множество отношений (таблицу сопоставлений) между пользователями и функциями. После этого функции будут иметь отношение «один ко многим» с теми действиями/контроллерами, которые они разрешают. Это позволило бы вам с минимальным повторением сказать такие вещи, как «учет и продажа должны иметь возможность читать все финансовые таблицы».