¿Qué es SAML? Guía práctica sobre federación e inicio de sesión único empresarial
Privacidad, seguridad e identidad
SAML son las siglas de Security Assertion Markup Language. Es un estándar de federación basado en XML que se utiliza principalmente para el inicio de sesión único empresarial. En una configuración típica de SAML, un proveedor de identidad autentica al usuario y envía una aserción firmada a un proveedor de servicios, que confía en esa declaración y concede acceso a la aplicación. Por eso SAML es habitual en el acceso del personal a herramientas SaaS: centraliza el inicio de sesión y facilita la gestión de altas, cambios y bajas. Sin embargo, SAML no sustituye a una gestión sensata de permisos, certificados ni revisiones de acceso dentro de la aplicación.
Revisado por Jackie, responsable de Aprendizaje y Desarrollo, Levellers - Última revisión: 8 de junio de 2026
Qué significa esto
SAML se entiende mejor como un mecanismo de confianza entre sistemas. En lugar de que cada aplicación empresarial gestione por su cuenta nombres de usuario, contraseñas y MFA, una empresa puede designar un servicio como proveedor de identidad, habitualmente la plataforma corporativa de SSO. Cuando un usuario intenta abrir un proveedor de servicios, como una herramienta de nóminas o una plataforma de atención al cliente, esa aplicación redirige al usuario al proveedor de identidad. El proveedor de identidad verifica quién es y devuelve una declaración estructurada que viene a decir: "esta persona ha sido autenticada y estos son los datos de usuario que solicitaste".
Esa declaración se denomina aserción. Puede incluir una declaración de autenticación que indique cuándo y cómo inició sesión el usuario, además de atributos como la dirección de correo electrónico, el departamento o el identificador de rol. El proveedor de servicios utiliza la aserción para crear una sesión local y decidir cómo asignar al usuario una cuenta en la aplicación.
El resultado no es solo comodidad: cambia el lugar donde se controla la identidad. La política de contraseñas, el MFA, la marca de inicio de sesión y la desactivación de cuentas pueden gestionarse de forma centralizada en lugar de hacerlo por separado en cada herramienta. Por eso SAML se generalizó tanto en el acceso empresarial a SaaS, especialmente cuando las organizaciones quieren que el personal inicie sesión a través de una única capa de identidad corporativa.
Por qué es importante
SAML importa porque las cuentas locales dispersas generan carga operativa y deuda de seguridad. Si cada producto SaaS tiene sus propias contraseñas, proceso de restablecimiento, configuración de MFA y directorio de usuarios, la organización acaba con reglas de inicio de sesión inconsistentes y accesos obsoletos que persisten después de que las personas cambien de equipo o se marchen. SAML ayuda a devolver ese control al proveedor de identidad, lo que significa que una política de inicio de sesión más sólida puede proteger muchas aplicaciones a la vez.
Para líderes y responsables operativos, esto tiene que ver principalmente con el control y la gestión del ciclo de vida. Cuando Recursos Humanos registra la baja de alguien, deshabilitar la cuenta de identidad puede cortar de inmediato el acceso a múltiples servicios conectados. Cuando alguien cambia de rol, las actualizaciones en el directorio pueden propagarse a las aplicaciones que dependen del proveedor de identidad. Cuando se necesita una autenticación más sólida para sistemas sensibles, a menudo es posible aplicarla de forma centralizada en el inicio de sesión, en lugar de confiar en que cada proveedor implemente el mismo estándar correctamente.
Esto también es relevante en entornos con IA. Muchas organizaciones conectan ahora a su personal con asistentes internos, herramientas de conocimiento, copilotos y plataformas SaaS que contienen material interno valioso. Si esos servicios confían en el proveedor de identidad corporativo a través de SAML, la empresa puede mantener la política de autenticación, el MFA y el desaprovisionamiento en un único lugar, lo cual es mucho más seguro que gestionar cuentas locales separadas para cada aplicación.
No obstante, el límite es importante. SAML ayuda a un proveedor de servicios a confiar en que un proveedor de identidad ha autenticado a una persona. No define todo el modelo de permisos. Un usuario puede acceder mediante SAML y aun así tener derechos incorrectos, roles excesivos o privilegios obsoletos dentro de la aplicación. El inicio de sesión centralizado no equivale al mínimo privilegio centralizado.
Cómo funciona
Un flujo web SAML habitual comienza cuando un usuario abre una aplicación SaaS. Esa aplicación, actuando como proveedor de servicios, detecta que el usuario aún no tiene una sesión local. Envía una solicitud de autenticación al proveedor de identidad. El usuario inicia sesión allí, posiblemente con MFA, y el proveedor de identidad crea una respuesta SAML que contiene una aserción SAML. La aserción está firmada digitalmente para que el proveedor de servicios pueda verificar que proviene de una fuente de confianza y que no fue modificada en tránsito.
Dentro de la aserción hay varios elementos clave. Normalmente hay un sujeto que identifica al usuario, una declaración de autenticación que indica que el usuario fue autenticado e incluye la hora y el método, y puede haber también declaraciones de atributos, como nombre, dirección de correo electrónico, departamento o número de empleado. Suele haber también condiciones, entre ellas para quién está destinada la aserción y durante cuánto tiempo es válida.
Esas condiciones no son meros detalles técnicos. La restricción de audiencia indica a la aplicación receptora para qué proveedor de servicios estaba destinada la aserción; el proveedor de servicios debe rechazar una aserción destinada a una audiencia diferente. Los campos de vigencia como NotBefore y NotOnOrAfter impiden que las aserciones sean válidas indefinidamente. Los campos InResponseTo y recipient ayudan a vincular la respuesta al flujo original y al destino.
La confianza depende de la configuración. El proveedor de servicios debe saber en qué proveedor de identidad confía y qué certificado de firma o metadatos utilizar para la validación. Tanto el proveedor de identidad como el proveedor de servicios necesitan metadatos precisos, endpoints correctos, certificados correctos y atributos acordados. Si se rota un certificado tarde, la confianza se rompe. Si se publican atributos incorrectos, la aplicación puede aprovisionar cuentas de forma errónea. Si no se validan firmas, audiencia o caducidad, no se tiene realmente seguridad federada, sino una suposición costosa.
Ejemplos
Imaginemos una firma de servicios profesionales que utiliza seis aplicaciones en la nube: Microsoft 365, software de Recursos Humanos, una plataforma de tickets, una herramienta de gastos, una wiki y una consola de administración de un portal de clientes. Antes de SAML, cada sistema tiene cuentas locales separadas. El proceso de baja depende de seis tareas manuales y habitualmente se omiten dos. Tras integrar esas aplicaciones en el proveedor de identidad corporativo, una identidad de personal deshabilitada interrumpe el acceso normal en todo el entorno de forma mucho más fiable. Los proveedores de servicios siguen manteniendo sus propias sesiones y roles, pero la puerta principal de inicio de sesión está centralizada.
Otro ejemplo es el proceso de incorporación. Un nuevo empleado se une al equipo de soporte. Recursos Humanos crea el registro del personal, el directorio asigna los atributos de departamento y correo electrónico, y el proveedor de identidad se convierte en la fuente de inicio de sesión para la suite de soporte. La plataforma de soporte recibe una aserción SAML con los atributos de usuario acordados y crea o actualiza la cuenta local automáticamente. Esto reduce la fricción operativa, pero solo si la asignación de atributos es correcta. Si se envía un valor de departamento o un feed de privilegios incorrecto, la persona puede acabar en el grupo de acceso equivocado.
Un tercer ejemplo es el MFA reforzado para SaaS sensible. Un sistema financiero acepta SAML del IdP corporativo. La empresa decide que el personal ordinario puede usar MFA con aplicación de autenticación, pero los aprobadores de finanzas y los administradores de nóminas deben usar un inicio de sesión resistente al phishing. Como la aplicación confía en el IdP a través de SAML, la empresa normalmente puede aplicar ese requisito en el IdP en lugar de pedirle al proveedor financiero que gestione una pila de inicio de sesión separada.
También hay un ejemplo de mala configuración que merece atención. Un equipo federa varias aplicaciones a través de SAML pero mantiene cuentas locales antiguas como alternativa "por si acaso". Dos años después, la cuenta de administrador local de un contratista sigue activa en una plataforma SaaS, a pesar de que el contratista se marchó hace tiempo. Esto no es un fallo de SAML en el sentido del protocolo: es un fallo de gobernanza causado por una migración incompleta y una disciplina deficiente en la gestión de bajas. SAML puede centralizar el inicio de sesión, pero solo si se retiran o gobiernan realmente las vías locales que permanecen.
Malentendidos frecuentes
Un malentendido habitual es que SAML es simplemente "SSO". SSO es la experiencia de usuario de iniciar sesión una sola vez y acceder a múltiples aplicaciones. SAML es uno de los estándares que puede contribuir a ofrecer esa experiencia. Están relacionados, pero no son idénticos.
Otro malentendido es que SAML gestiona todos los permisos. No es así. Las aserciones SAML pueden transportar atributos que ayudan en las decisiones de acceso, pero no sustituyen al modelo de roles propio de la aplicación, la lógica de aprobación ni las revisiones de privilegios. Un inicio de sesión SAML limpio puede igualmente asignar a alguien un rol local con privilegios excesivos si las asignaciones son descuidadas.
Algunos equipos también asumen que, como el proveedor de identidad realizó el MFA, todos los servicios posteriores son ahora seguros por defecto. Eso solo se cumple si el proveedor de servicios valida las aserciones correctamente, si las políticas de inicio de sesión son realmente suficientemente sólidas para el riesgo y si no se han dejado atrás vías de inicio de sesión alternativas.
También es fácil exagerar la diferencia entre SAML y OAuth. En la práctica, resuelven problemas principales distintos. SAML se usa ampliamente para la federación empresarial y el SSO basado en navegador hacia aplicaciones. OAuth trata sobre la autorización delegada a APIs y recursos. OpenID Connect añade identidad sobre OAuth. Existe solapamiento en los sistemas reales, pero sustituir una explicación por la otra suele confundir a quienes no son especialistas.
Por último, a veces se piensa que la configuración de certificados es solo fontanería. En SAML, la confianza en los certificados es un control de seguridad central. Si el proveedor de servicios confía en el certificado de firma incorrecto o no actualiza los metadatos de forma segura, un atacante o una mala configuración pueden socavar todo el esquema.
Riesgos y límites
El mayor riesgo en SAML es la confianza mal depositada. El proveedor de servicios elige confiar en las declaraciones del proveedor de identidad, por lo que la validación de firmas, la gestión de certificados y la administración de metadatos son elementos centrales, no opcionales. Si el proveedor de servicios acepta respuestas sin firmar o con validación deficiente, o si confía en el certificado incorrecto, el protocolo queda reducido a una apariencia.
La validación de aserciones es otro límite crítico. Las aserciones firmadas correctamente siguen necesitando comprobaciones adecuadas de emisor, audiencia, destinatario, caducidad y repetición. Una aserción válidamente firmada destinada a una aplicación no debe ser aceptada por otra. Una aserción previamente válida no debe crear una sesión nueva una vez caducada. Una respuesta no debe volverse reutilizable solo porque el proveedor de servicios nunca compruebe la unicidad.
La publicación de atributos genera un riesgo más operativo. Los equipos suelen empezar enviando muchos atributos porque parece más sencillo que diseñar con cuidado. Eso puede filtrar más datos personales de los necesarios o crear un aprovisionamiento de cuentas frágil que depende de valores que nadie gobierna bien. Una publicación de atributos mínima y deliberada suele ser más segura que "enviar todo y ver qué hace la aplicación".
El ciclo de vida de los certificados es otro punto de dolor práctico. La confianza en SAML depende a menudo de certificados de firma y URLs de metadatos. Si la rotación no está gestionada, las aplicaciones fallan un lunes por la mañana y alguien se ve tentado a aplicar una solución temporal insegura. Si los metadatos se entregan o actualizan de forma insegura, la confianza puede verse comprometida. Si las claves privadas de firma están mal protegidas, un atacante puede generar aserciones que los proveedores de servicios podrían aceptar.
También existe un límite de gobernanza tras el inicio de sesión. SAML puede facilitar la eliminación centralizada del acceso, pero los roles locales obsoletos dentro del proveedor de servicios pueden persistir. Una persona que cause baja puede perder el inicio de sesión SAML y aun así conservar claves de API, cuentas de servicio locales o privilegios de administrador previamente aprovisionados dentro de la aplicación si las revisiones son deficientes.
Para las organizaciones del Reino Unido, SAML puede contribuir a un control más limpio sobre el acceso del personal a sistemas que contienen datos personales, pero no es un sello de cumplimiento. Sigue siendo un mecanismo de federación e inicio de sesión. Siguen siendo necesarias las revisiones de privilegios, el registro de actividad, el diseño de roles a nivel de aplicación y los controles del ciclo de vida.
Qué hacer a continuación
Comience por identificar qué aplicaciones empresariales deben confiar en el proveedor de identidad corporativo y cuáles siguen funcionando con inicios de sesión locales. Ese inventario importa más que los debates abstractos sobre protocolos. Si la aplicación contiene datos personales sensibles, operaciones financieras, comunicaciones con clientes o conocimiento interno para herramientas de IA, conviene preguntarse si realmente debe seguir teniendo una base de datos de contraseñas separada.
A continuación, revise el proceso de altas, cambios y bajas en torno a cada aplicación federada. ¿Se asignan los roles correctamente? ¿Siguen existiendo cuentas locales de respaldo? ¿Se eliminan correctamente los contratistas y el personal temporal? El inicio de sesión centralizado solo resulta rentable cuando los controles del ciclo de vida son igualmente centrales y verificados.
Después, revise la propia configuración de federación. Pregunte quién es responsable de la rotación de certificados, cómo se distribuyen los metadatos, cómo se monitoriza el fallo de aserciones y si se realizan pruebas negativas. En lenguaje claro: ¿sabe que la aplicación rechaza las aserciones incorrectas, o solo sabe que los usuarios válidos pueden seguir iniciando sesión?
Tras eso, reduzca la publicación innecesaria de atributos. Envíe la información mínima de usuario que el proveedor de servicios realmente necesita. Eso es más limpio para la privacidad, más sencillo para las operaciones y menos frágil cuando cambian los campos del directorio.
Por último, mantenga el límite claro para las partes interesadas. Use SAML para el inicio de sesión de confianza y la federación. Use el diseño de roles, RBAC o ABAC, revisiones periódicas de acceso y gobernanza de aplicaciones para lo que ocurre después del inicio de sesión. Esa distinción evita una cantidad sorprendente de confusión y de confianza mal depositada.
¿Tiene alguna pregunta o sugerencia, o desea saber cómo investigamos y revisamos estas guías? Lea sobre nuestros estándares editoriales y cómo contactarnos.
Preguntas frecuentes
¿Está SAML obsoleto?
SAML es anterior a algunos estándares de identidad más recientes, pero "más antiguo" no significa irrelevante. Sigue siendo ampliamente utilizado para el SSO empresarial en aplicaciones SaaS, especialmente en entornos de trabajo. La pregunta más pertinente es si se adapta al caso de uso. Para el acceso del personal basado en navegador a aplicaciones empresariales, a menudo sigue siendo adecuado. Para la delegación de API y los patrones móviles modernos, OAuth y OpenID Connect suelen ser más naturales.
¿Significa SAML que podemos desactivar todas las cuentas locales en todas las aplicaciones?
Ese suele ser un buen objetivo, pero no siempre es una realidad inmediata. Algunas aplicaciones mantienen cuentas de emergencia locales, identidades de servicio o credenciales específicas para API. Lo importante es saber qué permanece y gobernarlo deliberadamente. El fallo habitual es asumir que la federación resolvió el problema completo mientras las cuentas locales de respaldo, los administradores antiguos o los tokens no gestionados siguen existiendo fuera de la vía SAML.
Si usamos SAML, ¿seguimos necesitando MFA?
Generalmente sí, y a menudo más que antes. SAML centraliza la confianza en el proveedor de identidad, lo que significa que la autenticación que tiene lugar allí se vuelve más importante, no menos. Un diseño SAML sólido suele combinar la federación con un MFA robusto en el proveedor de identidad, especialmente para usuarios con privilegios y aplicaciones sensibles. La federación sin autenticación sólida simplemente centraliza un inicio de sesión débil.
Fuentes
SAML 2.0 Technical Overview (OASIS). Plain-English description of SAML participants, web SSO flow, assertions, attributes, signed responses, conditions and federation use cases.
Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0 (OASIS). Formal specification background for assertions, statements and conditions.
Digital Identity Guidelines: Federation and Assertions (NIST). Federation concepts, assertions, identity provider and relying party terminology.
Guide for Relying Parties (NIST). Practical guidance on validating signatures, expirations, audience parameters, replay protections and metadata.
Using Software as a Service (SaaS) securely (NCSC). Operational context for SaaS onboarding, offboarding, authentication and permissions.
Access control (ICO). UK-style access review, privileged access and joiner/mover/leaver discipline.