Глава 11. Роль и разрешение

11.1 Роль и разрешение — не одно и то же

В простой модели доступа часто используется цепочка:

User → Role → Permission

Она полезна как первый уровень абстракции.

Например:

Alice → Manager → READ, UPDATE

Из такой записи кажется, что роль непосредственно содержит права пользователя.

Но в более сложной модели этого недостаточно.

Нужно различать как минимум два понятия:

роль отвечает на вопрос:

какое положение или отношение субъекта в данной модели имеет значение для доступа?

разрешение отвечает на вопрос:

какое действие допускается этой моделью?

Роль — это основание.

Permission — это описание допустимого действия.

Они участвуют в одном решении, но выполняют разные функции.

11.2 Permission описывает действие

Начнём с permission.

Permission — это формализованное право выполнить определённое действие.

Например:

READ
UPDATE
APPROVE
CLOSE

Но само по себе наличие READ ещё не означает:

пользователь может читать любой объект.

Permission должно быть применено к конкретному субъекту, объекту и контексту.

Поэтому:

Permission = READ

и

Can(Alice, READ, Document A)

— совершенно разные утверждения.

Первое описывает допустимое действие.

Второе является результатом конкретного решения о доступе.

11.3 Permission не определяет объект

Предположим, у пользователя есть READ.

Это не означает, что он может читать:

Document A
Document B
Document C

Право должно быть сопоставлено с объектом.

Например:

Alice
  │
  └── READ
        │
        ├── Document A
        ├── Document B
        └── Document C

Какие из этих объектов действительно доступны — определяется другими фактами.

Поэтому permission не является ACL объекта и не является публикацией объекта.

Оно лишь определяет допустимый тип действия.

11.4 Роль группирует разрешения

Роль нужна для того, чтобы не назначать каждое разрешение отдельно каждому субъекту.

Например:

Manager
   ├── READ
   ├── UPDATE
   └── APPROVE

Роль объединяет набор permission.

Это делает модель управляемой.

Но здесь появляется важное ограничение:

роль определяет набор возможностей, но сама по себе не определяет, над какими объектами эти возможности действуют.

Например:

Alice → Manager

ещё не говорит:

Alice → UPDATE → Document A

Необходимо знать, где действует роль и какие объекты связаны с этой областью.

11.5 Роль всегда должна рассматриваться вместе с областью

Сравним:

Alice → Manager

и:

Alice → Manager → Project P

Это разные утверждения.

Во втором случае роль ограничена конкретной областью.

У Alice может быть:

Manager → Project P
Reviewer → Project Q

При этом набор разрешений для ролей может различаться.

Даже если одна и та же роль существует в разных областях, правила её применения могут зависеть от области.

Поэтому роль без области часто является только неполным описанием отношения.

11.6 Роль — это отношение субъекта к модели

Теперь можно связать предыдущую главу с текущей.

Мы уже знаем, что субъект может иметь множество отношений.

Роль — один из видов таких отношений.

Например:

Alice → role → Manager → Project P

Здесь:

• Alice — субъект;

• Manager — роль;

• Project P — область действия;

• набор permission — значение роли для модели доступа.

То есть роль не заменяет отношение.

Она сама является частью отношения.

11.7 Роль не является разрешением

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

Предположим:

Manager → READ + UPDATE

Позже политика системы меняется:

Manager → READ

Роль осталась прежней.

Изменилось значение этой роли в модели разрешений.

Поэтому:

Role ≠ Permission

Роль определяет положение субъекта в модели.

Permission определяет допустимое действие.

Связь между ними задаётся правилами модели.

11.8 Один permission может входить в разные роли

Например:

Manager → READ, UPDATE, APPROVE
Reviewer → READ, APPROVE
Auditor → READ

READ присутствует во всех трёх ролях.

Следовательно, permission не идентифицирует роль.

Оно является самостоятельным элементом модели.

Это позволяет изменять состав ролей независимо от самих действий.

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

Роль является частью модели, а не персональным свойством конкретного пользователя.

Например:

Alice → Manager → Project P
Bob   → Manager → Project P
Carol → Manager → Project Q

Здесь одна и та же роль назначена разным субъектам.

Но область действия отношений различается.

Поэтому одинаковая роль не означает одинаковый доступ ко всем объектам.

11.10 Одна роль может иметь разные результаты

Пусть Alice имеет роль Manager в проекте P.

