Кратко

  • RFC 9967, одним из соавторов которого была Nancy Cam-Winget, определяет события безопасности SCIM, передаваемые в SET. SET сообщает, что у поставщика услуг SCIM уже произошло изменение состояния; каждый Event Receiver выбирает последующее локальное действие, а не читает сообщение как команду.
  • Set-Txn связывает асинхронный ответ 202 Accepted с заявлением txn в последующем SET. Ни эта связь, ни сохранение события, ни форма его полезной нагрузки не подтверждают, что получатель сопоставил ресурс, сверил модель, применил политику или достиг того же состояния.

В асинхронной автоматизации идентификации слово «завершено» особенно легко произнести и особенно трудно обосновать. Запрос получает 202 Accepted, затем появляется SET с ожидаемым txn; возникает желание назвать всю цепочку синхронизацией. RFC 9967 доказывает более узкую, но полезную вещь: поставщик принял асинхронную работу и позднее выпустил событие, которое клиент может с ней соотнести. Он не доказывает, как каждый принимающий домен истолковал это событие и какой эффект возник в его системе.

RFC 9967, System for Cross-Domain Identity Management (SCIM) Profile for Security Event Tokens (SETs), определяет SET как информацию об уже произошедшем изменении состояния у поставщика SCIM. Это уменьшает потребность зависимых систем бесконечно опрашивать поставщика. Но документ намеренно не превращает эту информацию в предписание. Каждый получатель сам определяет наилучшее дальнейшее действие в своём контексте; в качестве примера RFC называет согласование различий схем и типов ресурсов между доменами.

Это ограничение соответствует реальной эксплуатации. Два домена могут пользоваться разными идентификаторами, несовпадающими атрибутами или разной семантикой жизненного цикла. Получатель может сопоставить URI события с локальной записью, а может и не суметь. Если URI не удаётся сопоставить, RFC разрешает обратиться к заранее согласованному базовому URI поставщика с относительным URI и выполнить SCIM GET. Можно также сохранить событие для восстановления и передать решение другому локальному процессу. Изменение у поставщика и сверка у получателя — разные наблюдаемые факты.

Заголовок корреляции столь же ограничен. Для асинхронного ответа SCIM RFC требует 202 Accepted без тела и Set-Txn; его значение должно совпасть с txn в последующем SET, чтобы клиент мог искать соответствующее событие завершения. Это хорошая аудиторская связка между принятым запросом и поздним заявлением поставщика. Но это не универсальная квитанция. RFC различает txn и jti: jti идентифицирует отдельный токен, тогда как один txn может сохраняться при повторной передаче или публикации нескольких SET нескольким получателям. Совпадение говорит, какая транзакция была соотнесена, а не какой получатель сошёлся с каким состоянием.

Форма полезной нагрузки также не допускает лишних выводов. Должен присутствовать ровно один из data или attributes. data даёт представление ресурса после транзакции, attributes перечисляет созданные или изменённые атрибуты. Даже полное представление может потребовать преобразования схемы и локального решения. Перечень атрибутов может потребовать повторного получения ресурса. Ни одна форма не утверждает, что получатель принял данные, исполнил решение о доступе или теперь хранит текущее состояние поставщика.

Сохранность — иной вид доказательства. RFC требует, чтобы получатели прямо или косвенно сохраняли события для собственных нужд восстановления до подтверждения получения. Это позволяет восстановить долгоживущий поток после краткого сбоя доставки или повтора. Надёжный входящий журнал честно доказывает сохранение события; он не доказывает сопоставление, действие или наблюдаемое изменение локального состояния.

Здесь нужна дисциплина Running-Code Primacy: технический артефакт должен доказывать только то изменение, которое он действительно показывает. Принятый запрос, Set-Txn, txn, jti, получение SET, сохранение, локальное сопоставление, ответ на обратный запрос, правило, действие и наблюдаемое состояние — отдельные связки доказательств. Если назвать всё это «синхронизацией», исчезнет именно тот разрыв, который позже потребуется расследовать.

Сильный подход не в недоверии к RFC 9967 и не в централизации решения. Поставщик отвечает за своё заявление об изменении; получатель — за толкование в собственной модели; организация, несущая последствия, задаёт порог доказательств для слова «сверено». Стандарт расширяет проверяемые факты, но не выдаёт событие за решение чужого домена.

Источники