Глава 12. Как возникает эффективное разрешение

12.1. Назначенное и эффективное разрешение

Ранее мы различили отношение и разрешение.

Теперь нужно провести ещё одно различие.

В системе может существовать исходный факт:

Role R has permission READ

Это назначенное разрешение.

Но пользователь получает его не просто потому, что где-то существует такая запись.

Нужно определить:

• относится ли роль к этому субъекту;

• действует ли она в рассматриваемой области;

• относится ли область к данному объекту;

• применимо ли правило к конкретному действию;

• существуют ли ограничения.

Результат этих вычислений — эффективное разрешение.

Оно отвечает уже не на вопрос:

Какие права вообще существуют?

а на вопрос:

Какие права действуют для данного субъекта в отношении данного объекта в данном контексте?

12.2. Эффективное разрешение является производным фактом

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

Исходный факт может выглядеть так:

User U has Role R

Другой:

Role R has READ permission

Третий:

Role R applies to Project P

А результат:

User U has effective READ permission
in Project P

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

Он получен из других фактов и правил.

Поэтому:

Source facts ≠ Effective permissions

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

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

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

Например:

Owner
Role in Project
Group membership
Publication
Delegation

Они отвечают на вопрос:

Почему субъект вообще может участвовать в данном решении?

Эффективное разрешение отвечает на другой вопрос:

Какое действие в результате разрешено?

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

Access grounds
        ↓
Rules
        ↓
Effective permission

Основание не равно праву.

Право не равно окончательному решению.

12.4. Контекст определяет применимость правил

Пусть существует правило:

Project role → READ

Само наличие такого правила ничего не говорит о конкретном запросе.

Нужно определить его контекст:

Subject = User A
Action  = READ
Object  = Document X

и релевантные отношения:

User A → Role in Project P
Document X → published in Project P

Тогда правило может быть применимо.

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

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

12.5. Универсальная схема вычисления

На концептуальном уровне процесс можно выразить следующим образом:

function effectivePermission(context):
    applicableRules = findApplicableRules(context)
    return evaluate(applicableRules, context)

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

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

Важна последовательность:

Context
   ↓
Applicable rules
   ↓
Evaluation
   ↓
Effective permission

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

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

Универсального оператора combine() здесь нет.

12.6. Эффективное разрешение не равно ALLOW

Даже после получения эффективного разрешения решение ещё не обязательно принято.

Например:

Effective permission = READ
Requested action = UPDATE

Тогда право существует, но запрошенное действие ему не соответствует.

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

Effective permission

и

Access decision

Схема становится такой:

Facts
  ↓
Context
  ↓
Access grounds
  ↓
Rules
  ↓
Effective permission
  ↓
Check requested action
  ↓
ALLOW / DENY

12.7. Почему эффективное разрешение удобно материализовать

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

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

Например:

Role assignments
      ↓
Group/project relations
      ↓
Security rules
      ↓
Effective permissions

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

Это не меняет смысл модели.

Источник истины остаётся в исходных фактах и правилах.

Материализованное эффективное разрешение — производное представление.

12.8. Главное различие

Таким образом, в модели существуют как минимум четыре разных уровня:

Факт
  ↓
Отношение
  ↓
Контекст и основания
  ↓
Эффективное разрешение

А уже после этого появляется решение:

Effective permission
        ↓
Requested action?
        ↓
ALLOW / DENY

Это различие понадобится дальше.

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

Этому посвящена следующая глава.