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

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

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

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

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

Общий дизайн базы данных:

дизайн

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

пример

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

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


person NedRise    schedule 12.02.2017    source источник
comment
Кстати, только что понял, что этот ответ также может оказаться полезным: stackoverflow.com/questions/30701482/mysql-access-control   -  person David Brossard    schedule 13.02.2017
comment
спасибо за быстрый ответ :) Мне понадобится некоторое время, чтобы глубже изучить ваши предложения.   -  person NedRise    schedule 14.02.2017


Ответы (1)


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

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

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

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

В ABAC у вас есть следующие понятия:

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

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

  • Открытый исходный код: SunXACML, ATT XACML
  • Коммерческий: сервер политик Axiomatics
person David Brossard    schedule 13.02.2017
comment
Другие альтернативы с открытым исходным кодом, упомянутые на странице Википедии XACML, такие как AuthzForce или WSO2 Balana. - person cdan; 24.05.2017