Как на практике реализуют распределения прав доступа?

Question

[Алексей Юдов]

Доброго утра всем!
Сейчас занимаюсь проектом, который требует создания системы распределение прав доступа. В данную задачу входит следующее:
- Ограничение доступа к корпоративным страницам
- Ограничение доступа к отдельным частям сайта ( например к виджетам или каким компонентам )
список не полный, но уже на этом этапе я столкнулся с проблемой того, что не знаю как организовать такую систему.
Прошу дать полезный совет и ссылку на литературу, буду очень благодарен.
А за полные ответы ( "совет" + "ссылка" ) буду сразу ставить лайк и отмечать решением. Спасибо.

Comments

[other_letter]

Что именно Вы хотите? Что непонятно?
Литература Вам вряд ли что-то даст, потому как практически всегда это описание в общих словах, принципы, базис.

[Алексей Юдов]

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

Answer 1

[Stalker_RED]

Лучше чем RBAC вроде ничего не придумали.

Вот реализация RBAC с кодом на примере laravel https://habr.com/post/321678/

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

А вообще подходов намного больше, можно походить по ссылкам "см также" из этих статей.

Comments

[Виктор П.]

Привет, помню, вы мне отвечали в ветках по c#. Можете пояснить несколько моментов. Для своих домашних проектов (.net framework) я пользуюсь аутентификацией/авторизацией по умолчанию, не уверен, как правильно называется база, которая создается. Там всё достаточно гладко и понятно. Появляются фильтры (аттрибуты контроллеров), что-то типа
[Authorize(Roles="Admin")]
Есть еще некие клаймы для более тонкой настройки. Есть несколько готовых методов работы со всем этим.
Но вот что меня смущает, в более сложном варианте есть три уровня для авторизации: это фронтенд, бекенд и база.

На уровне бека я привел строчку, мы можем отсекать пользователей и это готово из коробки.
На уровне базы, если это нужно (например, есть организация и у неё есть список сотрудников. Чтобы пользователь, привязанный к организации, мог получить только сотрудников своей организации одним запросом ToList без дополнительных Where), можно сделать фабрику контекстов и разбирать по клаймам к какой организации привязан пользователь на все запросы накидывать Where.
Ну или чем-то подобным. Суть в том, что реализовать можно, но уже нужно что-то допиливать руками.
А вот с фронтом, например, накинуть disable на какие-то кнопки, придется так же кастылять проброс доступных use case-ov, экшинов, или кто как называет, на клиент. В смысле, на клиенте доработки понятны, но созданная база для этого уже не подходит, то есть весь этот уровень нужно самому писать. Или я это как-то не так себе представляю?

[Stalker_RED]

Виктор П., сорри, я практически не умею в дотнет. Возможно отвечал на какие-то простые вопросы, но в этом вопросе про клиент ничего не понимаю.

Answer 2

[other_letter]

Сильно зависит от технологий, используемых способой аутентификации и т.п.

Если я правильно понял вопрос, то Вам по сути нужно:

1. Сделать список всех элементов (разделов, виджетов и т.п.)
   
2. Сделать список ролей (админ/пользователь и т.п.) Не рекомендуется ,конечно, привязываться к "телу", лучше к роли
   
3. Сконфигурировать роли (какая роль имеет доступ к какому элементу)
   
4. отобразить результат в (лучше древовидном) виде элементов
   

...но всё это настолько просто, что я сомневаюсь - правильно ли понял вопрос.

Можно копнуть фундаментальнее:
Эти самые роли длячего-то предназначены. И их функционал должен быть где-то описан. У меня это обычно описание процесса (Process Model).
...но если Вы займётесь этим - там очень много работы.

Comments

[Толстый Лорри]

Управление доступом к ресурсам - это авторизация, от способов реализации аутентификации она не зависит.

[other_letter]

Толстый Лорри, отнюдь.
Почти всё, конечно, решаемо, но к примеру собирать последние события из JBoss при аутентификации через КриптоПро - никак. Точнее, с костылями сделать можно, но скорость реакции в лучшем случае 10-15 секунд, что во многих случаях недопустимо.

[Толстый Лорри]

other_letter, видимо, это личные трудности КриптоПро.

[other_letter]

Толстый Лорри, и? Теперь пытаться сдать проект в таком виде?

[Толстый Лорри]

other_letter, не возводить это свойство в абсолют, объясняя принцип построения архитектуры авторизации.