Глава 9. Область действия отношения

9.1 Одного отношения недостаточно

В предыдущей главе мы рассмотрели публикацию объекта.

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

Но сама по себе такая связь ещё не отвечает на вопрос о доступе.

Пусть объект Document A опубликован в области Project P.

Из этого пока нельзя сделать вывод:

любой пользователь, связанный с Project P, может читать Document A.

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

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

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

9.2 Что означает область действия отношения

Возьмём отношение:

Subject → Relation → Object

У отношения может быть область, в которой оно действительно.

Например:

User A → member of → Project P

Здесь область определяется самим проектом.

Но возможна и другая ситуация:

User A → role → Project P

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

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

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

область отвечает на вопрос, где действует отношение; само отношение отвечает на вопрос, что именно оно означает.

9.3 Область не является свойством субъекта

Нельзя сказать, что пользователь просто «имеет доступ к проекту».

Такое утверждение слишком грубое.

У одного и того же пользователя могут существовать разные отношения:

User A → member → Project P

User A → role → Project P

User A → member → Group G

User A → owner → Object X

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

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

Субъект не находится постоянно в одном единственном контексте доступа.

Контекст определяется конкретным запросом и конкретными отношениями, которые для него релевантны.

9.4 Область не является свойством объекта

По той же причине нельзя считать, что объект просто «принадлежит области».

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

Например:

Object A → published in → Project P

Object A → published in → Group G

Object A → owned by → User B

Здесь появляются три разных отношения и потенциально три разных основания для доступа.

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

Объекту пришлось бы иметь один scope.

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

9.5 Одна область — разные отношения

Рассмотрим проект P.

В его пределах могут существовать отношения:

• пользователь является участником проекта;

• пользователь имеет роль в проекте;

• объект опубликован в проекте;

• пользователь получил делегированное право в проекте.

Все они используют одну область, но не становятся одним отношением.

Это принципиально.

Если область сама начинает определять смысл доступа, модель быстро превращается в набор специальных исключений:

если пользователь находится в этой области, разрешить действие.

Но тогда теряется информация о том, почему пользователь оказался в области и какое именно отношение между ним и областью существует.

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

9.6 Одно отношение — несколько областей

Обратная ситуация тоже возможна.

Одно логическое отношение может распространяться на несколько областей.

Например, роль пользователя может быть назначена:

• для всей организации;

• для конкретного проекта;

• для конкретной группы.

Смысл отношения один — пользователь получает определённую роль, — но область действия различается.

Получается:

Role(User A, R, Company C)

и

Role(User A, R, Project P)

и

Role(User A, R, Group G).

Это не три разных пользователя и не три разных роли.

Это однотипные отношения с разной областью действия.

9.7 Область может быть иерархической

Области не обязательно образуют плоский список.

Они могут находиться в иерархии:

Company
   │
   ├── Project
   │      │
   │      ├── Group
   │      └── Group
   │
   └── Project

Тогда возникает дополнительный вопрос:

распространяется ли отношение из более широкой области на более узкую?

Например, если пользователь имеет определённое отношение к организации, означает ли это автоматически наличие такого же отношения к каждому проекту внутри неё?

Ответ не может быть универсальным.

Иногда — да.

Иногда — нет.

Это уже правило модели.

Сама иерархия области ничего автоматически не разрешает.

9.8 Иерархия области и наследование — разные вещи

Это различие легко потерять.

Пусть:

Project P ∈ Company C

Это означает, что проект находится внутри организации.

Но из этого ещё не следует:

Relation(User, Company C) ⇒ Relation(User, Project P).

Для такого перехода должно существовать отдельное правило наследования.

И наоборот:

Relation(User, Project P)

не обязательно означает наличие отношения к Company C.

Иерархия описывает структуру областей.

Наследование описывает правила переноса отношений между ними.

Это разные элементы модели.

9.9 Область может ограничивать действие, но не создавать его

Представим разрешение:

READ

и отношение пользователя к проекту.

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

Но сама область P не создаёт право READ.

Она только ограничивает место, в котором соответствующее основание может быть применено.

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

Relation
    ↓
Area
    ↓
Rule
    ↓
Effective Permission

Область является частью входных данных правила.

Она не является результатом правила.

9.10 Область публикации и область разрешения могут совпадать

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

Например:

Object A
   │
   └── published in → Project P

User B
   │
   └── role in → Project P

Если правила модели связывают эти два отношения, из них может возникнуть эффективное разрешение:

User B
   ↓
