Assertions, bindings, metadata, firmas XML, SSO y federación de identidad en entornos corporativos
Edición en profundidad - material de estudio y consulta profesional
Por João Ricardo Dutra••Material completo
Federación : identidad autenticada en un dominio y consumida en otro
Figura de apertura: conecta dominios de identidad a través de mensajes y relaciones de confianza explícitas.
Principio central
transporta de seguridad entre entidades que ya han establecido , claves y reglas de confianza.
Edición en profundidad: material de estudio y consulta profesional.
Presentación del capítulo
Los capítulos anteriores estudiaron 2.0, OpenID Connect y la familia . Estos estándares dominan las aplicaciones y modernas, pero no han reemplazado por completo los mecanismos de federación empresarial creados antes que ellos. 2.0 sigue estando ampliamente presente en portales corporativos, sistemas SaaS, entornos académicos, gobiernos, bancos e integraciones entre organizaciones que requieren un inicio de sesión único basado en navegador y un intercambio de atributos estandarizado.
, abreviatura de Security Markup Language, es un marco para comunicar de autenticación, atributos y decisiones de autorización. Su uso más conocido es el del navegador web, en el que un Identity Provider autentica al usuario y envía una aserción firmada al Service Provider. Sin embargo, comprender por sí solo el flujo visual de la redirección es insuficiente. La seguridad depende de enlaces, , certificados, validación de firmas , condiciones temporales, audience, destinatario, correlación y protección de reproducción.
A diferencia de un simple de portador transportado directamente a una , la respuesta generalmente la consume un de Service Provider específico llamado Servicio de Consumidor de Aserción. El valida el mensaje y crea su propia sesión local. Esta separación explica por qué es especialmente adecuado para el inicio de sesión federado para aplicaciones web, pero menos natural para la autorización delegada de y llamadas de servicio a servicio.
Este capítulo construye un modelo mental completo de 2.0: actores, aserciones, mensajes de protocolo, enlaces, perfiles, , , atributos, firma, cifrado, Single Logout, federación e integración con . El objetivo es permitir el diseño, la revisión y la de forma segura, sin reducir el estándar a copiar certificados entre dos consolas administrativas.
Cómo estudiar este capítulo
Separe siempre cuatro capas: aserción, mensaje de protocolo, enlace y . Luego, siga la relación de confianza descrita en los y valide cada restricción de seguridad. Esta descomposición hace que sea mucho menos confuso y evita mezclar transporte, identidad y sesión.
Objetivos de aprendizaje
Explique las responsabilidades del director, el Identity Provider, el Service Provider y las autoridades .
Distinga aserción, mensaje de protocolo, enlace, y .
Describir declaraciones de autenticación, atributos y decisiones de autorización.
Detalle el del navegador web en los modos iniciado por e iniciado por .
Interpretar , Respuesta, Aserción, Asunto, Condiciones y .
Compare bindings -Redirect, - , -Artifact y .
Comprenda el , , el servicio , el servicio , el descriptor de clave y la rotación de certificados.
Aplique una validación de firma segura y reconozca el ajuste y la reproducción de firmas.
Comprenda , atributos, mapeo de identidad, y descubrimiento de .
Compare 2.0 con OpenID Connect y reconozca el papel de los intermediarios y de identidad.
Estructura del capítulo
19.1 Fundamentos y componentes de 2.0
19.2 Aserciones y declaraciones
19.3 Mensajes de protocolo
19.4 del navegador web
19.5 iniciado por el y el
19.6 en profundidad
19.7 y en profundidad
19.8 Conditions, y correlación
19.9 Bindings
19.10 y confianza
19.11 Firma y cifrado
19.12 , atributos y mapeo
19.13 Sesiones, y descubrimiento
19.14 x , , seguridad y
Resumen, lista de verificación, ejercicios, glosario y referencias.
19.1 Fundamentos y componentes de 2.0
organiza la federación en entidades con roles bien definidos. El principal normalmente es el usuario. El Identity Provider, o , autentica este principal y emite . El Proveedor de Servicios, o , ofrece la aplicación y confía en las producidas por el según una relación previamente configurada. En escenarios más amplios, también puede haber autoridades de atributos, autoridades de autenticación y puntos de decisión de políticas.
El patrón se compone de piezas complementarias. Core define aserciones y mensajes de protocolo. Los bindings describen cómo se transportan estos mensajes a través de protocolos como o . Los perfiles combinan aserciones, mensajes y bindings para resolver casos de uso concretos, como del navegador o Single Logout. Los describen entidades, , bindings admitidos, identificadores, certificados y otra información necesaria para la interoperabilidad.
La relación de confianza no surge porque un mensaje contenga un certificado. El debe conocer de antemano el del y las claves aceptadas para la firma. Asimismo, el necesita conocer el del , sus y, según la política, las claves utilizadas por el . Los son el mecanismo estándar para distribuir esta información, pero su obtención y actualización también debe ser autenticada y gobernada.
Tabla 1: las capas SAML deben analizarse por separado.
Concepto
Responsabilidad
Ejemplo
Assertion
Contiene declaraciones sobre un tema.
Usuario autenticado con MFA y atributos corporativos.
protocolo
Coordina las solicitudes y respuestas de SAML.
Solicitud y respuesta de autenticación.
Encuadernación
Define el transporte del mensaje.
Redireccionamiento HTTP o HTTP-POST.
Perfil
Combina reglas para un caso de uso.
Perfil SSO del navegador web.
Metadata
Publica identidades, endpoints y claves.
EntityDescriptor del IdP o SP.
19.2 Aserciones y declaraciones
Una aserción es una estructura emitida por una autoridad y relacionada con un tema. Tiene identificador, versión, hora de emisión, issuer y cero o más declaraciones. También puede contener una firma, condiciones e información sobre cómo el sujeto debe confirmar su identidad al destinatario.
La Declaración de Autenticación registra que una autoridad autenticó al sujeto en un momento y contexto determinados. Puede incluir SessionIndex, SessionNotOnOrAfter y AuthnContextClassRef, elementos utilizados por las aplicaciones que necesitan distinguir contraseña, , certificado u otros métodos. La Declaración de atributos lleva pares de nombre y valor, como identificador interno, correo electrónico, unidad organizativa o grupos.
La Declaración de decisión de autorización representa una decisión de autorización sobre un recurso, pero es menos común en el web moderno. En la práctica, muchos utilizan atributos y contexto de autenticación para impulsar sus propias políticas locales. Esta elección preserva la autonomía del dominio, pero requiere acuerdos claros sobre semántica, cardinalidad, espacios de nombres y manejo de atributos faltantes.
Figura 1: una afirmación segura combina origen, asunto, restricciones, declaraciones y protección criptográfica.
Tabla 2: Las declaraciones tienen una semántica diferente dentro de la afirmación.
declaración
Declaración principal
Uso recurrente
AuthnStatement
Cómo y cuándo se autenticó al usuario.
SSO, intensificación y auditoría.
AttributeStatement
Atributos asociados al tema.
Aprovisionamiento lógico y autorización local.
AuthzDecisionStatement
Decisión sobre la acción en apelación.
Integraciones específicas y heredadas.
19.3 Mensajes de protocolo
Los mensajes del protocolo coordinan las interacciones entre entidades. solicita autenticación; contiene una o más o un estado de error; LogoutRequest y LogoutResponse participan en el Single Logout; ArtifactResolve y ArtifactResponse recuperan mensajes por referencia; AttributeQuery y AuthnQuery consultan autoridades especializadas.
Cada mensaje tiene ID, Versión, IssueInstant y, según el tipo, Destino, Consentimiento, y otros atributos. Estos campos no son decorativos. La identificación permite la correlación y la protección de . El destino restringe el esperado. vincula una respuesta a una solicitud emitida previamente. IssueInstant ayuda con la validación temporal y la investigación de relojes desalineados.
El estado de la respuesta debe interpretarse antes de la afirmación. El éxito indica que el procesamiento principal está completo, pero no anula todas las validaciones. Otros códigos pueden representar un error del solicitante, un error de respuesta, una autenticación fallida, un método no compatible, un usuario desconocido o una falta de consentimiento.
El del navegador web es el uso más conocido de 2.0. El navegador actúa como intermediario entre el y el . Cuando el usuario accede a un recurso protegido, el crea una y redirige o envía el navegador al . El autentica al usuario, crea la , firma la afirmación o la respuesta misma según el acuerdo y devuelve el resultado al Servicio al Consumidor de Aserciones del .
El recibe el mensaje, realiza validaciones estructurales, criptográficas y semánticas y, si todo es correcto, crea una sesión de aplicación local. no define cómo se debe implementar esta sesión local. Puede utilizar una segura, una sesión del lado del servidor u otro mecanismo. Esto significa que la seguridad posterior al inicio de sesión también depende de controles clásicos como Secure, HttpOnly, SameSite, protección de caducidad, rotación y fijación.
conserva el estado de la aplicación, como el recurso solicitado originalmente. No debe tratarse como un canal de autorización confiable y debe protegerse contra la redirección abierta y la manipulación. La implementación solo debe aceptar objetivos pronosticados o valores opacos almacenados en el lado del servidor.
Figura 2: en el iniciado por el , la respuesta debe estar correlacionada con la original.
19.5 iniciado por el y el
En el iniciado por el , el flujo comienza en el Service Provider. El crea una , registra su ID y espera una respuesta correlacionada. Este modelo permite un mejor control del contexto, destino y retorno al recurso solicitado. La validación mitiga los ataques de respuesta en frío y ayuda a asociar la autenticación con la transacción correcta.
En el iniciado por el , el flujo comienza en un portal del o catálogo de aplicaciones. El envía una respuesta no solicitada al del . Este modo es conveniente para portales corporativos, pero pierde correlación con . La implementación debe compensar esta reducción en contexto con controles estrictos sobre el issuer, la audience, el destinatario, el tiempo, la y los destinos permitidos.
Algunas aplicaciones admiten ambos modos. En esta situación, el código de validación debe distinguir claramente entre respuestas solicitadas y no solicitadas. No es seguro simplemente hacer que sea opcional en todos los casos. La política debe definir cuándo se acepta la iniciativa iniciada por , para qué , y flujos de negocios.
Tabla 3: Los dos modos requieren políticas de validación diferentes.
Apariencia
iniciado por SP
Iniciado por IdP
Inicio
El usuario accede al SP.
El usuario abandona el portal del IdP.
AuthnRequest
Existe y debe ser rastreado.
Normalmente ausente.
Correlación
InResponseTo y estado local.
No hay ninguna solicitud original.
Riesgo adicional
Abra la redirección y solicite manipulación.
Replay y respuesta no solicitada.
Tabla 3: Los dos modos requieren políticas de validación diferentes.
19.6 en profundidad
comunica al qué solicita autenticación y, opcionalmente, qué características desea. El issuer identifica al . El destino apunta al del . AssertionConsumerServiceURL o AssertionConsumerServiceIndex selecciona el . ProtocolBinding puede indicar cómo debe regresar la respuesta. NameIDPolicy requiere formato de identificador y puede permitir la creación de un nuevo seudónimo.
ForceAuthn solicita al que vuelva a autenticar al usuario incluso si existe una sesión . IsPassive solicita que el no interactúe con el usuario; Si no se puede realizar la autenticación silenciosa, la respuesta debe indicar un error apropiado. RequestedAuthnContext expresa requisitos sobre el método o la solidez de la autenticación, pero su interpretación debe estar alineada entre las partes.
La política puede exigir la firma de , especialmente cuando el envía dinámico, solicita ForceAuthn u opera en federaciones con requisitos estrictos. En el binding -Redirect, la firma se produce a través de parámetros de y no a través de un elemento ds:Signature dentro del . En el binding - , el mensaje puede llevar una firma . Confundir estas dos formas es una causa común de fracaso.
Tabla 4: AuthnRequest controla más que una simple redirección.
campo
Función
Validación o política
Emisor
Identifica el SP solicitante.
Debe coincidir con los metadata confiables.
Destino
Endpoint de Identity Provider.
Comparación exacta con el endpoint recibido.
URL/Índice SCA
Destino de la respuesta.
Sólo valores registrados en metadata.
FuerzaAuthn
Solicita una nueva autenticación.
Aplica solo según póliza.
Contexto de autenticación solicitado
Requisito de autenticación.
Mapear clases y comparar correctamente.
19.7 y en profundidad
es el mensaje de protocolo entregado al . Tiene Issuer, Status, Destination, y puede contener aserciones. En muchos perfiles, la y la Afirmación se pueden firmar en diferentes combinaciones. La política del debe definir exactamente qué firma se requiere y sobre qué elemento, evitando aceptar de manera inconsistente mensajes parcialmente protegidos.
La Aserción contiene las declaraciones consumidas por la aplicación. El debe encontrar la aserción autenticada mediante una firma validada, y no simplemente la primera aserción con un XPath determinado. Esta regla es fundamental contra el ajuste de firmas , un ataque en el que se mueve un elemento firmado válido y se coloca otro elemento malicioso en la ubicación que procesa la aplicación.
Una validación completa también verifica el issuer, la versión, el instante del problema, las condiciones, la restricción de audience, los datos de confirmación del sujeto, el destinatario, NotOnOrAfter, , AuthnStatement y el contexto requerido. Después de la validación, los atributos deben asignarse mediante reglas explícitas. El hecho de que un haya sido firmado no hace que todos los valores sean adecuados para la aplicación.
Estrutura simplificada de Response e Assertion
<samlp:Response Destination="https://app.example/saml/acs"
InResponseTo="_a12f...">
<saml:Issuer>https://idp.example/metadata</saml:Issuer>
<samlp:Status>...</samlp:Status>
<saml:Assertion ID="_assertion123">
<saml:Subject>...</saml:Subject>
<saml:Conditions>...</saml:Conditions>
<saml:AuthnStatement>...</saml:AuthnStatement>
<saml:AttributeStatement>...</saml:AttributeStatement>
</saml:Assertion>
</samlp:Response>
19.8 Conditions, y correlación
Las condiciones restringen cuándo y dónde se puede utilizar la afirmación. NotBefore define el instante inicial y NotOnOrAfter define un límite único. AudienceRestriction indica las entidades para las que se emitió la afirmación. La aplicación debe comparar la audience con su identificador esperado y utilizar una tolerancia de reloj pequeña y controlada, sin transformar la desviación del reloj en una ventana de reproducción amplia.
normalmente utiliza el método de portador en el del navegador web. SubjectConfirmationData transporta Destinatario, NotOnOrAfter e . El destinatario debe coincidir con el realmente utilizado. debe apuntar a una pendiente cuando el inició el flujo. Una respuesta ya procesada debe marcarse como consumida para evitar que se reproduzca.
La correlación también involucra , temporales y estado local. Estos elementos no se reemplazan entre sí. relaciona la con ; devuelve el contexto de la aplicación; la sesión temporal del almacena información sobre la transacción. Un diseño robusto mantiene todos los enlaces y elimina el estado después de su uso.
Figura 3: La firma es un paso del proceso, no una validación completa.
19.9 Bindings
El binding define cómo se asigna un mensaje a otro protocolo. En el binding -Redirect, el mensaje normalmente se comprime con DEFLATE, se codifica en y se coloca en la . Es adecuado para AuthnRequests pequeñas, pero tiene límites de y reglas de firma específicas en torno a SAMLRequest, y SigAlg.
En el binding - , el mensaje se envía en formato , generalmente mediante envío automático. Es el enlace más común para transportar SAMLResponse a . A medida que el navegador entrega contenido de un dominio a otro, el debe aceptar , proteger la sesión local y validar completamente el mensaje antes de cualquier redirección.
-Artifact solo envía una breve referencia a través del navegador. El intercambia el artefacto por el mensaje real en un back-channel, normalmente con . Esto reduce la exposición de las al agente de usuario, pero agrega disponibilidad, autenticación y latencia al servicio de resolución de artefactos. también aparece en consultas de back-channel y Single Logout.
Figura 4 - La unión es transporte; el define cómo participa este transporte en el caso de uso.
Tabla 5 - Cada vinculación tiene su propio formato y riesgos operativos.
Encuadernación
Uso típico
Punto técnico
HTTP-Redirect
AuthnRequest en el navegador.
DEFLATE, codificación de URL y firma de parámetros.
HTTP-POST
SAMLRespuesta para ACS.
Formulario HTML con mensaje Base64.
HTTP-Artifact
Referencia del front-channel.
Resolución de mensajes vía back-channel.
SOAP
Consultas e intercambio directo.
Canal de servidor a servidor con XML SOAP.
19.10 y confianza
Los describen entidades a través de EntityDescriptor. Un es un identificador estable, a menudo un , pero no es necesario que sea una accesible. Los descriptores de funciones informan si la entidad actúa como , u otra autoridad. Los incluyen enlace, ubicación, índice y preferencia. KeyDescriptor publica certificados asociados con la firma o el cifrado.
Los del generalmente contienen , formatos de y certificados. Los de contienen SingleSignOnService, SingleLogoutService, certificados y otros recursos. El consumidor sólo debe aceptar y claves de fuentes confiables. Permitir arbitrario proveniente únicamente de puede convertir al en un transmisor de para un atacante.
La rotación de certificados requiere superposición. El nuevo certificado debe publicarse antes de poder utilizarse; el antiguo permanece mientras que los mensajes y los cachés aún pueden depender de él. El certificado caducado en los no debe tratarse de manera simplista: el uso de en suele ser un contenedor de claves, pero las políticas corporativas pueden requerir validaciones adicionales. Lo importante es tener reglas explícitas y auditables.
Figura 5: Los reducen la configuración manual, pero necesitan una cadena de distribución confiable.
Exemplo simplificado de metadata de SP
<md:EntityDescriptor entityID="https://app.example/saml">
<md:SPSSODescriptor AuthnRequestsSigned="true"
protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
<md:KeyDescriptor use="signing">...</md:KeyDescriptor>
<md:AssertionConsumerService
Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
Location="https://app.example/saml/acs"
index="0" isDefault="true"/>
</md:SPSSODescriptor>
</md:EntityDescriptor>
19.11 Firma y cifrado
La firma protege la integridad y autenticidad de los elementos . Hace referencia a un elemento por ID, aplica transformaciones, canonicalización y resumen y produce SignatureValue. La canonicalización existe porque semánticamente equivalente puede tener diferencias en los espacios en blanco, los espacios de nombres y el orden de los atributos. La implementación debe utilizar bibliotecas maduras y una política estricta sobre algoritmos, transformaciones y referencias.
El ataque aprovecha la divergencia entre el elemento verificado y el elemento consumido. La defensa principal es resolver la referencia firmada de forma segura, exigir identificaciones únicas, rechazar estructuras inesperadas y procesar exactamente el nodo autenticado. Las consultas XPath genéricas, como buscar la primera afirmación en el documento, son peligrosas cuando no están vinculadas a la verificación criptográfica.
El cifrado le permite cifrar la aserción, el ID de nombre o los atributos. El utiliza la clave de cifrado pública del y el la descifra con su clave privada. La firma y el cifrado resuelven diferentes problemas: el cifrado protege la confidencialidad en el camino y ante los intermediarios; la firma protege la integridad y el origen. Incluso una afirmación cifrada debe validarse después del descifrado.
Tabla 6 - Los controles criptográficos son complementarios.
Control criptográfico
Protege
No reemplaza
Firma de respuesta
Protocolo y mensaje de destino.
Validación de aserción y condiciones.
Firma de afirmación
Declaraciones y restricciones.
Correlación y protección de sesiones.
Aserción cifrada
Confidencialidad del contenido.
Autenticidad y audience.
TLS
Canal entre participantes.
Firma de extremo a extremo del mensaje.
Regla de implementación
Nunca implemente la firma manualmente con concatenación de cadenas o XPath improvisado. Utilice una biblioteca especializada, mantenga un analizador reforzado, desactive entidades externas y valide la estructura, los ID y las referencias antes de consumir atributos.
19.12 , atributos y mapeo de identidad
identifica al sujeto en formatos estandarizados. Persistente produce un identificador estable y generalmente opaco. Transitorio crea un valor temporal. EmailAddress utiliza el correo electrónico, pero puede no ser adecuado como clave inmutable. No especificado depende del acuerdo bilateral. La elección debe considerar la privacidad, la correlación entre los , los cambios de datos y el ciclo de vida de la cuenta.
Los atributos se identifican por Nombre y, opcionalmente, NameFormat y FriendlyName. El no debe depender únicamente de nombres informales como rol o grupo sin contrato. Es necesario definir el espacio de nombres, el tipo, la cardinalidad, el origen autorizado y el significado. Un grupo de directorio puede no equivaler a un permiso comercial y las asignaciones automáticas pueden elevar los privilegios de manera inapropiada.
La vinculación de cuentas merece atención. Cuando el recibe un sujeto federado, necesita vincularlo a una cuenta local. La vinculación únicamente por correo electrónico puede permitir la adquisición si diferentes proveedores emiten la misma dirección o si la verificación por correo electrónico no es equivalente. La clave recomendada normalmente combina un identificador de issuer y sujeto estable, con procesos controlados para la migración.
Tabla 7: Los identificadores y atributos necesitan un contrato, no solo un XML válido.
Formato/elemento
Característica
Precaución
ID de nombre persistente
Estable y opaco por relación.
Preservar el enlace durante la migración.
ID de nombre transitorio
Temporales y no correlacionados.
No utilizar como llave permanente.
dirección de correo electrónico
Legible y familiar.
Puede cambiar y no ser globalmente único.
atributo
Valor adicional sobre el tema.
Definir semántica, origen y cardinalidad.
19.13 Sesiones, Single Logout y descubrimiento
Hay al menos dos sesiones distintas: la sesión de usuario en el y la sesión local en el . AuthnStatement puede contener SessionIndex y SessionNotOnOrAfter, pero el decide cómo crear y caducar su . La finalización de la sesión del no finaliza automáticamente todas las sesiones locales a menos que se admita el Single Logout y funcione en toda la cadena.
El Single Logout coordina LogoutRequest y LogoutResponse entre los participantes. Puede utilizar el front-channel a través del navegador o el canal posterior. En la práctica, los fallos parciales son comunes: un no disponible, una bloqueada o un tiempo de espera pueden dejar las sesiones activas. Por lo tanto, no debe tratarse como un sustituto de sesiones cortas, revocación local y controles de riesgo propios.
Discovery aparece cuando un acepta varios proveedores. La elección se puede realizar por dominio de usuario, portal, de descubrimiento o servicio dedicado. La interfaz debe evitar el phishing y la selección confusa. En federaciones amplias, los servicios de descubrimiento y agregados deben operarse con firma, vencimiento, filtros y gobernanza.
19.14 2.0 x OpenID Connect
2.0 y OpenID Connect resuelven la autenticación federada, pero tienen diferentes modelos y ecosistemas. utiliza , aserciones, enlaces y perfiles de navegador. utiliza 2.0, , , y Discovery/ . tiende a encajar mejor en aplicaciones móviles, , y arquitecturas modernas; sigue siendo muy sólido en SaaS empresarial y en integraciones B2B heredadas.
La comparación no debe reducirse a lo viejo versus lo nuevo. tiene enriquecidos, federaciones maduras e interoperabilidad consolidada en muchos productos empresariales. ofrece una mejor alineación con , bibliotecas modernas y . Una organización puede operar ambas cosas durante muchos años, utilizando un intermediario de identidad para traducir protocolos y centralizar políticas.
La traducción entre y no es una mera conversión sintáctica. , asunto, atributos, , acr, amr, sesión y cierre de sesión tienen semánticas diferentes. El intermediario necesita asignaciones explícitas, políticas de confianza y observabilidad para que la garantía de autenticación no se degrade durante la transformación.
Tabla 8 - Las normas se superponen en objetivos, pero no en todos los detalles.
Apariencia
SAML 2.0
OpenID Connect
Formato
XML y firma XML.
JSON, JWT y JOSÉ.
uso dominante
Web corporativa SSO y federación B2B.
Web, aplicaciones móviles, API e identidad moderna.
Descubrimiento
Metadata SAML.
Metadata de descubrimiento y JWKS.
Identificador
NombreID y atributos.
sub y claims.
Sesión y cierre de sesión
SLO para mensajes SAML.
Canales de cierre de sesión iniciados por RP y OIDC.
19.15 en y brokers de identidad
Las normalmente protegen las con , , o credenciales técnicas. puede aparecer en la autenticación del portal de desarrolladores, en el inicio de sesión de la consola administrativa o como un protocolo de entrada del agente de identidad. Cuando una aplicación necesita llamar a , el patrón común es intercambiar la sesión federada con un apropiado y no enviar la aserción directamente a todos los servidores.
Algunas pueden validar , extraer atributos y transformarlos en contexto o internos. Esta capacidad debe usarse con cuidado: la debe validar la firma, el issuer, la audience, el destinatario, la hora y la reproducción con el mismo rigor que un . También debe evitar convertir atributos genéricos en privilegios amplios sin una política explícita.
En arquitecturas híbridas, un corredor puede recibir de los socios y emitir / para aplicaciones modernas. Este puente reduce la necesidad de que cada comprenda la firma , pero centra la confianza en el intermediario. Los registros deben registrar el issuer externo, el sujeto federado, el método de autenticación, las asignaciones y el emitido, preservando la trazabilidad de un extremo a otro.
19.16 Amenazas y hardening
Las principales amenazas incluyen de , firma no válida o elemento incorrecto, aceptación inesperada del issuer, audience inadecuada, abierto, envoltura de firmas , analizador vulnerable a entidades externas, algoritmos débiles, manipulados, robo de sesiones, redireccionamiento abierto a través de y mapeo de atributos inseguro.
El fortalecimiento comienza con listas permitidas de y , autenticados, algoritmos modernos, validación precisa de , ID únicas, cachés de reproducción, estricta tolerancia de reloj y cierre de fallas. El analizador debe deshabilitar DTD y entidades externas. La aplicación sólo debe procesar elementos firmados y rechazar mensajes con estructura ambigua, firmas duplicadas o referencias inesperadas.
La operación también importa. Los certificados necesitan inventario, alertas y rotación con superposición. Los relojes deben utilizar una sincronización confiable. Los cambios de atributos y requieren pruebas de regresión. Los registros no deben almacenar completas innecesariamente, ya que pueden contener datos personales e información de autenticación.
Tabla 9: la mayoría de las fallas ocurren en la validación y la integración, no en el concepto de SAML.
Amenaza
Defecto explotado
controlar
Reproducir
Aserción válida reutilizada.
Cache de ID y ventanas de tiempo breves.
Envoltorio de firma
El elemento verificado se diferencia del consumido.
Procese exactamente el nodo referenciado y firmado.
inyección SCA
Destino controlado por el atacante.
Solo endpoints registrados en metadata.
XXE
El analizador resuelve la entidad externa.
DTD y entidades externas deshabilitadas.
Mapeo de privilegios
El atributo se convierte en permiso excesivo.
Mapeo explícito y privilegio mínimo.
19.17 basada en evidencia
La debe identificar el punto exacto del flujo: creación del , redirección, autenticación en el , emisión de la , entrega al , validación criptográfica, mapeo de atributos o creación de sesión. Los errores del navegador, la y la aplicación pueden parecer similares, por lo que los ID de solicitud, las marcas de tiempo, los y los son esenciales.
Mensajes como una firma no válida pueden deberse a un certificado incorrecto, una canonicalización, un alterado, un algoritmo no permitido o la verificación del elemento incorrecto. La audience no válida apunta a un divergente. La falta de coincidencia del destinatario indica un SCA diferente. La respuesta caducada podría deberse a un reloj desalineado, una cola larga o una ventana pequeña. desconocido apunta a un estado perdido, varios nodos que no comparten una sesión o una respuesta no solicitada.
Las herramientas de captura deben usarse en entornos autorizados y con cuidado de no exponer . El diagnóstico ideal compara los activos, la solicitud emitida, la respuesta recibida, el certificado seleccionado y la configuración de la aplicación. En los clústeres, verifique la afinidad, solicite el almacenamiento de ID y el reloj de todos los nodos.
Tabla 10: El diagnóstico SAML requiere correlación entre el mensaje, los metadata y el estado local.
Síntoma
Hipótesis
evidencia
Firma no válida
Clave incorrecta, XML, algoritmo o referencia modificados.
Certificado, información firmada, URI de referencia y registros de biblioteca.
Discrepancia de audience
ID de entidad diferente al esperado.
AudienceRestriction y configuración de SP.
En respuesta a desconocido
Estado perdido o respuesta no solicitada.
ID de solicitud, cookie temporal y nodo de clúster.
La afirmación expiró
Desviación del reloj o retraso excesivo.
NotBefore, NotOnOrAfter y el tiempo del host.
Usuario sin permiso
Atributo faltante o asignación incorrecta.
Declaración de atributos y política local.
19.18 Estudios de casos y laboratorios
Estudio de caso 1: una empresa integra su corporativo con un SaaS externo. requiere persistente y grupos específicos. El equipo define de dos caras, certificados de firma, mapeo de atributos, ventana de rotación y pruebas de usuarios de múltiples unidades. Inicialmente, el proyecto fracasó porque el correo electrónico se utilizó como clave inmutable; la solución adopta un identificador estable y una migración controlada.
Estudio de caso 2: un portal bancario acepta socios a través de y convierte la identidad en internos para . El corredor valida la afirmación, aplica la política del issuer y , asigna el sujeto externo a una aplicación asociada y emite un con audience restringida. La nunca recibe la afirmación original en los servidores, lo que reduce la exposición a y centraliza la federación.
Estudio de caso 3: un clúster de experimenta fallas intermitentes de . La causa es el almacenamiento local de en cada nodo sin afinidad o sesión compartida. El navegador comienza en un nodo y regresa a otro. La solución utiliza almacenamiento distribuido de solicitudes pendientes y mantiene la memoria caché de reproducción durante todo el período de validez.
Laboratorios sugeridos
1) Examinar los de y e identificar el , , , y certificados. 2) Decodificar una y una Respuesta del entorno del laboratorio. 3) Enumere todas las validaciones además de la firma. 4) Simular la rotación de certificados con período superpuesto. 5) Comparar un flujo con Authorization Code + .
Resumen del capítulo
2.0 es un marco de federación basado en aserciones, mensajes de protocolo, enlaces, perfiles y . Su caso de uso más común es el del navegador web entre un Identity Provider y un Service Provider. El autentica al principal, emite notificaciones y el valida el mensaje antes de crear su propia sesión local.
La seguridad depende de mucho más que una firma válida. El issuer, la audience, el destinatario, el destino, la respuesta de entrada, la hora, la confirmación del sujeto, la reproducción, la estructura y los deben validarse de forma coherente. El ajuste de firmas y el análisis inseguro demuestran por qué las bibliotecas maduras y el procesamiento eficaz de elementos firmados son indispensables.
sigue siendo relevante en federaciones empresariales y B2B, mientras que OpenID Connect se adapta mejor a las aplicaciones y modernas. Los intermediarios de identidad permiten la coexistencia y la traducción, pero necesitan preservar la semántica y la trazabilidad. En las plataformas , normalmente autentica a los usuarios en los portales o ingresa al intermediario, que luego emite los apropiados para las .
Siguiente paso del curso
El Capítulo 20 profundizará en la federación de identidades y el inicio de sesión único como arquitectura, comparando dominios de confianza, intermediarios, descubrimiento de dominios de origen, aprovisionamiento, ciclo de vida y coexistencia entre , OpenID Connect y otros mecanismos.
Lista de verificación de implementación y revisión
Los EntityID, los y los enlaces provienen de versionados y confiables.
Los ID de son únicos y se almacenan hasta la correlación de respuesta.
acepta solo destinos registrados y rechaza mensajes para otro destinatario.
La biblioteca valida la firma y la aplicación consume exactamente el elemento firmado.
Se verifican el issuer, la audience, el destino, el destinatario, y las condiciones temporales.
Las aserciones procesadas se registran en la caché de reproducción durante la ventana requerida.
Parser desactiva DTD, entidades externas y construcciones peligrosas.
y los atributos tienen un contrato semántico, de cardinalidad y de origen.
Las asignaciones de grupos a permisos siguen el privilegio mínimo y tienen pruebas.
Los certificados tienen un plan de inventario, monitoreo, superposición y reversión.
La sesión local utiliza seguras y no depende únicamente del Single Logout.
Los registros preservan la correlación sin almacenar datos personales innecesarios.
Ejercicios
Diferenciar entre aserción, mensaje de protocolo, vinculación, y .
Describa el flujo de iniciado por el e indique dónde se valida .
Explique por qué una firma válida no es suficiente para aceptar una afirmación.
Compare bindings -Redirect, - , -Artifact y .
Explique el papel de AudienceRestriction, Recipient y SubjectConfirmationData.
Diferenciar entre firma de respuesta y firma de aserción.
Describir el ajuste de firmas y la principal regla de defensa.
Proponer rotación de certificados sin tiempo de inactividad.
Compare persistente, transitorio y de dirección de correo electrónico.
Explique por qué puede fallar parcialmente.
Compare 2.0 y OpenID Connect en una arquitectura empresarial.
Diseñe un puente de a / utilizando un intermediario de identidad.
Glosario
Tabla 11 - Vocabulario esencial del capítulo.
Término
Definición
ACS
Servicio al Consumidor de Aserción; endpoint del SP que recibe la respuesta.
Assertion
Estructura XML con declaraciones sobre un tema.
AttributeStatement
Declaración que lleva atributos del sujeto.
AuthnContext
Información sobre el método o la fuerza de autenticación.
AuthnRequest
Mensaje del SP que solicita autenticación al IdP.
Encuadernación
Asignación de mensajes SAML a otro protocolo.
ID de entidad
Identificador estable de una entidad SAML.
IdP
Identity Provider que autentica y emite declaraciones.
InResponseTo
Correlación entre Respuesta y solicitud anterior.
Metadata
Descripción de la entidad, roles, endpoints, enlaces y claves.
NameID
Identificador de sujeto en formato definido.
Perfil
Conjunto de reglas para un caso de uso de SAML.
RelayState
Estado de la aplicación transportado por el flujo del navegador.
SLO
Single Logout coordinado entre los participantes.
SP
Service Provider que consume aserciones y ofrece la aplicación.
SubjectConfirmation
Reglas por las que el sujeto presenta la afirmación.
XML Signature Wrapping
Ataque que separa el elemento verificado del elemento consumido.
Referencias técnicas
OASIS. Aserciones y protocolos para el lenguaje de marcado de de seguridad ( ) de OASIS V2.0.
OASIS. Bindings para el lenguaje de marcado de afirmación de seguridad ( ) de OASIS V2.0.
OASIS. Perfiles para el lenguaje de marcado de afirmación de seguridad ( ) V2.0 de OASIS.
OASIS. para el lenguaje de marcado de afirmación de seguridad ( ) de OASIS V2.0.
OASIS. Descripción técnica del lenguaje de marcado de afirmación de seguridad ( ) V2.0.
OASIS. de interoperabilidad de V2.0 Versión 1.0.
. Sintaxis y procesamiento de firmas .
. Sintaxis y procesamiento de cifrado .
. Hoja de referencia de seguridad .
. Lineamientos de Identidad Digital, cuando sean aplicables al contexto de autenticación y federación.
Nota de actualización
2.0 es un estándar estable, pero los productos, los algoritmos permitidos, los perfiles de interoperabilidad y las prácticas de refuerzo continúan evolucionando. Antes de la implementación, valide la documentación oficial para el , , y biblioteca utilizados, incluido el comportamiento de firma, los y la rotación.
