SAML y OIDC, qué viaja en cada flujo

En el inicio de sesión único con SAML 2.0 la persona no entrega su contraseña a la nube. La entrega al proveedor de identidad, y este le devuelve una respuesta en XML con una aserción firmada: quién es, para quién es, hasta cuándo vale y qué atributos trae. El navegador hace de mensajero: publica esa respuesta (un POST) en el punto de recepción del servicio, que en AWS es la dirección de inicio de sesión de la consola.

El servicio no ve la contraseña, ve una afirmación firmada. Por eso lo que se revisa en una federación es la afirmación y la confianza que la nube le tiene a quien la firma.

Una aserción SAML y un token de identidad de OIDC responden a la misma necesidad con formatos distintos. SAML usa XML firmado y viaja por el navegador. En OIDC con código de autorización el navegador solo lleva un código de un solo uso; la aplicación lo canjea en el punto de tokens del proveedor por un canal directo y recibe un JSON Web Token firmado, con campos como el emisor (iss), la audiencia (aud), la caducidad (exp) y el nonce que ató la petición.

Quien recibe el mensaje comprueba lo mismo en ambos casos: que lo firmó quien dice (con claves que el proveedor publica), que va dirigido a este servicio y no a otro, y que está dentro de su ventana de validez. Basta que falle una de las tres para rechazarlo. Abre comparativo-flujos.txt.

Abre aserto-saml.xml. Entre los atributos hay uno que AWS usa como nombre de la sesión del rol: el valor de RoleSessionName. Es el que luego aparece en los registros de AWS como quién actuó, así que conviene que sea un identificador de la persona y no un nombre genérico.

El atributo SessionDuration indica, en segundos, cuánto debe durar la sesión de consola. Según la documentación de AWS puede ir desde 15 minutos hasta 12 horas, y si no viene, la sesión dura una hora. Que la aserción pida mucho tiempo no basta: el rol tiene su propio máximo. Pero lo que la aserción pide es lo primero que se lee.

La audiencia de un token identifica a la aplicación a la que va dirigido. Si el portal aceptara tokens emitidos para otra aplicación, un token pensado para el entorno de pruebas serviría en producción. validacion-portal.log recoge lo que el portal de Alborada aceptó y rechazó en una tarde, y cada rechazo dice por qué.