Перейти к содержанию

Базовые понятия

Доступ пользователей к Webim реализован при помощи подхода Attribute-based access control (ABAC), базируемом на атрибутах действий, объектов и т.п. В системе, использующей ABAC, разграничение прав доступа выполняется согласно решениям, которое принимает дерево политик на основе вычисления логических выражений для проверки атрибутов. Таким образом, доступы пользователя не привязаны просто к одной из существующих в системе ролей, а могут настраиваться гибко, посредством Редактора политик. Редактор политик частично использует понятия и систему выражений XACML 3.0, подробные описания которых присутствуют в данной статье, а также в статье о выражениях.

Политики, определяющие возможности той или иной роли, задаются при помощи дерева политик (Policy tree).

Реализация проверки доступа на основе атрибутов предполагается концептуально совместимой со стандартом XACML 3.0. Рекомендуется ознакомиться с терминологией стандарта и секцией Policy language model.

Решение о доступе (разрешить или запретить) принимается на основе Дерева политик. Дерево политик составляется из трех основных элементов: Правило (Rule), Политика (Policy) и Группа политик (PolicySet). Каждый из элементов дерева имеет связанную с ним логику обработки запроса доступа, которая реализована согласно стандарту.

Решения (Decision)

Дерево политик должно вернуть ответ на запрос о доступе, который должен содержать одно из возможных решений:

  • Разрешить (Allow)

  • Запретить (Deny)

  • Не применимо (Not Applicable)

  • Ошибка, решение не определено (Indeterminate)

Правило (Rule)

Согласно XACML, базовым блоком проверки доступа является Правило.

type Rule {
  target: Expression[],
  condition: Expression[],
  effect: Permit | Deny,
  advices: Advice[]
}

Правило может быть применимо к текущему запросу доступа или нет. Применимость Правил определяется по выполнению выражений-условий в полях Назначение (target) и Дополнительные условия (condition). Если все проверки возвращают истину, значит результатом будет поле effect, в противном случае возвращается решение Не применимо, т. е. все выражения в полях Назначение и Дополнительные условия объединены через логическое И, однако предполагается, что в поле Назначение проводятся простые проверки, а в поле Дополнительные условия более сложные, что позволяет быстро отбрасывать неприменимые Правила. Под простыми выражениями в Назначении понимаются выражения без функций, со сравнением атрибута с константой. Это также относится к полям Назначение для Политик и Групп политик.

Политика (Policy)

Политика объединяет несколько Правил.

type Policy {
  target: Expression[],
  rules: Rule[],
  combiningAlgorithm: CombiningAlgorithm,
  advices: Advice[]
}

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

Для случая, если в поле Назначение нет ни одного выражения, стандарт предлагает (но не требует) определять применимость Политики на основе Назначения у вложенных Правил (см. п. 3.3.2.1). Однако для большей однозначности было решено отказаться от этого в пользу следующего: если в поле Назначение у Политики нет ни одного выражения, то такая Политика применима к любому запросу доступа. Это же правило относится и к Группе политик.

Группа политик (PolicySet)

Группа политик объединяет несколько Политик и/или Групп политик.

type PolicySet {
  target: Expression[],
  items: (Policy | PolicySet)[],
  combiningAlgorithm: CombiningAlgorithm,
  advices: Advice[]
}

Логика применения Группы политик аналогична логике применения Политик за исключением того, что Алгоритм комбинирования возвращает результат на основе вложенных Политик и Групп политик.

Алгоритм комбинирования (Combining Algorithm)

Алгоритм комбинирования определяет алгоритм применения вложенных элементов: списка Правил у Политики и списка (Policy | PolicySet) у Группы политик.

Реализованы следующие Алгоритмы комбинирования из стандарта XACML:

  • Deny Overrides

  • Permit Overrides

  • Deny Unless Permit

  • Permit Unless Deny

  • First Applicable

  • Only One Applicable

Ознакомиться с описанием этих алгоритмов комбинирования можно в Приложении С (Appendix C) стандарта.

N.B.

Также стоит отметить, что стандарт дополнительно определяет алгоритмы Ordered Deny Overrides и Ordered Permit Overrides. Это вариации Deny Overrides и Permit Overrides, применяющие вложенные элементы дерева согласно порядку, в котором они были указаны. Однако для простоты и однозначности все алгоритмы считаются Ordered.

Решение о доступе (Decision Result)

Структура, представляющая собой ответ на запрос доступа – результат вычисления дерева политик. Содержит Решение о доступе и список Рекомендаций.

type DecisionResult {
  decision: Permit | Deny | NotApplicable | Indeterminate,
  advices: Advice[]
}

Рекомендации (Advice)

Рекомендация может содержать набор свойств в зависимости от типа. Общий вид:

type Advice {
  type: string,
  appliesTo: Permit | Deny,
  attributes: { ... }
}

В системе Webim реализованы два типа Рекомендаций:

  • fields - содержит информацию об ограничении на поля сущности. Имеет смысл для разрешающих Решений о доступе. Например, может быть правило, разрешающее редактировать оператору свой профиль, но в этом правиле может быть дополнительно прописано ограничение на поле Шаблоны ответов. Как следствие, оператор не сможет редактировать свои шаблоны ответов, но сможет редактировать все остальное.

  • redirect - предложение перенаправить пользователя в другой раздел интерфейса. Имеет смысл для запрещающих Решений о доступе. К примеру, если доступ к Панели управления запрещен, при наличии Рекомендации типа redirect с path='chat', оператора перенаправит в РМО.

Список Рекомендаций в ответе на запрос доступа формируется на основе Решений о доступе, возвращаемых элементами дерева согласно правилам:

  1. В Решении о доступе содержатся только те Рекомендации, которые применимы к Решению. Например, если решением является Разрешить (Permit), то в ответе должны быть только Рекомендации со значениием appliesTo == 'Permit'.

  2. Ответ от Правила содержит привязанные к нему Рекомендации.

  3. Ответ от Политик и Групп политик содержит как привязанные к ним Рекомендации, так и Рекомендации из ответов вложенных элементов, повлиявших на решение о доступе.

Ниже приведена иллюстрация, как Рекомендации попадают в итоговый ответ на примере Рекомендации с типом reason. Иллюстрация взята из статьи от Axiomatics.

В зависимости от места применения Решения о доступе Рекомендации могут быть проигнорированы полностью или частично. Например, API сервера не учитывает Рекомендацию Перенаправление, т. к. она имеет смысл только для интерфейса.

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