Контроль доступа: RBAC с дополнительным членством в группах вместо свойств объекта

Question

Учитывая приложение, которое показывает объекты (например, фильмы) в соответствии с определенными правами пользователя.

общий вид разрешение на показ или создание объектов реализовано как RBAC с ролями и разрешениями.

Разрешение на доступ к объекту с определенными атрибутами (например, фильм с атрибутом «драма») должно быть реализовано с помощью членства. Это означает, что объект не обладает свойством «драма», он является членом группы «драма». Если пользователь и объект являются членами одной и той же группы, пользователь имеет специальное разрешение на доступ к этому объекту. Для отображения, создания или удаления объекта могут быть разные группы, например, простая группа зрителей или какая-то группа редакторов. Кроме того, существует таблица, которая указывает, какие типы групп релевантны для определенных действий над определенными объектами. Например, соответствующими группами для действия «показать» на объекте «фильм» могут быть «жанр» и «возраст» (пригодность фильма для определенных аудиторий).

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

Общая структура базы данных:

Пример: Фильм "Выживший" является членом группы "жанр: драма" и "возраст: 18". Пользователь может получить к нему доступ, если он также является членом этих групп.

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

Пожалуйста, поделитесь своими мыслями по этому вопросу со мной - выбор «драмы» как категории для примера не является совпадением;) Я просто не знаю, является ли это тупиком или я направляюсь в правильном направлении , Я застрял в этой точке довольно долгое время.

Answer 1

По крайней мере, у вас есть хорошее чувство юмора :-)

Ваш подход звучит отлично. До тех пор, пока вы сохраняете небольшое количество параметров, вы можете уйти с контролем доступа на основе ролей (RBAC) и несколькими дополнительными параметрами, например. членство в группах.

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

Для этого существует модель управления доступом под названием Access Access Control Control (ABAC), которая позволит вам определять свои политики авторизации независимо от вашего кода.

В ДКСЕ, у вас есть следующие понятия:

• архитектура, которая определяет точку применения политики (PEP) и точку принятия решения политики (PDP). PEP находится перед (или внутри) вашего приложения. Он перехватывает бизнес-запросы (например, запрос на просмотр фильма) и отправляет запрос авторизации PDP.PDP настроен с политиками. На основании запроса PDP примет решение: либо «да», «Разрешить», либо «Нет», «Запретить».
• политический язык: язык политики основан на атрибутах (отсюда и название ABAC). Это означает, что вы можете использовать любое количество атрибутов (например, роль пользователя, идентификатор пользователя, членство в пользовательских группах, а также возраст пользователя, местоположение пользователя, подписка на пользователя, а также атрибуты ресурсов, такие как рейтинг фильмов, категория фильма, цена фильма ...)
• схема запроса/ответа: так вы запрашиваете авторизацию. Это по существу поток «да/нет». «Может ли пользователь сделать X?», «Да, они могут».

Существует несколько вариантов реализации ABAC, некоторые из которых относятся к конкретным средам, например. CanCanCan. XACML и ALFA - это два подхода, которые не привязаны к какой-либо конкретной структуре. Вы можете выбрать один из открытых источников и коммерческих реализаций любого языка, например:

• Open Source: SunXACML, ATT XACML
• Коммерческая: Аксиоматика Сервер политики