Объект Document A опубликован в P.

Другой объект Document B опубликован в Q.

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

Alice → Manager → Project P
Document A → published in → Project P

Alice → Manager → Project P
Document B → published in → Project Q

В первом случае отношения пересекаются по области.

Во втором — нет.

Следовательно, роль сама по себе не определяет результат.

Она становится основанием доступа только вместе с областью и отношениями объекта.

11.11 Permission тоже может иметь область применения

В некоторых моделях permission назначается не просто субъекту, а субъекту в определённой области.

Тогда фактически возникает конструкция:

Subject
   +
Permission
   +
Area

Например:

Alice → READ → Project P

Это уже существенно точнее, чем:

Alice → READ

Потому что второе утверждение выглядит глобальным.

Первое задаёт границу действия разрешения.

Но даже такая конструкция ещё не гарантирует доступ к конкретному объекту.

Нужно определить, как объект связан с этой областью.

11.12 Permission не заменяет публикацию

Пусть:

Alice → READ → Project P

и:

Document A → published in → Project P

Тогда эти два факта могут быть использованы правилом для получения:

Alice → READ → Document A

Но если объект вообще не связан с Project P, одного permission недостаточно.

Это важное разделение:

Permission
   ↓
что разрешено

Publication
   ↓
где объект доступен для рассмотрения

Rule
   ↓
как эти факты связываются

Ни один из этих элементов не заменяет остальные.

11.13 Permission не заменяет отношение

Предположим, пользователю назначено:

READ

Но модель требует, чтобы пользователь был связан с объектом через определённую область.

Тогда:

READ

без соответствующего отношения не даёт доступа.

Это особенно важно в системах, где один permission используется для множества объектов.

Permission отвечает на вопрос:

какое действие допустимо?

Отношение отвечает на другой вопрос:

почему этот субъект вообще участвует в данном контексте?

11.14 Роль может быть только одним из оснований

У пользователя может существовать несколько оснований:

Alice
 ├── owner → Document A
 ├── role → Project P
 ├── member → Group G
 └── delegated access → Document A

Роль является только одним из них.

Она не должна автоматически поглощать ownership, membership или delegation.

Иначе разные отношения начинают превращаться в один универсальный механизм:

User → Role → Everything

Такой механизм удобен только пока модель проста.

При появлении разных типов отношений он начинает скрывать происхождение права.

11.15 Несколько ролей могут дать одно permission

Пусть:

Manager → UPDATE
Editor  → UPDATE

Alice одновременно имеет обе роли.

Это не означает, что у неё существует два разных UPDATE.

Для конкретного решения эффективный набор разрешений обычно рассматривается как множество возможностей.

Например:

Manager ──┐
          ├── UPDATE
Editor  ──┘

Два основания приводят к одному эффективному permission.

Это важная идея для следующей главы: эффективное разрешение является результатом объединения оснований, а не копией каждого из них.

11.16 Несколько ролей могут давать разные permission

Теперь:

Manager → UPDATE
Reviewer → APPROVE

Alice имеет обе роли.

Тогда эффективный набор возможностей может быть:

READ
UPDATE
APPROVE

если READ также предоставляется одной из ролей или другим основанием.

Таким образом, роли могут агрегироваться.

Но агрегация сама по себе не отвечает на вопрос, к каким объектам применяются полученные возможности.

Для этого снова нужны области и отношения объектов.

11.17 Permission может быть ограничено объектом

Даже если субъект имеет:

UPDATE

объект может ограничивать применение этого права.

Например, объект может быть доступен пользователю только для чтения.

Тогда модель должна учитывать одновременно:

Subject Permission
        ∩
Object Constraint
        ∩
Action

В результате:

UPDATE ∩ READ_ONLY = READ

или, если модель устроена иначе, UPDATE просто не проходит проверку.

Конкретный механизм зависит от системы.

Принцип остаётся общим:

permission субъекта и допустимость действия над объектом — не одно и то же.

11.18 Permission имеет смысл только в отношении действия

Нельзя говорить о permission вообще, не определив, какое действие оно представляет.

Например:

READ
UPDATE
APPROVE

— это разные возможности.

Наличие READ не означает UPDATE.

Наличие APPROVE не означает CLOSE.

Поэтому разрешение должно быть связано с конкретным действием.

Это позволяет формализовать проверку:

Can(Subject, Action, Object)

где Action сопоставляется с требуемым permission.

