Resumen

  • RFC 9967, del que Nancy Cam-Winget es coautora, define eventos de seguridad SCIM en SET. Un SET comunica que ocurrió un cambio de estado en un proveedor SCIM; cada receptor determina la actuación local adecuada en vez de leerlo como una orden.
  • Set-Txn vincula una respuesta 202 Accepted con la reclamación txn de un SET posterior. Ese vínculo, la conservación del evento o su carga no acreditan que el receptor haya encontrado el recurso, conciliado el modelo, aplicado una política o alcanzado el mismo estado.

En un flujo asíncrono, la palabra más fácil de usar y más peligrosa de probar es hecho. Una solicitud obtiene 202 Accepted; después aparece un SET con el txn esperado. Eso prueba una secuencia valiosa, pero acotada. El proveedor aceptó procesar la solicitud de forma asíncrona y luego emitió un evento que el cliente puede correlacionar. No prueba que cada dominio receptor haya interpretado la novedad de la misma manera ni que ya produzca el efecto que alguien espera.

El RFC 9967, System for Cross-Domain Identity Management (SCIM) Profile for Security Event Tokens (SETs), formula con precisión qué porta un SET: información sobre un cambio de estado ocurrido en un proveedor de servicios SCIM. Es una alternativa útil al sondeo continuo. Sin embargo, el documento rechaza expresamente que los receptores interpreten esos SET como mandatos. Cada Event Receiver decide la mejor acción posterior dentro de su propio contexto; el ejemplo del RFC es la conciliación de diferencias de esquema y de tipo de recurso entre dominios.

La diferencia aparece en cuanto un URI llega a un sistema distinto. Puede que el receptor relacione el URI con un registro local. Puede que el identificador no exista, que el tipo de recurso tenga otro significado o que falte información para decidir. Cuando no logra emparejar el URI, el RFC permite al receptor realizar una llamada al proveedor previamente acordado y ejecutar un SCIM GET con el URI relativo. También puede conservar el evento para recuperación y dejar una acción para una cola local. Nada de eso contradice el cambio del proveedor; demuestra que el cambio y la conciliación son hechos diferentes.

La cabecera de correlación tampoco afirma más de lo que puede sostener. Una respuesta SCIM asíncrona usa 202 Accepted, no lleva cuerpo y devuelve Set-Txn. Su valor debe coincidir con la reclamación txn de un SET posterior, para que el cliente busque el evento de finalización correspondiente. Es una unión de auditoría excelente entre una solicitud aceptada y una declaración posterior del proveedor. No es un recibo de convergencia mundial. RFC 9967 separa txn de jti: jti identifica un token individual, mientras que un txn puede mantenerse en retransmisiones o en publicaciones para varios receptores. La coincidencia dice qué transacción se correlacionó, no qué receptor llegó a qué estado.

La forma del evento pide la misma cautela. Debe aparecer exactamente uno entre data y attributes. data ofrece una representación del recurso tras la transacción; attributes enumera los atributos creados o modificados. Una representación completa puede requerir transformación de esquema y juicio local. Una lista de atributos puede requerir recuperar el recurso. Ninguna forma confirma que un receptor aceptó el dato, ejecutó una decisión de acceso o ya refleja el estado actual del proveedor.

La persistencia es otra evidencia distinta. El RFC exige a los receptores persistir los eventos, directa o indirectamente, para sus necesidades locales de recuperación antes de acusar recibo. Esta regla hace recuperable un flujo de larga duración cuando hay fallos breves o reintentos. Una bandeja durable demuestra que el receptor guardó un mensaje. No demuestra que lo haya conciliado ni que una política local haya tenido un efecto.

La disciplina de Running-Code Primacy sugiere no convertir una cadena de artefactos técnicos en una autoridad ficticia. La solicitud aceptada, Set-Txn, txn, jti, la llegada del SET, la persistencia, el emparejamiento local, la consulta, la regla aplicada, la acción y el estado observado son uniones separadas. Llamarlas de una vez «sincronización» priva a operadores y auditores de la pregunta decisiva: ¿qué parte se ha observado realmente?

La salida sólida no es desconfiar del estándar ni imponer una respuesta central. El proveedor responde por informar su cambio. El receptor responde por interpretarlo dentro de su modelo. La entidad que soporta las consecuencias decide qué evidencia exige antes de declarar conciliación. Así, RFC 9967 amplía los hechos comprobables sin disfrazar un evento como una decisión ajena.

Fuentes