Proveedor de identidad y proveedor de servicio

SAML 2.0 es un estándar de OASIS, publicado en 2005, para que una organización le diga a otra quién es una persona sin compartir su contraseña. Tiene dos papeles. El proveedor de identidad (IdP) es el sistema de la empresa cliente: autentica a la persona con su contraseña, su segundo factor o lo que su política pida, y emite una aserción, un documento XML firmado que afirma quién es y, a veces, a qué grupos pertenece. El proveedor de servicio (SP) es la aplicación: recibe la aserción, la valida y abre su propia sesión.

Los dos no hablan directamente en el caso más común. El mensaje viaja por el navegador de la persona, de un sitio al otro, y llega al SP en una dirección propia llamada servicio de consumo de aserciones (ACS). Por eso el SP no puede confiar en el canal: todo lo que decida tiene que apoyarse en lo que puede comprobar del mensaje. Y lo que hace la persona dentro de la aplicación, qué ve y con qué rol, lo sigue decidiendo el SP.

Abre arquitectura.txt y ubica cada pieza en su papel.

El flujo más seguro empieza en el SP. La persona elige su empresa, el SP crea una solicitud de autenticación (AuthnRequest) con un identificador único, lo guarda en la sesión de ese navegador y lo envía al IdP. Cuando la respuesta vuelve, debe traer ese mismo identificador en el atributo InResponseTo. Así el SP sabe que la respuesta contesta a algo que él pidió, en ese navegador y hace poco, y no a una solicitud de otra persona o de otro momento.

Lee traza-inicio.txt de principio a fin y sigue el identificador de ida y vuelta.

La firma de la aserción solo prueba algo si el SP sabe de antemano con qué clave la verifica. Ese dato se intercambia una vez, fuera del flujo, cuando se da de alta a la empresa cliente: el SP registra el certificado del IdP, normalmente desde sus metadatos. Si en lugar de eso el SP verifica la firma con el certificado que viene dentro del propio mensaje, en el elemento KeyInfo, solo comprueba que el mensaje es coherente consigo mismo: cualquiera que tenga un certificado propio puede producir un mensaje con una firma válida para ese certificado. La firma deja de decir quién habla. Es la debilidad que MITRE cataloga como verificación incorrecta de una firma criptográfica (CWE-347).

Revisa inquilinos-saml.yml, inquilino por inquilino.

SAML también permite el flujo al revés: la persona entra primero al portal de su empresa, hace clic en el enlace de la aplicación y el IdP envía una respuesta al SP sin que el SP haya pedido nada. Se le llama inicio desde el IdP, y la respuesta llega sin InResponseTo. Es cómodo, pero el SP pierde la única prueba de que esa respuesta corresponde a un inicio que empezó en ese navegador. La hoja de buenas prácticas de SAML de OWASP lo considera menos seguro y recomienda activarlo solo si hace falta, con detección de repeticiones y, si el parámetro RelayState lleva una dirección, compararla contra una lista de destinos permitidos.

Vuelve a inquilinos-saml.yml y busca quién acepta respuestas no solicitadas. Fíjate también en qué hace Quenaré con el destino que viene en RelayState para ese inquilino: una redirección a cualquier dirección convierte a la plataforma en un trampolín para enviar a la persona, ya autenticada, a un sitio ajeno.