Zusammenfassung

  • RFC 9967, an dem Nancy Cam-Winget mitgewirkt hat, definiert SCIM-Sicherheitsereignisse in SETs. Ein SET meldet eine beim SCIM-Service-Provider eingetretene Zustandsänderung; jeder Event Receiver bestimmt die passende lokale Folgehandlung, statt das Ereignis als Befehl zu lesen.
  • Set-Txn verbindet eine asynchrone Antwort 202 Accepted mit dem txn-Claim eines späteren SET. Weder diese Korrelation noch die Persistenz des Ereignisses oder seine Nutzlast beweisen, dass der Empfänger eine Ressource zugeordnet, sein Modell abgeglichen, eine Regel ausgeführt oder denselben Zustand erreicht hat.

In asynchronen Identitätsabläufen ist „abgeschlossen“ oft das bequemste und ungenaueste Etikett. Eine Anfrage erhält 202 Accepted, später erscheint ein SET mit dem erwarteten txn. Das zeigt eine nützliche, aber begrenzte Kette: Der Provider hat asynchrone Bearbeitung angenommen und später ein korrelierbares Ereignis veröffentlicht. Es zeigt nicht, wie jede Empfängerdomäne die Nachricht ausgelegt hat oder welche lokale Wirkung daraus entstand.

RFC 9967, System for Cross-Domain Identity Management (SCIM) Profile for Security Event Tokens (SETs), bezeichnet ein SET als Information über eine Zustandsänderung, die bei einem SCIM-Service-Provider erfolgt ist. Das ist sinnvoll, weil abhängige Systeme nicht fortlaufend blind abfragen müssen. Die Spezifikation verbietet jedoch die bequeme Umdeutung in einen Befehl. Jeder Empfänger entscheidet im eigenen Kontext über die beste Folgehandlung; als Beispiel nennt der RFC den Abgleich von Schema- und Ressourcentypunterschieden zwischen Domänen.

Diese Einschränkung entspricht dem Betrieb. Zwei Domänen können unterschiedliche Kennungen, nicht deckungsgleiche Attribute oder andere Lebenszyklusbegriffe verwenden. Ein Empfänger kann die URI eines Ereignisses einem lokalen Datensatz zuordnen, oder er kann daran scheitern. Kann er die URI nicht zuordnen, darf er nach RFC 9967 die vereinbarte SCIM-Basis-URI mit der relativen URI aufrufen und einen SCIM-GET ausführen. Er kann das Ereignis auch zur Wiederherstellung speichern und die Entscheidung einer lokalen Verarbeitung überlassen. Provider-Änderung und Empfänger-Abgleich sind nicht derselbe beobachtbare Sachverhalt.

Auch der Korrelationsheader beansprucht nicht mehr. Für eine asynchrone SCIM-Antwort verlangt der RFC 202 Accepted ohne Body sowie Set-Txn. Dessen Wert muss dem txn eines späteren SET entsprechen, damit der Client das zugehörige Abschlussereignis suchen kann. Das ist eine gute Audit-Verbindung zwischen angenommener Anfrage und späterer Provider-Aussage. Es ist keine globale Quittung. Der RFC trennt txn und jti: jti kennzeichnet einen einzelnen Token, während ein txn über Wiederholungen oder Veröffentlichungen an mehrere Empfänger hinweg gleich bleiben kann. Ein Treffer sagt, welche Transaktion korreliert wurde, nicht welcher Empfänger wohin konvergiert ist.

Die Nutzlast verlangt dieselbe Zurückhaltung. Genau eines von data und attributes muss vorhanden sein. data liefert eine Ressourcendarstellung nach der Transaktion; attributes nennt erzeugte oder geänderte Attribute. Auch eine vollständige Darstellung kann Schemamapping und lokale Bewertung erfordern. Eine Attributliste kann ein Nachladen verlangen. Keine der beiden Formen erklärt, dass der Empfänger Daten akzeptiert, eine Berechtigungsentscheidung umgesetzt oder nun denselben aktuellen Zustand hält.

Persistenz ist wiederum ein anderer Beleg. Empfänger müssen Ereignisse laut RFC vor der Empfangsbestätigung direkt oder indirekt für ihre lokalen Wiederherstellungsbedürfnisse persistieren. Das macht einen langlebigen Ereignisstrom bei kurzfristigen Zustellproblemen und Wiederholungen wiederherstellbar. Ein dauerhaftes Postfach belegt, dass ein Ereignis erhalten blieb; es belegt weder Zuordnung noch Ausführung noch beobachteten lokalen Zustand.

Running-Code Primacy fordert an dieser Stelle Disziplin: Ein technisches Artefakt darf nur den Zustand beweisen, den es tatsächlich sichtbar macht. Angenommene Anfrage, Set-Txn, txn, jti, SET-Eingang, Persistenz, lokale Zuordnung, Rückfrageergebnis, Regelentscheidung, Aktion und beobachteter Zustand sind getrennte Verbindungen. Wer sie pauschal „synchronisiert“ nennt, verdeckt genau die Lücke, die ein Betriebsteam später untersuchen muss.

Die robuste Antwort ist weder Misstrauen gegen RFC 9967 noch Zentralisierung der Entscheidung. Der Provider steht für seine Änderungsmitteilung ein, der Empfänger für deren Auslegung in seinem Modell, und die Organisation mit der Konsequenz bestimmt die Belegschwelle für „abgeglichen“. Der Standard erweitert nachprüfbare Fakten, ohne ein Ereignis als Entscheidung einer anderen Domäne auszugeben.

Quellen