Детальная авторизация для доступа к объектам базы данных

Question

Каков наилучший архитектурный подход для приведенного ниже примера использования:

1. Модель домена содержит компанию, отдел и должность.
2. Компания может иметь несколько отделов. Отдел может иметь несколько позиций.
3. Любой пользователь может иметь три уровня разрешений для каждого объекта - «Администратор», «Запись» или «Чтение».
4. Если у пользователя есть «Администратор» доступ к Компании - тогда он имеет административный доступ к любому дочернему объекту. Если пользователь имеет доступ «Запись» к Департаменту, то любая должность в департаменте наследует это право доступа.
5. Объекты должны храниться в постоянном хранилище, например, в реляционном или документном БД.

Насколько я понимаю, области OAuth не применимы для описанных выше случаев использования. Один из способов - сохранить все данные (включая разрешения) в реляционной базе данных и каждый раз запрашивать их, используя объединения. Другой способ - создать внешнюю систему, такую ​​как LDAP, которая будет хранить отношения между сущностями и управлять их разрешениями. Сами сущности все еще хранятся в некоторой базе данных.

Оба приведенных выше варианта выглядят не слишком привлекательно по понятным причинам. В первом случае у вас слишком много объединений. Во втором случае вам может быть трудно управлять целостностью данных в двух системах. Кроме того, это нарушает принцип единого источника истины.

Вариант использования должен быть типичным для разработки программного обеспечения, но я не нашел ни одного совета «передового опыта» для этого варианта использования. Буду признателен за любые предложения или ссылки на внешние ресурсы.

Answer 1

Рекомендуется использовать управление внешней авторизацией (EAM).

Управление внешней авторизацией предлагает более детальный способ управления доступом внутри организации. (Gartner)

EAM дает вам:

• управление доступом на основе атрибутов (ABAC), т. Е. Управление доступом, которое использует параметры (атрибуты) пользователя, ресурса, действия и контекст, а не просто определяет управление доступом с точки зрения ролей или разрешения
• p управление доступом на основе olicy то есть набор политик, которые объединяют атрибуты и определяют, что может или не может произойти. Например:
  • менеджеры могут просматривать собственный профиль компании.
  • никто не может редактировать профиль компании, если он только готов.

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

Все ваши требования выражаются в виде политик.