Résumé

  • Le RFC 9967, dont Nancy Cam-Winget est coautrice, transporte des événements de sécurité SCIM dans des SET. Un SET indique qu’un changement s’est produit chez un fournisseur SCIM ; chaque récepteur détermine sa propre suite locale au lieu de lire ce message comme une injonction.
  • Set-Txn associe une réponse asynchrone 202 Accepted à la revendication txn d’un SET ultérieur. Cette association, la persistance d’un événement ou son contenu ne prouvent ni rapprochement, ni application d’une règle, ni état présent chez le récepteur.

Le risque d’une automatisation asynchrone tient souvent au mot terminé. Une demande reçoit 202 Accepted, un en-tête Set-Txn, puis un SET portant le même txn. Le tableau de bord peut alors afficher « synchronisé ». Le protocole a pourtant établi une chaîne beaucoup plus précise : un fournisseur a accepté un travail asynchrone et a produit un événement corrélable. Il n’a pas établi ce que le domaine voisin a compris, retenu ou décidé.

Le RFC 9967, System for Cross-Domain Identity Management (SCIM) Profile for Security Event Tokens (SETs), définit le SET comme une information concernant un changement d’état déjà survenu chez un fournisseur de services SCIM. C’est une information de grande valeur : elle évite de faire interroger sans cesse le fournisseur par tous les systèmes dépendants. Mais le texte refuse délibérément de faire du SET une commande. Le récepteur choisit la meilleure action locale selon son contexte ; le RFC cite le rapprochement des schémas et des types de ressources entre domaines.

Cette réserve répond à une réalité d’exploitation. Deux domaines peuvent employer des identifiants différents, des attributs non isomorphes ou des règles de cycle de vie incompatibles. Un récepteur peut reconnaître l’URI et mettre à jour sa représentation. Il peut aussi ne pas la reconnaître. Dans ce cas, le RFC l’autorise à appeler l’URI relative sur une base SCIM préalablement convenue et à exécuter un GET. Il peut encore conserver l’événement pour la reprise et reporter l’action à un processus local. Le changement du fournisseur n’est pas moins réel parce que le récepteur n’est pas encore arrivé au même résultat.

L’en-tête de corrélation conserve la même modestie. Pour une réponse SCIM asynchrone, le RFC impose le statut 202 Accepted, l’absence de corps et un Set-Txn dont la valeur doit correspondre au txn d’un SET ultérieur. Le client peut ainsi rechercher l’événement de fin associé. C’est une jonction probante entre une demande et une déclaration ultérieure du fournisseur. Ce n’est pas un reçu universel. Le RFC distingue txn de jti : jti identifie un jeton, tandis qu’un même txn peut subsister dans des retransmissions ou des publications à plusieurs récepteurs. Une correspondance dit quelle opération a été corrélée, pas quel récepteur a convergé.

La forme de la charge utile limite également toute lecture excessive. L’événement contient exactement l’un des deux attributs data ou attributes. data fournit une représentation de la ressource après la transaction ; attributes énumère les champs créés ou modifiés. Une représentation complète n’absorbe pas la traduction de schéma et la politique locale. Une liste de changements peut exiger un rappel. Aucune des deux ne déclare que la ressource locale a été trouvée, que l’effet recherché a été autorisé ou que l’état observé est désormais identique.

La persistance constitue une autre preuve, pas la même preuve. Avant d’accuser réception, les récepteurs doivent, selon le RFC, faire persister directement ou indirectement les événements afin de répondre à leurs besoins de reprise. Cette obligation protège le flux de longue durée contre une panne momentanée ou une répétition de livraison. Une boîte de réception durable démontre honnêtement la conservation d’un événement. Elle ne démontre ni l’appariement, ni l’exécution, ni l’état actuel d’une ressource locale.

La discipline de Running-Code Primacy aide ici à résister aux libellés commodes. Demande acceptée, Set-Txn, txn, jti, réception, persistance, correspondance locale, résultat du rappel, règle examinée, action et état observé sont des faits distincts. Les fondre dans le mot « réconcilié » masque précisément le joint qui échouera lorsqu’une investigation devra séparer l’annonce du fournisseur de l’effet dans le domaine récepteur.

La bonne réponse n’est donc ni de dévaluer le RFC 9967 ni d’imposer une décision centrale. Le fournisseur atteste son changement. Le récepteur conserve le pouvoir de l’interpréter dans son modèle. L’organisation qui assume la conséquence fixe le seuil auquel elle appellera un état « rapproché ». Cette répartition produit une trace capable de dire ce qui est connu, et ce qui ne l’est pas encore.

Sources