Configuración de SAML 2.0
Configure el inicio de sesión único utilizando SAML 2.0 para proveedores de identidad que admiten el protocolo SAML. Esta guía cubre la configuración genérica de SAML aplicable a cualquier IdP compatible.
Requisitos previos
- Un proveedor de identidad compatible con SAML 2.0 (Okta, Azure AD, OneLogin, PingFederate, etc.)
- Acceso de administrador a su proveedor de identidad para crear y configurar aplicaciones
- Una cuenta de administrador de organización de SecureCodingHub
Detalles del proveedor de servicio
Estos valores son necesarios al configurar SecureCodingHub en su proveedor de identidad:
| Ajuste | Valor |
|---|---|
| SP Entity ID | https://api.limeplate.com |
| URL ACS (Assertion Consumer Service) | https://api.limeplate.com/api/sch/auth/sso/callback/saml |
| URL de metadatos del SP | https://api.limeplate.com/api/sch/auth/sso/metadata |
| Formato del Name ID | urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress |
| Binding | HTTP-POST |
Paso 1 — Configure su proveedor de identidad
Paso 2 — Configure SAML en SecureCodingHub
Paso 3 — Pruebe
Mapeo de atributos
SecureCodingHub lee los siguientes atributos de la afirmación SAML:
| Atributo SAML | Campo de SecureCodingHub | Obligatorio |
|---|---|---|
NameID (formato de correo) | Correo | Sí |
givenName (…/claims/givenname) | Nombre (primera parte — concatenada con el apellido en un único nombre para mostrar) | No |
surname (…/claims/surname) | Nombre (segunda parte — unida con givenName en el momento del aprovisionamiento) | No |
Leer una respuesta SAML en el mundo real
Cuando SAML falla, el camino más rápido al diagnóstico es inspeccionar la respuesta SAML real en lugar del síntoma en el navegador. Instale una extensión de navegador SAML tracer, reproduzca el inicio de sesión fallido y observe el POST que el IdP envía a la URL ACS. Tres campos le cuentan casi todo. El elemento Issuer debería coincidir con el entityID publicado en los metadatos de su IdP. El elemento Audience anidado dentro de Conditions debería coincidir con el SP Entity ID configurado en SecureCodingHub. El Subject NameID debería ser la dirección de correo del usuario en el formato que especificó.
Más allá de estos campos, compruebe el identificador InResponseTo si su IdP lo admite, confirme que la respuesta está firmada (el elemento ds:Signature está presente) y verifique que las marcas de tiempo NotBefore y NotOnOrAfter son consistentes con el reloj actual. Un desfase de reloj significativo entre el IdP y el SP provoca el rechazo silencioso de afirmaciones por lo demás válidas. Si la respuesta parece bien formada pero la afirmación sigue siendo rechazada, copie el valor SAMLResponse codificado en base64 desde el tracer y decodifíquelo sin conexión. Leer el XML en crudo frente a la especificación SAML 2.0 es la forma más fiable de encontrar un atributo ausente o una declaración mal configurada.
Cuándo pedir ayuda al equipo del IdP o al equipo del SP
La mayoría de los tickets de soporte SAML pueden clasificarse en menos de un minuto si sabe en qué lado de la federación vive el error. Como regla general, los desajustes de audiencia y emisor son problemas del lado del SP: la configuración de SecureCodingHub espera valores que el IdP no está produciendo, o se configuró frente a un SP entity ID distinto del que el IdP está firmando. Estos se resuelven ajustando los ajustes SSO de SecureCodingHub o el SP Entity ID y la URL ACS en la configuración de la aplicación del IdP. Acuda primero al lado de SecureCodingHub.
Los problemas de mapeo de claims y atributos suelen ser del lado del IdP. Si los usuarios aterrizan en SecureCodingHub con nombres ausentes, direcciones de correo equivocadas o asignaciones de rol inesperadas, el IdP está emitiendo atributos que el SP no puede consumir. El administrador del IdP necesita añadir o renombrar claims en la configuración de la aplicación. Los fallos de certificado y firma están repartidos: si el certificado del IdP caducó o se rotó, eso es un arreglo del lado del IdP. Si SecureCodingHub dejó de confiar en una firma previamente válida, los metadatos o el certificado almacenados en el lado del SP están obsoletos y necesitan refrescarse. En caso de duda, capture la salida del SAML tracer y compártala con ambos equipos; la propia respuesta muestra qué lado debe dar el siguiente paso. Consulte la descripción general de SSO para orientarse en la selección de protocolo.
SAML 2.0: preguntas frecuentes
¿Qué significa realmente "SAML federado"?
SAML federado se refiere a la relación de confianza establecida entre un proveedor de identidad (IdP) y un proveedor de servicio (SP) para que un usuario pueda autenticarse una vez en el IdP y que esa afirmación sea aceptada por el SP. La federación es el contrato XML firmado: cada lado confía en los metadatos y el certificado de firma del otro. SecureCodingHub pasa a formar parte de su federación una vez que sube los metadatos del IdP y el IdP conoce el SP entity ID.
¿Cómo roto un certificado SAML sin romper los inicios de sesión?
Una rotación de certificado SAML se ejecuta mejor con una breve ventana de solapamiento. Si su IdP admite publicar varios certificados de firma en los metadatos, añada el certificado nuevo antes de retirar el antiguo y haga que SecureCodingHub vuelva a buscar los metadatos del IdP para que ambos certificados sean de confianza durante la transición. Después de que el IdP comience a firmar con la nueva clave, monitorice los inicios de sesión durante un día y, a continuación, elimine el certificado antiguo de los metadatos. La caída de producción más común es rotar sin solapamiento, un viernes.
SAML vs OAuth vs OpenID Connect — ¿cuál elijo?
Cuando los equipos comparan SAML frente a OAuth frente a OpenID Connect, la respuesta práctica es seguir el encaje operativo. SAML 2.0 es el estándar de federación maduro, basado en XML, dominante en los IdP empresariales como ADFS y PingFederate. OAuth 2.0 por sí solo es un marco de autorización, no de autenticación. OpenID Connect añade una capa de identidad sobre OAuth 2.0 y es el valor por defecto moderno para Azure AD y Okta. Tanto SAML como OIDC le proporcionarán una seguridad SSO equivalente con SecureCodingHub.
¿Cómo decodifico una respuesta SAML para resolver un fallo?
Para decodificar una respuesta SAML, capture el parámetro SAMLResponse codificado en base64 que el IdP envía mediante POST a la URL ACS — una extensión de navegador SAML tracer es la forma más sencilla de obtenerlo. Decodifique el valor de base64 a XML en crudo e inspeccione el Issuer, Audience, NameID y las marcas de tiempo. La mayoría de los fallos se resuelven una vez que compara esos cuatro campos con los valores configurados en los ajustes SSO de SecureCodingHub y en la configuración de la aplicación de su IdP.