Proveedor de identidad y parte que confía: quién garantiza qué

En una federación hay dos papeles. El proveedor de identidad (IdP) autentica a la persona y emite una afirmación firmada: esta persona es tal, se autenticó de tal forma a tal hora y tiene estos atributos. La parte que confía (en SAML se le llama proveedor de servicio; en OpenID Connect, cliente) recibe esa afirmación, comprueba que viene de quien dice y que es para ella, y con eso abre una sesión.

Lo que la parte que confía hace después es asunto suyo: el IdP no sabe qué pedidos puede aprobar alguien en el ERP ni qué descuentos puede conceder en el tablero comercial. Esa decisión se toma en la aplicación, con lo que el IdP afirma y con sus propias reglas. Por eso el diseño de una federación empieza por escribir, para cada aplicación, qué da por garantizado y qué decide con ello.

Ese papel escrito se llama acuerdo de confianza. NIST SP 800-63C-4 (julio de 2025), la guía de federación del instituto de estándares de EE. UU., le dedica un apartado propio: es el documento que fija qué afirma el IdP, con qué garantías y qué hace cada parte con lo que recibe, y puede ser bilateral (dos organizaciones) o multilateral (una federación de muchas).

No todos los atributos valen lo mismo. Un atributo es tan confiable como su fuente y como el control sobre quién puede cambiarlo. Un cargo que llega del sistema de recursos humanos y que solo cambia un analista con aprobación es un dato con dueño. Un dato que la persona escribe en su propio perfil es una declaración: sirve para contactarla, no para darle permisos.

El error de diseño aparece cuando una aplicación toma una decisión de autorización con un atributo del segundo tipo. El protocolo funciona perfectamente; la aserción va firmada; y aun así la persona se concede a sí misma lo que quiera, porque el IdP firma fielmente lo que ella escribió.

Abre el laboratorio y lee atributos.txt junto con aplicaciones.txt.

El segundo error es creer algo que el acuerdo excluye. Si el IdP declara que para cierto grupo no hay segundo factor, una aplicación que lo da por hecho tiene un supuesto falso. Lo peligroso es que nadie lo nota: la aplicación nunca recibe un aviso, solo deja de pedir algo que creía cubierto.

Lee acuerdo-de-confianza.txt y crúzalo, aplicación por aplicación, con la columna «da por garantizado» de aplicaciones.txt. Fíjate también en quién usa cada aplicación.

Corregir el atributo de la tarea 2 no pasa por esconderlo ni por vigilar a quien lo cambia. Pasa por dos decisiones de diseño: que el dato salga de una fuente con dueño (el sistema comercial asigna las zonas, no el vendedor) y que llegue a la aplicación por un camino que respete ese dueño. La aplicación también puede guardar la asignación en su propia tabla, mantenida por quien tiene autoridad para asignarla. Lo que no puede es seguir decidiendo con lo que la persona escribe de sí misma.