Cómo funciona la autenticación de SAML y por qué sigue siendo pertinente para los clientes empresariales

SAML 2.0 (Security Assertion Markup Language) es un estándar abierto creado para proporcionar el inicio de sesión único (SSO) entre dominios. En otras palabras, permite que un usuario se autentique en un sistema y acceda a otro proporcionando una prueba de su autenticación.

Aunque SAML se utiliza desde 2005, sigue siendo popular para la federación de identidades en aplicaciones B2B y B2E. Esta amplia adopción ha conducido a su éxito autoperpetuante. En general, si se quiere proporcionar un SSO sin fisuras entre las empresas y los negocios, hay que ser capaz de manejar SAML. De hecho, el protocolo SAML 2.0 se utiliza principalmente para aplicaciones empresariales y gubernamentales.

SAML utiliza XML para representar los datos de identidad del usuario y HTTP simple para los mecanismos de transporte de datos.

En este artículo, repasaremos qué es SAML y qué lo distingue de otros estándares de identidad; también veremos cómo un socio de gestión de identidades como Auth0 encaja en la ecuación.

SAML es un protocolo de autenticación basado en XML en el que los Proveedores de identidad (IdP) (entidades que gestionan y almacenan las credenciales de los usuarios) intercambian documentos XML firmados digitalmente (Aserciones de SAML) que permiten a un usuario final acceder a un Proveedor de servicios (SP), como la colección de aplicaciones que utiliza cada día en el trabajo o un sitio web.

El servicio que solicita y recibe los datos de los proveedores de identidad (IdP) se conoce como Parte de confianza (RP) y los datos de identidad del usuario, encapsulados en la aserción SAML, se presentan en forma de atributos, por ejemplo, dirección de correo electrónico, nombre, teléfono, etc.

Una analogía del mundo real sería el escenario de un viaje internacional. Piense en un viajero que desea venir de su país de origen a Estados Unidos. Cuando llega a la frontera, se le pide el pasaporte para autenticar y posiblemente autorizar su acceso. Si el viajero no tiene pasaporte, se lo remite al gobierno de su país para que obtenga uno.

Una vez que el viajero tiene su pasaporte, puede demostrar su identidad a los funcionarios de la frontera. Estos comprueban la validez del pasaporte y los datos de identidad que figuran en él y deciden si dejan pasar al viajero o no:

• el país de origen del viajero es el Proveedor de identidad
• los funcionarios de la frontera, que representan al gobierno de EE. UU., son la Parte de confianza,
• EE. UU. como país es el Proveedor de servicios
• el pasaporte es la Aserción de SAML

Considere que EE. UU. solo acepta pasaportes de países con los que ha hecho acuerdos preliminares.

Puede replicar este escenario del mundo real en un sistema informático.

Digamos que usted trabaja en una empresa que tiene múltiples aplicaciones, pero un punto centralizado para la autenticación de usuarios. Supongamos que un socio de la empresa tiene una organización similar, y para un proyecto específico, algunos empleados del socio necesitan acceder a una o más aplicaciones de su empresa. Usando SAML, después de una configuración preliminar que establece la confianza entre los dos sistemas, usted puede replicar el escenario de viaje internacional.

El empleado del socio intenta acceder a una de las aplicaciones de su empresa. Como ese usuario no pertenece a su empresa, el sistema de su empresa redirige al usuario al sistema del socio para obtener una prueba de identidad. El sistema del socio autentica al usuario y le proporciona una aserción de SAML. El sistema de su empresa comprueba esa afirmación y permite el acceso del usuario.

Con SAML, el flujo de trabajo de autenticación puede ser iniciado por el proveedor de servicios o el proveedor de identidad. La autenticación iniciada por el IdP podría ocurrir si un empleado está conectado a su tablero corporativo y quiere utilizar una herramienta comprada por la empresa en un sitio externo. En este caso, el IdP enviaría una aserción de SAML a través del navegador web para iniciar la sesión automáticamente.

