Перейти к основному контенту

RBAC

Определение роли​

[role_definition] - это определение отношений прав наследования роли RBAC. Casbin поддерживает несколько экземпляров систем RBAC, напр. пользователи могут иметь роли и их отношения с наследованием, а ресурсы могут также иметь роли и их отношения с наследованием. Эти две системы RBAC не будут мешать этому.

Этот раздел является необязательным. Если вы не используете роли RBAC в модели, то пропустите этот раздел.

[role_definition]
g = _, _
g2 = _, _

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

Касбин хранит реальное сопоставление ролей пользователей (или сопоставление ролей ресурсов, если вы используете роли на ресурсах) в политике, например:

p, data2_admin, data2, read
g, alice, data2_admin

Это означает alice inherits/является членом роли data2_admin. alice может быть пользователем, ресурсом или ролью. Касбин признает его только в качестве строки.

Затем в матче, вы должны проверить роль, как показано ниже:

[matchers]
m = g(r.sub, p.sub) && r.obj == p.obj && r.act == p.act

Это означает, что часть в запросе должна иметь роль под в политике.

::note

  1. Касбин хранит только сопоставление ролей пользователя.
  2. Касбин не проверяет, является ли пользователь допустимым пользователем, или роль является правильной ролью. Это должно быть сделано путем аутентификации.
  3. Не используйте одно и то же имя пользователя и роль внутри системы RBAC, потому что Касбин распознает пользователей и роли как строки, и для Касбина не существует способа узнать, указали ли вы alice или роль alice. Вы можете просто решить это с помощью role_alice.
  4. Если A имеет роль B, B имеет роль C, затем A имеет роль C. Сейчас эта транзитность бесконечна.

:::

Token name convention

Conventionally subject token name in policy definition is sub and placed in the beginning. Now Golang Casbin supports customized token name & place. If the subject token name is sub, the subject token can be placed at an arbitrary place and no extra action needs. If the subject token name is not sub , e.SetFieldIndex() for constant.SubjectIndex should be called after the enforcer is initialized regardless of its position.

# `subject` here for sub
[policy_definition]
p =  obj, act, subject
e.SetFieldIndex("p", constant.SubjectIndex, 2) // index start from 0
ok, err := e.DeleteUser("alice") // without SetFieldIndex, it will raise an error

Иерархия ролей​

RBAC в Касбине поддерживает иерархию ролей RBAC1, что означает, что alice имеет роль1, роль1 имеет роль2, затем alice также будет иметь роль2 и наследовать его права.

Вот понятие под названием уровень иерархии. Таким образом, уровень иерархии для этого примера - 2. Для встроенного ролевого менеджера в Касбине можно указать максимальный уровень иерархии. Значение по умолчанию: 10. Это означает, что конечный пользователь, как alice , может наследовать только 10 уровней ролей.

// NewRoleManager — конструктор для создания экземпляра
// по умолчанию RoleManager.
func NewRoleManager(maxHierarchyLevel int) rbac.RoleManager {
    rm := RoleManager{}
    rm.allRoles = &sync. ap{}
    maxHierarchyLevel = maxHierarchyLevel
    rm. asPattern = false

    return &rm
}

Как отличить роль от пользователя?​

Касбин не отличает роль от пользователя в своей RBAC. Все они рассматриваются как строки. Если вы используете только одноуровневый RBAC (роль никогда не будет членом другой роли). Вы можете использовать e.GetAllSubjects() для получения всех пользователей, и e.GetAllRoles() для получения всех ролей. Они просто перечисляют все U и все r соответственно. g, u, r правила.

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

Как запрашивать неявные роли или разрешения?​

Когда пользователь наследует роль или разрешение через иерархию RBAC вместо прямого назначения их в правиле политики, мы называем такой тип задания неявным. Запрашивать неявные отношения, вам необходимо использовать эти 2 API: GetImplicitRolesForUser() и GetImplicitPermissionsForUser() вместо GetRolesForUser() и GetPermissionsForUser(). Для получения более подробной информации обратитесь к этой проблеме GitHub.

Использовать подходящий шаблон в RBAC​

Смотрите RBAC с шаблоном

Роль менеджера​

Подробнее см. в разделе Role Managers.