Comments 8
Вот например у меня есть в системе разные сущности, например, контрагент, заказ, исполнитель заказа, и разные пользователи должны иметь доступ только к некоторым контрагентам, а пользователи исполнителей - только к тем заказам, с которыми связаны из организации.
И при этом приложение развивается и в нем появляются новые сущности и новые пользователи.
А сущности в системе исчисляются сотнями миллионов.
Как организовать логику так, чтобы во время выполнения кода осуществлялись проверки, имеет ли конкретный пользователь доступ к определенной сущности?
И как выбирать из БД только те сущности, к которым текущий пользователь имеет доступ?
И чтобы это очень быстро работало.
В этом случае мы пробуем такой подход: выносим логику всей авторизации в сервис на основе Open Policy Agent. И все проверки делает через него.
Для тех случаев, когда нужна производительность - тогда используем partial evaluation и генерим sql предикаты.
Если интересно - можно поискать по таким словам:
How Miro leverages Open Policy Agent to implement authorization-as-a-service
AWS Prescriptive Guidance - Multi-tenant SaaS authorization and API access control
How to build authorization like Netflix with Open Source?
Write Policy in OPA. Enforce Policy in SQL.
В статье много интересного для новичков, но не описан ещё один интересный подход. Заключается он в разделении логики ролей и разрешений (permission). У каждой роли могут добавляться, изменяться и удаляться разрешения. Каждому человеку можно прописать сколько угодно ролей.
В итоге каждая точка доступа сверяет разрешения текущего пользователя с необходимыми разрешениями, что даёт большую гибкость
Вероятно, Вы про этот подход: https://habr.com/ru/articles/539778/ (статья про Casbin)?
Прикол в том, что это все равно будет неполное решение. Там более мелкие кирпичики контроля доступа, но без abac это все полная херня. Ты выдал обычным пользователям разрешение "удалить файл" и теперь каждый пользователь может удалить любой файл)
Так что только abac с применением rbac (с разрешениями) как одного из способов проверки доступов, иначе гибкость будет неполная
Спасибо за статью! Редко можно увидеть, когда не путают аутентификацию с авторизацией😃
Скажите пожалуйста, может знаете как этот подход к контролю доступа называется, мне недавно в голову пришло: условно имеем таблицу с 4 полями: класс модели, айди модели, юзер айди и тип доступа (чтение, редактирование и тд). Соответственно, заполняется эта таблица при создании какой-либо сущности. Суть в тотальном упрощении проверки доступа к ресурсу путем однострочного sql запроса, без сложных проверок (они будут сделаны при создании ресурса каким-то отдельным сервисом). Спасибо!
Основы Identity and Access Management (IAM) в архитектуре приложений