Resolución de problemas
El mensaje de error depende de la herramienta, pero las causas son casi siempre las mismas. Encuentre la suya.
Consejo: pegue la respuesta SAML en el decodificador o use el SP de pruebas para ver exactamente qué comprobación falla.
Causa probable. La aserción está destinada a un nombre de aplicación distinto del que espera la aplicación. La diferencia puede ser un solo carácter: barra final, http frente a https, URL frente a URN, mayúsculas.
Causa probable. La dirección a la que el IdP envía la respuesta no es exactamente la de la aplicación. Caso habitual: un proxy inverso convierte internamente la aplicación de https a http, o añade una ruta.
Causa probable. El contenido cambió tras la firma, o un componente reformateó el XML por el camino (pasarela, antivirus web, copiar y pegar).
SAMLResponse) sin alterarla. Compruebe que la codificación base64 no esté rota por saltos de línea ni codificada dos veces.Causa probable. El certificado configurado en la aplicación no es el que firma. Muy a menudo, el IdP ha renovado su certificado y la aplicación conserva el antiguo.
Causa probable. Los relojes del servidor de la aplicación y del IdP no están sincronizados, o el periodo de validez es muy corto.
Causa probable. La aplicación no encuentra la solicitud a la que responde la respuesta: sesión perdida entretanto (cookie bloqueada, otro navegador, otra pestaña), varios servidores sin compartir sesión, o un inicio de sesión lanzado desde el IdP mientras la aplicación lo prohíbe.
Causa probable. La aplicación espera una dirección de correo y el IdP envía un identificador opaco (o al revés).
emailAddress o persistent en ambos lados, y compruebe que el IdP tiene el valor correspondiente para el usuario.Causa probable. El IdP no envía el atributo, o lo envía con otro nombre (mail, email o un nombre largo estilo URI).
Causa probable. La aplicación no puede crear su sesión tras la respuesta (cookie bloqueada, Secure en http interno, o un ACS que a su vez redirige al inicio de sesión).
Secure, SameSite) y que el ACS no esté protegido por el mismo inicio de sesión que debe completar.Causa probable. En el IdP, el usuario no está asignado a la aplicación, o sus grupos no coinciden con las reglas de la aplicación.
Causa probable. El IdP cifra las aserciones pero la aplicación no tiene la clave de descifrado, o se entregó al IdP un certificado de cifrado equivocado.
use="encryption") y conserve la clave privada correspondiente. ID-Kit todavía no descifra: desactive el cifrado para la prueba.Causa probable. Con el binding Redirect, la solicitud se comprime (deflate) antes del base64. Una herramienta que solo decodifica base64 ve caracteres ilegibles.
Causa probable. El IdP rechaza: aplicación desconocida (Entity ID no declarado), ACS no declarado, usuario desconocido o autenticación fallida.
¿Quiere verlo en directo? ID-Kit hace el papel que le falta y le muestra cada paso.