11.19 Роль и permission находятся на разных уровнях

Теперь можно провести границу.

SUBJECT
   │
   ▼
RELATION / ROLE
   │
   ▼
PERMISSION
   │
   ▼
ACTION

Но эта схема всё ещё неполна.

Не хватает объекта и области:

Subject
   │
   ├── Role
   │      │
   │      └── Permission
   │
   └── other relations
          │
          ▼
       Area

Object
   │
   └── Publication / other relations
          │
          ▼
        Area

Только сопоставив эти элементы, можно перейти к конкретному решению.

11.20 Почему старая модель всё ещё полезна

После всей этой критики может показаться, что модель User → Role → Permission нужно выбросить.

Нет.

Она остаётся полезной.

Она хорошо решает задачу определения:

какие действия в принципе может выполнять субъект определённого типа или положения?

Например:

Manager → READ, UPDATE, APPROVE

Это компактный и удобный способ описать базовый набор возможностей.

Проблема возникает только тогда, когда эту модель пытаются использовать как полное описание доступа к конкретным объектам.

11.21 От роли к эффективному разрешению

Теперь у нас есть все необходимые элементы для следующего шага.

Роль связывает субъекта с набором permission.

Permission описывает допустимое действие.

Область ограничивает применение отношения.

Публикация связывает объект с областью.

Другие отношения могут создавать дополнительные основания.

Получается:

Subject
   │
   ├── Role ──→ Permission
   │
   ├── Membership
   │
   ├── Ownership
   │
   └── Other Relations
             │
             ▼
          Relevant
           Context
             │
             ▼
        Object Relations
             │
             ▼
            Rules
             │
             ▼
     Effective Permission

Здесь впервые становится видна разница между назначенным и эффективным разрешением.

Назначенное разрешение — это факт модели.

Эффективное разрешение — результат его применения к конкретной ситуации.

11.22 Назначенное право не равно эффективному праву

Пусть Alice имеет:

Manager → UPDATE

Это означает, что UPDATE входит в набор возможностей роли.

Но для конкретного объекта ещё нужно установить:

1. действует ли роль в релевантной области;

2. связан ли объект с этой областью;

3. нет ли дополнительных ограничений;

4. относится ли запрошенное действие к данному permission.

Только после этого можно получить:

Can(Alice, UPDATE, Document A)

Поэтому полезно различать:

Assigned Permission

и

Effective Permission

Первое — исходный факт.

Второе — результат модели.

11.23 Это не только вопрос ролей

На этом этапе легко снова сделать слишком простой вывод:

значит, нужно просто правильно вычислить роли.

Но роль — лишь одно из оснований.

Эффективное разрешение может зависеть от:

• роли;

• членства;

• владения;

• публикации;

• делегирования;

• иерархии;

• ограничений объекта;

• других отношений.

Поэтому архитектура не должна превращать все основания в роли только ради удобства вычисления.

Если разные отношения имеют разный смысл, этот смысл должен сохраняться в модели.

11.24 Что теперь можно формализовать

Мы можем записать:

Permissions(Subject, Context)
    = правила, определяющие набор допустимых действий

Но окончательный вопрос всё ещё звучит иначе:

Can(Subject, Action, Object)?

Чтобы ответить на него, нужно объединить:

Subject
+
Action
+
Object
+
Relations
+
Areas
+
Permissions
+
Constraints

И только затем определить эффективное разрешение.

То есть permission является не финальным ответом, а одним из элементов вычисления ответа.

11.25 Главный вывод

Роль и permission решают разные задачи.

Роль описывает положение или тип отношения субъекта в модели доступа.

Permission описывает допустимое действие.

Роль может предоставлять несколько permission.

Один permission может входить в несколько ролей.

Один субъект может иметь несколько ролей в разных областях.

Но ни роль, ни permission сами по себе не определяют доступ к конкретному объекту.

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

Поэтому старая конструкция:

User → Role → Permission

не исчезает.

Она становится частью более широкой модели:

Subject
   +
Roles / Other Relations
   +
Permissions
   +
Areas
   +
Object Relations
   +
Rules
   ↓
Effective Permission

Именно эффективное разрешение, а не назначенная роль или отдельный permission, является непосредственным результатом модели доступа.

Следующая глава отвечает на главный практический вопрос:

как из нескольких отношений, ролей и разрешений получается одно эффективное разрешение для конкретного действия над конкретным объектом?