relation with Project P
   ↓
Object A published in Project P
   ↓
READ

Но это не означает, что публикация сама является разрешением.

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

9.11 Области разных отношений могут пересекаться

Не все отношения должны использовать одну и ту же область.

Например:

User A → role → Project P
Object B → published in → Group G
Group G → belongs to → Project P

Теперь появляется цепочка отношений.

Пользователь связан с проектом.

Объект опубликован в группе.

Группа связана с проектом.

Можно ли через эту цепочку получить доступ к объекту?

Это уже вопрос правила.

Сама цепочка ещё ничего не разрешает.

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

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

9.12 Область отношения может быть частью ограничения

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

Например, пользователь может иметь право UPDATE в проекте P, но не иметь его в проекте Q.

То есть одно и то же разрешение:

UPDATE

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

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

Более точной становится конструкция:

Subject
    +
Action
    +
Object
    +
Relevant Relations
    +
Their Areas
    ↓
Effective Permission

9.13 Несколько областей не означают несколько контекстов

Здесь легко сделать ещё одну ошибку.

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

Контекст формируется для конкретного запроса:

Can(User A, READ, Object B)?

Для ответа на него могут оказаться релевантными сразу несколько отношений:

User A → role → Project P
User A → member → Group G
Object B → published in → Project P
Object B → published in → Group G

Эти факты вместе участвуют в одном решении.

Поэтому несколько областей являются частью контекста, но не определяют его структуру полностью.

9.14 Область не обязана быть физическим контейнером

Область действия отношения может совпадать с физическим контейнером, но это не обязательно.

Например, документы проекта могут физически храниться в одной таблице:

documents

а логически относиться к разным проектам.

И наоборот, документы одного проекта могут физически храниться в разных таблицах, базах или хранилищах.

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

физическое размещение данных и область действия отношения — разные уровни модели.

Это особенно важно для архитектур, где физическое хранение меняется независимо от логической модели доступа.

9.15 Область действия может изменяться

Отношение не обязательно существует с одной областью действия навсегда.

Пользователь может получить роль на уровне организации, затем отдельную роль в проекте.

Объект может быть опубликован в проекте, а затем публикация может быть отозвана.

Группа может быть перемещена внутри иерархии.

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

Может измениться только отношение или его область действия.

А значит, изменяется и контекст последующих запросов.

Это один из ключевых моментов всей модели:

изменение доступа может происходить без изменения самого объекта.

9.16 Область действия — одно из измерений контекста

Теперь можно собрать предыдущие главы в одну конструкцию.

У нас есть:

• субъект;

• действие;

• объект;

• отношения между ними и связанными сущностями;

• основания доступа;

• области действия этих отношений;

• дополнительные ограничения и условия.

Из этого набора формируется контекст конкретного решения.

Поэтому:

Scope ⊂ Relation

в том смысле, что область может быть характеристикой отношения,

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

Scope ⊂ Context

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

При этом:

Context ≠ Scope

потому что контекст содержит гораздо больше информации.

9.17 Отношение связывает, область ограничивает

Теперь можно сформулировать более точное разделение.

Отношение говорит:

что связывает эти сущности.

Область действия говорит:

где действует это отношение.

Правило говорит:

какое значение имеет это отношение для конкретного действия.

Эффективное разрешение говорит:

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

Например:

User A
   │
   └── role ──────────────→ Project P
                              │
Object B
   │                          │
   └── published in ──────────┘

Здесь обе связи используют проект как область.

Но право READ возникает не из самого существования Project P.

Оно возникает из правила, которое интерпретирует эти отношения.

9.18 Что теперь известно о контексте

После предыдущих глав модель стала существенно конкретнее.

Мы начали с объекта и фактов вокруг него.

Затем выделили основания доступа.

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

Теперь мы можем описать следующий уровень:

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

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

Context = Project P

Более точная модель выглядит так:

Context =
    Subject
    +
Action
    +
Object
    +
Relevant Facts
    +
Relevant Relations
    +
Areas of those Relations
    +
Rules and Constraints

Это не означает, что все перечисленные элементы обязательно хранятся вместе.

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

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

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

Она не является пользователем, объектом или контекстом.

Она является характеристикой отношения, показывающей, где это отношение действует.

Одно отношение может иметь разные области.

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

Иерархия областей сама по себе не означает наследование отношений.

Публикация связывает объект с областью, но не превращает область в разрешение.

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

User
Role
Permission
Scope

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

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

Этим и занимается следующая часть книги.