Разрешения на основе ролей Django - PullRequest
0 голосов
/ 04 декабря 2018

Я разрабатываю огромное приложение в django, и мне нужна система разрешений, и я предполагаю, что собственное разрешение пользователя / группы в django недостаточно.Вот мои потребности:

Приложение будет доступно через несколько отделов.В каждом отделе будут происходить практически одинаковые действия.Но, возможно, пользователю будет разрешено добавить нового члена команды в отдел A и в отдел B, ему разрешено только просматривать список команд, а в других отделах он вообще не имеет доступа.Я, хотя использование системы RBAC было бы наиболее подходящим.Роли также должны быть наследуемыми, храниться в модели, управляемой через интерфейс.Есть хорошие идеи или предложения?Привет

Ответы [ 2 ]

0 голосов
/ 08 декабря 2018

То, что вы ищете, называется aka Управление доступом на основе атрибутов.Это эволюция RBAC как модели контроля доступа.В RBAC вы определяете управление доступом в терминах ролей, групп и, возможно, разрешений.Затем вам нужно написать код в вашем приложении, чтобы понять роли и группы.Это называется управление доступом на основе идентичности .

В ABAC появилось 2 новых элемента:

  • атрибуты, которые являются обобщением групп и ролей.Атрибуты представляют собой пару ключ-значение, которая может описывать кого угодно и что угодно.Например, department, member и action являются атрибутами.
  • политики связывают атрибуты вместе, чтобы определить, следует ли предоставить доступ или запретить.Политика - это дружественный для человека способ выражения авторизации.Вместо того чтобы писать собственный код в своем приложении, вы пишете политику, которой можно централизованно управлять и повторно использовать в приложениях, базах данных и API.

Существует несколько языков ABAC, таких как и .Используя ALFA, я мог бы написать следующую политику:

  • Пользователю будет разрешено добавить нового члена команды в отдел A
  • В отдел B ему разрешено толькопросмотреть список команд
  • В других отделах он вообще не имеет доступа.
  • Роли также должны быть наследуемыми, храниться в модели, управляемой через интерфейс.
policyset appAccess{
    apply firstApplicable
    policy members{
        target clause object = "member"
        apply firstApplicable
        /**
         * A user can add a member to a department if they are a manager and if they are assigned to that department.
         */
        rule addMember{
            target clause role == "manager" and action == "add"
            permit
            condition user.department == target.department
        }
    }
}

Одним из ключевых преимуществ ABAC является то, что вы можете разрабатывать столько политик, сколько захотите, проводить аудит, делиться ими и вообще не трогать код своего приложения.потому что вы заканчиваете экстернализацию авторизации.

Существует несколько механизмов / проектов, которые реализуют ABAC, таких как:

  • AuthZForce (библиотека Java для авторизации XACML)
  • Axiomatics Policy Server (коммерческий продукт - отказ от ответственности: я там работаю)
  • AT & T XACML
0 голосов
/ 04 декабря 2018

Этот вопрос состоит из двух компонентов:

Во-первых, управление ролями.Роли могут быть достигнуты с помощью членства в группах, т.е.К этим группам будут прикреплены соответствующие разрешения, например, «Member | Add» и «Member | View».В этом контексте отдел может иметь больше ресурсов, для которых требуются отдельные разрешения.Django позволяет расширять объекты с пользовательскими разрешениями .

Во-вторых, наследование.Я понимаю, что вы хотите, чтобы отдельные группы были членами других групп?Тогда это то, что Django потребует от вас реализовать самостоятельно.

Однако, если вы ищете действительно более сложное решение для аутентификации, возможно, стоит интегрироваться со сторонними сервисами, например, django-allauth .Есть, конечно, больше / другие решения, просто чтобы добавить одно имя.

...