SAML leído como flujo de confianza

En el flujo más común, el iniciado por el proveedor de servicio (SP), la aplicación manda al navegador al IdP con una solicitud de autenticación que lleva un identificador propio. El IdP autentica a la persona y devuelve, a través del navegador, una respuesta firmada que contiene la aserción. El navegador la entrega en la dirección de recepción del SP (el ACS, assertion consumer service).

Cada elemento de la aserción responde a una pregunta del SP. El emisor (Issuer) y la firma: ¿viene de mi IdP? El sujeto (NameID): ¿quién es? Las condiciones: ¿es válida ahora (NotBefore, NotOnOrAfter) y es para mí (AudienceRestriction)? La confirmación del sujeto: ¿me la entregaron en mi dirección (Recipient) y contesta a una solicitud mía (InResponseTo)? La declaración de autenticación: ¿cuándo y cómo se autenticó?

La restricción de audiencia es la que impide reutilizar una aserción legítima en otro sitio: una aserción emitida para la nómina no debe abrir sesión en el ERP aunque esté perfectamente firmada.

Una aserción SAML del tipo más usado es un documento al portador: quien la tiene y la presenta dentro de su ventana de validez puede abrir la sesión. Por eso la política de una empresa fija una vigencia corta, de pocos minutos, que basta para que el navegador la entregue. Una vigencia de horas no aporta comodidad (la sesión de la aplicación ya dura lo que tenga que durar) y alarga la ventana en que una aserción robada o filtrada sirve.

Una excepción con fecha y motivo es una decisión. La misma desviación sin excepción es un error de configuración que nadie decidió.

Abre el laboratorio y compara registro-de-sp.txt con politica-saml.txt y excepciones.txt.

En el flujo iniciado por el SP, la respuesta lleva InResponseTo con el identificador de la solicitud. El SP puede comprobar que contesta a algo que él pidió en esa sesión del navegador. En el flujo iniciado por el IdP, la persona entra desde el portal del IdP y la respuesta llega sin solicitud previa: es una respuesta no solicitada.

Aceptarlas tiene sentido en la aplicación que se abre desde el portal, y a ese precio se pierde una comprobación. En una aplicación que nunca se abre así, aceptarlas solo quita una defensa sin dar nada a cambio: el SP deja de poder distinguir una respuesta que contesta a su solicitud de una que le llega sin que nadie la haya pedido.

Lee las dos últimas columnas de registro-de-sp.txt junto con la regla PS-2 de la política.

La aserción puede traer varias cosas que parecen identificar a la persona: el NameID, el correo, el nombre. Solo una debe servir para atar la sesión a la cuenta de la aplicación, y la política la fija. Un identificador persistente es opaco, propio de esa persona y no se reasigna; un correo puede cambiar o pasar a otra persona cuando la primera se va.

Lee asercion-erp.txt con la política PS-3 al lado.