La autenticación iniciada por el SP se produce si un empleado intenta iniciar la sesión en ese sitio externo (el SP) y el sitio lo redirige a su página de inicio de sesión corporativa de inicio de sesión único (SSO) para introducir sus credenciales y autenticarse. Tras la autenticación, el empleado es redirigido de nuevo al sitio externo con una aserción de SAML que demuestra su identidad.

En ocasiones, los desarrolladores se preguntan por qué deben implementar el protocolo SAML. ¿Qué hace que SAML valga la pena? Como se menciona en este tutorial técnico, los beneficios incluyen:

Estandarización: Al ser un estándar abierto, SAML hace posible la interoperabilidad de los sistemas:

Experiencia del usuario: Los usuarios pueden acceder a varios proveedores de servicios iniciando una sola sesión, sin necesidad de autenticación adicional, lo que permite una experiencia más rápida y mejor en cada proveedor de servicios. Esto también centraliza las cuestiones de gestión de contraseñas, como el restablecimiento y la recuperación.

Acoplamiento suelto de directorios: SAML no requiere que la información del usuario sea mantenida y sincronizada entre directorios.

Mayor seguridad: SAML proporciona un único punto de autenticación, que se produce en un IdP seguro. Al evitar la replicación de credenciales (cuentas sombra) y la sincronización, SAML reduce los puntos de ataque para el robo de identidades.

Costos reducidos para los proveedores de servicios: Con SAML, no tiene que mantener la información de la cuenta en varios servicios. El proveedor de identidad soporta esta carga.

Mayor cumplimiento: En la Era de la Privacidad de los Datos, la capacidad de recibir atributos sobre la marcha y olvidarlos cuando ya no son necesarios reduce la responsabilidad de su organización: ya no es necesario crear cuentas en la sombra para realizar el trabajo

Los desarrolladores pueden dar fe de que intentar implementar SAML 2.0 en casa puede ser complicado, y es fácil dejar inadvertidamente grietas en la firma XML y el cifrado que dejan una aplicación vulnerable a los atacantes. Sin embargo, un socio de identidad como Auth0 puede hacer que la autenticación SAML sea simple y segura.

Usando Auth0 inicio de sesión universal, puede rápidamente configurar SAML y ofrecerlo a sus clientes empresariales. Cuando se utiliza Auth0, se obtienen todas las ventajas de SAML, pero se descarga la carga y el riesgo de ser el único proveedor de identidades.

Auth0 puede conectarse a cualquier lenguaje o API. Puede actuar como proveedor de identidad, proveedor de servicios, o ambos.

Cuando se implementa un SP de SAML y se utiliza Auth0 como proveedor de identidad, los usuarios son redirigidos a Auth0 para iniciar sesión, y Auth0 los autentica. Auth0 es agnóstico en cuanto a la conexión de autenticación y puede utilizar proveedores sociales, bases de datos, directorios LDAP (como Active Directory), u otros IdP de SAML.

Cuando su aplicación necesita hablar con un SP de SAML utilizando Auth0, este traduce sus peticiones en una Solicitud de autenticación de SAML y la reenvía a un IdP de SAML. No importa el protocolo que esté utilizando para hablar con Auth0.

El uso de Auth0 como su proveedor de IdaaS le permite ofrecer a los usuarios múltiples proveedores de identidad. De este modo, los usuarios de una organización pueden iniciar la sesión con sus credenciales de G-Suite, mientras que otros pueden utilizar una conexión a la base de datos.

Para una empresa de SaaS que intenta atraer a clientes empresariales, ofrecer SAML 2.0 además de otros protocolos, como OAuth y OpenID Connect, es una forma sencilla de demostrar que se es lo suficientemente flexible como para satisfacer las necesidades de los clientes que llevan años utilizándolo.

Siga leyendo en nuestra página de Introducción a IAM para explorar más temas en torno a la gestión de identidades y accesos.