Глава 7. Основания доступа

Теперь у нас есть три уровня:

Subject → Action → Object

и:

Facts + Relations

Но пока отсутствует главное связующее звено.

Почему некоторый факт должен приводить к разрешению?

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

7.1. Одно действие может иметь несколько оснований

Предположим, Alice хочет прочитать документ D.

У системы может быть несколько независимых причин предоставить ей доступ:

Alice owns D

или:

Alice is member of Group G
G has access to D

или:

Alice has a role in Project P
D is published in P

Результат может быть одним:

Alice → READ → D

Но путь к этому результату различается.

Поэтому важно разделять:

право и основание, по которому это право возникло.

7.2. Создатель — основание, а не универсальное право

Если Alice создала D:

Alice → created → D

это факт происхождения объекта.

Некоторые системы могут использовать его как основание доступа.

Например:

создатель может редактировать объект до его передачи.

Но это не универсальное свойство понятия «создатель».

После передачи объекта:

Alice → created → D
Bob   → owns → D

Alice остаётся создателем.

Если правило владения определяет текущий доступ, владельцем уже является Bob.

Поэтому:

Creator ≠ Owner

и факт создания не должен автоматически подменяться отношением владения.

7.3. Владелец — тоже основание, а не готовое разрешение

Если:

Bob → owns → D

система может определить, что Bob имеет определённые права.

Например:

Bob → READ → D

Bob → UPDATE → D

Но набор этих прав зависит от правил системы.

В другой модели владелец может иметь право изменять объект, но не иметь права утверждать его.

Следовательно:

Owner → Permission

это не универсальная истина.

Правильнее:

Owner relation
      ↓
правило системы
      ↓
определённые permissions

7.4. Роль — другое основание

Роль отвечает на другой вопрос.

Например:

Alice → Editor

а роль Editor определяет:

Editor → UPDATE

Но этого всё ещё недостаточно для конкретного объекта.

Нужно знать, где действует эта роль.

Alice может быть редактором одного проекта и не иметь той же роли в другом.

Поэтому роль становится частью более сложного отношения:

Alice
  ↓
Role: Editor
  ↓
Project P

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

7.5. Членство в группе тоже не является разрешением

Рассмотрим:

Alice → member_of → G

Само по себе членство не говорит, что Alice может читать любой объект, связанный с G.

Нужно ещё знать, какое значение имеет группа для конкретного объекта.

Например:

Alice ∈ G
G → access → D

может дать:

Alice → READ → D.

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

Поэтому:

Membership ≠ Permission

Членство — это факт.

Право — результат применения правил к этому факту.

7.6. Проект также не является разрешением

Аналогично:

Alice → role in → Project P
D    → published in → P

может создать основание для доступа Alice к D.

Но само участие в проекте не означает автоматически доступ ко всем объектам проекта.

Это зависит от модели.

Проект определяет некоторую структуру отношений.

Правила определяют, какие права из неё следуют.

7.7. Публикация отвечает на другой вопрос

Публикация особенно хорошо показывает разницу между фактом и правом.

Например:

D → published → Project P

Этот факт говорит, что объект опубликован в определённой области.

Но он не отвечает сам по себе на вопрос:

Может ли Alice выполнить UPDATE над D?

Для этого нужно учитывать ещё и отношения Alice с этой областью, соответствующие разрешения и ограничения самого действия.

Поэтому:

Publication ≠ Permission

Публикация определяет видимость или область, в которой объект может быть доступен.

Она не является универсальным разрешением на любые действия.

7.8. Несколько оснований могут дать одно эффективное право

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

Alice owns D

и одновременно:

Alice ∈ G
G has READ access to D

И ещё:

Alice has READ permission in Project P
D is published in P

Три независимых основания приводят к одному результату:

Alice → READ → D

Это важно по двум причинам.

Во-первых, удаление одного основания не обязательно лишает пользователя права.

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

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

Access Grounds
       ↓
Effective Permission

7.9. Эффективное разрешение — результат, а не исходный факт

