Los requisitos a menudo se expresan en términos de autenticación (mutua), integridad y confidencialidad, dejando la elección del mecanismo de seguridad a los implementadores y despliegues. El caso de uso principal de SAML se denomina inicio de sesión único (SSO) del navegador web. Un usuario utiliza un agente de usuario (normalmente un navegador web) y solicita un recurso web protegido por un proveedor de servicios SAML. El proveedor de servicios, que desea conocer la identidad del usuario solicitante, emite una solicitud de autenticación a un proveedor de identidad SAML a través del agente de usuario.
Seguridad SAML general
Las siguientes secciones analizan los riesgos de seguridad al usar e implementar SAML y describen las contramedidas que utiliza el complemento/módulo SSO miniOrange SAML para mitigar los riesgos.
- Afirmaciones SAML:
En el nivel de la afirmación SAML en sí, hay poco que decir sobre las preocupaciones de seguridad; la mayoría de las preocupaciones surgen durante las comunicaciones en el protocolo de solicitud/respuesta, o durante el intento de utilizar SAML por medio de uno de los enlaces. Por supuesto, siempre se espera que el consumidor respete el intervalo de validez de la afirmación y cualquier elemento que esté presente en la afirmación. Sin embargo, una cuestión a nivel de aserción merece análisis: una aserción, una vez emitida, está fuera del control del emisor. Este hecho tiene varias ramificaciones. Por ejemplo, el emisor no tiene control sobre cuánto tiempo persistirá la afirmación en los sistemas del consumidor; El emisor tampoco tiene control sobre las partes con quienes el consumidor/proveedor de servicios compartirá la información de la afirmación. Estas preocupaciones van más allá de las preocupaciones sobre un atacante malicioso que pueda ver el contenido de las afirmaciones que pasan por la red sin cifrar (o insuficientemente cifradas). Si bien se han realizado esfuerzos para abordar muchas de estas cuestiones dentro de la especificación SAML, nada de lo contenido en la especificación borrará el requisito de una consideración cuidadosa de qué incluir en una afirmación. En todo momento, los emisores deben considerar las posibles consecuencias si la información contenida en la afirmación se almacena en un sitio remoto, donde puede ser directamente utilizada indebidamente, expuesta a posibles piratas informáticos o posiblemente almacenada para usos más creativos y fraudulentos. Los emisores también deben considerar la posibilidad de que la información contenida en la afirmación pueda compartirse con otras partes, o incluso hacerse pública, ya sea intencionalmente o sin darse cuenta.
1.1. Protocolo SAML:
Las siguientes secciones describen consideraciones de seguridad para el protocolo de solicitud-respuesta SAML en sí, además de cualquier amenaza que surja del uso de un enlace de protocolo particular.
1.1.1. Negación de servicio:
El protocolo SAML es susceptible a un ataque de denegación de servicio (DOS). Manejar una solicitud SAML es potencialmente una operación muy costosa, incluido el análisis del mensaje de solicitud (que normalmente implica la construcción de un árbol DOM), la búsqueda en la base de datos/almacenamiento de afirmaciones (potencialmente en una clave no indexada), la construcción de un mensaje de respuesta y, potencialmente, uno o más operaciones de firma digital. Por lo tanto, el esfuerzo requerido por un atacante para generar solicitudes es mucho menor que el esfuerzo necesario para manejar esas solicitudes.
1.1.2. Requerir solicitudes firmadas
La solicitud de señales de módulo/complemento SSO de miniOrange SAML también reduce el orden de la asimetría entre el trabajo realizado por el complemento SAML y el respondedor. El trabajo adicional requerido por el respondedor para verificar la firma es un porcentaje relativamente pequeño del trabajo total requerido por el respondedor, mientras que el proceso de cálculo de la firma digital representa una cantidad de trabajo relativamente grande para el solicitante. Reducir esta asimetría disminuye el riesgo asociado con un ataque de DOS. Sin embargo, tenga en cuenta que, en teoría, un atacante puede capturar un mensaje firmado y luego reproducirlo continuamente, evitando este requisito. Esta situación se puede evitar requiriendo el uso del elemento Firma XML. que contiene una marca de tiempo; Luego, la marca de tiempo se puede utilizar para determinar si la firma es reciente. Por lo tanto, cuanto más estrecha sea la ventana de firma válida después de la emisión de la respuesta, mayor será la seguridad contra la repetición de ataques de denegación de servicio.
2. Seguridad de enlaces SAML:
Las consideraciones de seguridad en el diseño del protocolo de solicitud-respuesta de SAML dependen en gran medida del enlace de protocolo particular (como se define en la especificación de enlaces de SAML [SAMLBind]) que se utiliza. Los enlaces sancionados por el Comité Técnico de Servicios de Seguridad de OASIS son el enlace SOAP, el enlace SOAP inverso (PAOS), el enlace de redireccionamiento HTTP, el enlace de redireccionamiento HTTP/POST y el enlace de artefacto HTTP y los enlaces de URI SAML. Los complementos miniOrange SAML SSO admiten enlaces Http-Redirect y Http-POST.
2.1. Enlace de redireccionamiento HTTP
2.1.2. Denegación de servicio
Amenaza: Redireccionamientos maliciosos a objetivos de proveedores de identidad o proveedores de servicios.
Descripción: Una entidad espuria podría emitir una redirección a un agente de usuario para que el agente de usuario acceda a un recurso que interrumpa el inicio de sesión único. Por ejemplo, un atacante podría redirigir al agente de usuario a un recurso de cierre de sesión de un proveedor de servicios, lo que provocaría que el Principal cerrara sesión en todas las sesiones de autenticación existentes.
Contramedidas: El acceso a los recursos que producen efectos secundarios se especifica con un calificador transitorio que debe corresponder a la sesión de autenticación actual. Alternativamente, se podría interponer un diálogo de confirmación que se base en un calificador transitorio con semántica similar.
2.2. Enlace HTTP POST
2.2.1. Afirmación robada
Amenaza: Si un espía puede copiar la respuesta SAML del usuario real y las aserciones incluidas, entonces el espía podría construir un cuerpo POST apropiado y poder hacerse pasar por el usuario en el sitio de destino.
Contramedidas: Mantenemos la confidencialidad cada vez que se comunica una respuesta entre el complemento SAML SSO y el navegador del usuario. Esto proporciona protección contra un espía que obtenga la respuesta y las afirmaciones SAML de un usuario real. Si un espía infringe las medidas utilizadas para garantizar la confidencialidad, hay contramedidas adicionales disponibles:
● Los sitios del Proveedor de identidad y del Proveedor de servicios DEBEN hacer un esfuerzo razonable para garantizar que la configuración del reloj en ambos sitios difiera en unos pocos minutos como máximo. Hay muchas formas de servicios de sincronización horaria disponibles, tanto a través de Internet como de fuentes patentadas.
● Cuando un perfil SAML que no es SSO utiliza el enlace POST, debe garantizar que el receptor pueda realizar una confirmación de asunto oportuna. Para este fin, DEBE incluirse una aserción de autenticación SAML para el principal en la respuesta del formulario PUBLICADO.
● Los valores para los atributos NotBefore y NotOnOrAfter de las aserciones de SSO DEBEN tener el período de validez más corto posible consistente con la comunicación exitosa de la aserción desde el proveedor de identidad al sitio del proveedor de servicios. Esto suele ser del orden de unos pocos minutos. Esto garantiza que una afirmación robada sólo pueda utilizarse con éxito en un breve período de tiempo.
● El complemento miniOrange SAML SSO verifica el período de validez de todas las aserciones obtenidas del sitio del proveedor de identidad y rechaza las aserciones vencidas. Elegimos implementar una prueba de validez más estricta para las aserciones de SSO, como exigir que el valor del atributo IssueInstant o AuthnInstant de la aserción esté dentro de unos minutos del momento en que se recibe la aserción en el sitio del proveedor de servicios.
● Si una declaración de autenticación recibida incluye una elemento con la dirección IP del usuario, el sitio del proveedor de servicios PUEDE comparar la dirección IP del navegador con la dirección IP contenida en la declaración de autenticación.
2.2.2. Afirmación falsificada
Amenaza: Un usuario malintencionado, o el usuario del navegador, podría falsificar o alterar una afirmación SAML.
Contramedidas: El perfil de navegador/POST requiere que la respuesta SAML que contiene aserciones SAML esté firmada, proporcionando así integridad y autenticación del mensaje. El complemento miniOrange SAML SSO verifica la firma y autentica al emisor.
2.2.3. Exposición del estado del navegador
Amenaza: El perfil de navegador/POST implica la carga de afirmaciones desde el navegador web al sitio de un proveedor de servicios. Esta información está disponible como parte del estado del navegador web y generalmente se almacena en un almacenamiento persistente en el sistema del usuario de forma completamente insegura. La amenaza aquí es que la afirmación pueda ser “reutilizada” en algún momento posterior.
Contramedidas: Las afirmaciones comunicadas utilizando este perfil siempre deben tener una vida útil corta y deben tener una Aserción SAML elemento. Se espera que los sitios de proveedores de servicios garanticen que las afirmaciones no se reutilicen.
2.2.4. Repetir
Amenaza: Los ataques de repetición equivalen a volver a enviar el formulario para acceder de forma fraudulenta a un recurso protegido.
Contramedidas: El complemento miniOrange SAML SSO exige que las afirmaciones transferidas tengan la propiedad de un solo uso, lo que evita que los ataques de repetición tengan éxito.
2.2.5. Modificación o Exposición de información estatal
Amenaza: Manipulación o fabricación del estado del relé. Algunos de los mensajes pueden llevar un elemento, cuya integridad se recomienda por parte del productor y, opcionalmente, protección de la confidencialidad. Si no se siguen estas prácticas, un adversario podría provocar efectos secundarios no deseados. Además, al no proteger la confidencialidad del valor de este elemento, una entidad legítima del sistema podría exponer información inadvertidamente al proveedor de identidad o a un atacante pasivo.
Contramedida: Siga la práctica recomendada de confidencialidad e integridad para proteger los datos de RelayState. Nota: Dado que el valor de este elemento lo produce y consume la misma entidad del sistema, se podrían utilizar primitivas criptográficas simétricas.
3. Seguridad del perfil SAML
La especificación de perfiles SAML [SAMLProf] define perfiles de SAML, que son conjuntos de reglas que describen cómo incorporar aserciones SAML y extraerlas de un marco o protocolo.
3.1. Perfiles de inicio de sesión único (SSO) del navegador web
Tenga en cuenta que la autenticación de usuario en el sitio de origen está explícitamente fuera de alcance, al igual que los problemas relacionados con la autenticación de este sitio de origen. La noción clave es que la entidad del sistema fuente debe poder determinar que la entidad del sistema cliente autenticado con la que interactúa es la misma que la del siguiente paso de interacción. Una forma de lograr esto es realizar estos pasos iniciales utilizando TLS como capa de sesión debajo del protocolo que se utiliza para esta interacción inicial (probablemente HTTP).
3.1.1. Perfil SSO
3.1.1.1. Modificación de mensaje
Amenaza: Existe la posibilidad de alteración de los mensajes en el flujo para este conjunto de perfiles. Algunos posibles resultados indeseables son los siguientes:
● La modificación de la solicitud inicial puede resultar en el rechazo por parte del emisor de SAML, o
creación de un artefacto dirigido a un recurso diferente al solicitado
● La alteración del artefacto puede provocar una denegación de servicio en el consumidor de SAML.
● La alteración de las propias afirmaciones durante el tránsito podría dar lugar a todo tipo de
de malos resultados (si están firmados) o de denegación de servicio (si están firmados y
el consumidor los rechaza).
Contramedidas: Para evitar la modificación del mensaje, el tráfico debe transportarse mediante un sistema que garantice la integridad del mensaje de un extremo a otro. Para los perfiles basados en navegador web, el método recomendado para proporcionar integridad de mensajes en tránsito es el uso de HTTP sobre TLS/SSL con un conjunto de cifrado que proporciona verificación de integridad de datos.
3.1.2. Perfil de cierre de sesión único
Amenaza: El atacante pasivo puede recopilar el identificador del nombre de un Principal. Durante los pasos iniciales, un atacante pasivo puede recolectar el información cuando se emite en la redirección. Exponer estos datos representa una amenaza a la privacidad.
Contramedidas: Todos los intercambios deben realizarse a través de un transporte seguro como SSL o TLS.
Amenaza: Un sin firmar podría ser inyectado por una entidad espuria del sistema, negando así el servicio al Principal. Suponiendo que el NameID pueda deducirse o derivarse, entonces es concebible que se pueda ordenar al agente de usuario que entregue un dispositivo fabricado. mensaje.
Contramedidas: El complemento/módulo miniOrange SAML SSO firma el mensaje. El Proveedor de identidad también puede verificar la identidad de un Principal en ausencia de una solicitud firmada.
3.2. Perfiles de gestión de identificadores de nombres
Amenaza: Permitir que las entidades del sistema correlacionen información o expongan inapropiadamente información de identidad, dañando la privacidad.
Contramedidas: El IDP debe tener cuidado de utilizar diferentes identificadores de nombre con diferentes proveedores de servicios para el mismo principal. El IDP debe cifrar el identificador de nombre que devuelve al proveedor de servicios, permitiendo que las interacciones posteriores utilicen un identificador opaco.
3.2.1. Perfiles de atributos
Las amenazas relacionadas con los enlaces asociados con los perfiles de atributos se analizan anteriormente. No se conocen amenazas adicionales específicas del perfil.
4. Resumen
La seguridad y la privacidad deben abordarse de manera sistemática, considerando que cuestiones humanas como los ataques de ingeniería social, cuestiones de políticas, gestión de claves y gestión de confianza, implementación segura y otros factores están fuera del alcance de este documento. Las soluciones técnicas de seguridad tienen un costo, por lo que los requisitos y las políticas alternativas también deben considerarse como requisitos legales y reglamentarios “obligatorios”. Este documento no normativo resume los problemas y enfoques generales de seguridad, así como las amenazas y contramedidas específicas para el uso de afirmaciones, protocolos, enlaces y perfiles de SAML de una manera segura que mantenga la privacidad. Los requisitos normativos se especifican en las especificaciones normativas SAML.
