要約

  • Nancy Cam-Wingetらが共同執筆したRFC 9967は、SCIMのセキュリティイベントをSETで運ぶ。SETはSCIMサービス提供者で状態変化が起きたことを伝え、Event Receiverはそれを命令として扱わず、自身の文脈で次の行為を決める。
  • Set-Txnは非同期の202 Acceptedと、後続SETのtxnクレームを結び付ける。相関、イベント保存、リソース表現のいずれも、受信側がリソースを照合し、ローカル処理を行い、同じ現在状態へ到達した受領証にはならない。

非同期のアイデンティティ運用で最も誤解を招く語は「完了」かもしれない。要求が202 Acceptedを受け、後から同じtxnを持つSETが見つかる。そこで画面に「同期済み」と表示したくなる。しかしRFC 9967が確立するのは、提供者が非同期処理を受け付け、その後に相関可能なイベントを発行したという限定された事実である。どの受信ドメインが何を理解し、どの効果を生んだかまでは確立しない。

RFC 9967 System for Cross-Domain Identity Management (SCIM) Profile for Security Event Tokens (SETs) は、SETをSCIMサービス提供者で既に起きた状態変化の情報と位置付ける。依存先が盲目的にポーリングし続けずに済む点で有益である。一方、仕様はSETをコマンドとして読むことを拒む。各Event Receiverが自分の文脈で最良の後続行為を決めるのであり、文書はドメイン間のスキーマとリソース型の照合を例に挙げている。

この留保には運用上の理由がある。二つのドメインは異なる識別子、異なる属性体系、異なるライフサイクル意味論を持ち得る。受信側がイベントURIをローカルの記録に結び付けられることもあれば、できないこともある。URIを一致させられない場合、RFCは事前合意したサービス提供者のベースURIと相対URIでSCIM GETを行うことを許す。あるいは回復のためイベントだけを保持し、別のローカル工程へ判断を渡せる。提供者の変更と受信側の照合は、同じ事実ではない。

相関用のヘッダーも範囲が狭い。非同期SCIM応答には本文なしの202 AcceptedとSet-Txnが必要であり、その値は後続SETのtxnに一致しなければならない。クライアントはこれで対応する完了イベントを探せる。これは受け付けられた要求と提供者による後日の声明を結ぶ、良い監査上の接点である。しかし世界全体の受領証ではない。RFCはtxnとjtiを分ける。jtiは個々のトークンを一意にし、同じtxnは再送や複数受信者への発行にまたがり得る。一致は何を相関したかを示すだけで、どの受信者がどこまで収束したかを示さない。

ペイロードの形も過大解釈を防ぐ。dataかattributesのいずれか一方だけが存在しなければならない。dataは取引後のリソース表現を与え、attributesは作成または変更された属性を列挙する。完全な表現にもスキーマ写像とローカル判断は必要である。属性の通知には取得し直しが必要なことがある。どちらも、受信側がデータを受理したこと、権限に関する決定を実施したこと、現在状態が提供者と一致したことを宣言しない。

永続化は別の証拠である。RFCは受信者に対し、受信確認の前に、ローカル回復の必要に応じてイベントを直接または間接に永続化することを求める。これは短い配送失敗や再試行から長期イベント流を回復可能にする。耐久的な受信箱はイベントを保持した証拠にはなるが、照合、実行、ローカル状態変更の証拠ではない。

ここではRunning-Code Primacyの姿勢が有効である。技術的な成果物には、実際に公開する状態変化だけを証明させるべきだ。要求受理、Set-Txn、txn、jti、SET受信、保存、ローカル一致、再照会結果、規則判断、行為、観測状態は別々の接点である。これらを「同期」という一語に畳むと、後で調査すべき断点が消える。

答えはRFC 9967を疑うことでも、決定を中央へ集めることでもない。提供者は変更の声明を担い、受信者は自分のモデル内での解釈を担い、影響を負う組織が照合済みと呼ぶための証拠閾値を定める。仕様は検証可能な事実を増やすが、イベントを他者の決定に見せかけない。

出典