Пусть исходные данные таковы:

Alice ∈ G
G has access to D

А правило системы говорит:

член группы получает READ для опубликованных группе объектов.

Тогда:

Alice → READ → D

является эффективным разрешением.

Оно может быть вычислено из исходных отношений.

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

7.10. Основания могут конфликтовать

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

Например:

Alice owns D

может давать право UPDATE.

Но:

D is closed

может запрещать UPDATE.

Тогда одного основания недостаточно.

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

Основание доступа
        +
Ограничение объекта
        +
Требуемое действие

В результате эффективное право определяется не просто наличием основания, а правилами их совместного применения.

7.11. Право зависит от действия

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

Например, владелец может:

READ

и:

UPDATE

но не:

APPROVE.

Или член проекта может:

READ

но не:

CLOSE.

Поэтому нельзя говорить:

«У Alice есть доступ к D».

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

Точнее:

Can(Alice, READ, D)

или:

Can(Alice, UPDATE, D)

7.12. Основание доступа не обязано быть прямым

Иногда между субъектом и объектом находится цепочка отношений:

Alice
  ↓
member of
  ↓
Group G
  ↓
published to
  ↓
Document D

В этом случае Alice не имеет прямой связи READ с D.

Она получает право через цепочку.

Именно такие модели делают авторизацию отношенческой: результат зависит не от одного свойства субъекта, а от структуры отношений.

7.13. Одно отношение может участвовать в разных решениях

Факт:

Alice ∈ G

может быть использован сразу в нескольких правилах.

Например:

• для чтения документов группы;

• для доступа к проекту;

• для определения области видимости;

• для других операций.

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

Оно является исходным фактом, который разные правила могут использовать по-разному.

7.14. Отношения имеют разный смысл

В реальной модели могут одновременно существовать:

created
owns
member_of
role_in
published_in
access
delegated_to

Нельзя объединить их в универсальное:

related_to.

Такое объединение уничтожило бы семантику.

Создатель — не владелец.

Владелец — не участник группы.

Участник группы — не обязательно редактор.

Редактор — не обязательно утверждающий.

Публикация — не право изменения.

Именно различия между отношениями позволяют построить точную модель.

7.15. Основания доступа образуют вход модели разрешений

Теперь можно представить более полную цепочку:

Предметные факты
       ↓
Отношения
       ↓
Основания доступа
       ↓
Правила
       ↓
Эффективное разрешение

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

Это скорее роль, которую определённый факт играет в конкретном правиле.

Например:

Alice owns D

является обычным фактом.

Но в правиле:

владелец может UPDATE

тот же факт становится основанием для UPDATE.

7.16. Почему это важно для архитектуры

Если система хранит только конечные permissions, теряется информация о том, почему пользователь получил право.

Если система хранит только отношения, приходится вычислять права непосредственно во время каждого запроса.

Оба подхода имеют последствия.

Поэтому в сложных системах полезно разделять:

Исходные факты
       ↓
Производные security-факты
       ↓
Эффективные permissions

Так модель остаётся выраженной через отношения, а механизм проверки может работать с заранее подготовленным результатом.

7.17. Что мы теперь знаем о контексте

После глав 5–7 модель стала существенно конкретнее.

Для запроса:

Can(Alice, UPDATE, D)

мы можем рассматривать:

Subject
  Alice

Action
  UPDATE

Object
  D

Relevant facts
  owner
  membership
  role
  publication
  state
  ...

Некоторые из этих фактов могут стать основаниями доступа.

Некоторые — ограничениями.

Некоторые могут вообще оказаться нерелевантными.

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

7.18. Главный вывод

Доступ редко возникает из одного свойства пользователя или объекта.

Он может иметь несколько оснований:

• владение;

• создание;

• роль;

• членство;

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

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

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

Но каждое из них является фактом или отношением, а не готовым разрешением.

Поэтому:

Fact ≠ Permission

Relation ≠ Permission

Role ≠ Access to Object

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

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