Simplificar la integración de aplicaciones SAML para desarrolladores

Inicio de sesión único (SSO) es clave para las aplicaciones modernas, y SAML permite una autenticación segura y amigable a través de sistemas de identidad empresarial. Esta guía simplifica SAML para desarrolladores y diseñadores con pasos claros y ejemplos prácticos para ayudarte a implementarlo de manera eficiente.

¿Qué son SAML SSO y las aplicaciones SAML?#

Security Assertion Markup Language (SAML) es un estándar basado en XML utilizado para intercambiar datos de autenticación y autorización entre dos actores clave: el Proveedor de Identidad (IdP) y el Proveedor de Servicios (SP). Es una solución común para el inicio de sesión único (SSO) en las organizaciones, facilitando la vida a los usuarios empresariales al permitirles iniciar sesión una vez y acceder a múltiples aplicaciones.

Proveedor de Identidad (IdP) es responsable de gestionar y verificar las credenciales del usuario, como nombres de usuario y contraseñas. Cuando un usuario intenta acceder a un servicio protegido, el IdP confirma su identidad y envía esta confirmación al servicio.

• Ejemplo: Imagina que trabajas para una gran empresa que utiliza Microsoft Azure AD para gestionar cuentas de empleados. Cuando quieres iniciar sesión en Salesforce, Azure AD actúa como el IdP. Verifica tus credenciales e informa a Salesforce que estás autorizado para usarlo.

Proveedor de Servicios (SP) es la aplicación o servicio al que los usuarios realmente intentan acceder. Depende del IdP para manejar la carga pesada de la autenticación.

• Ejemplo: Continuando con nuestro escenario anterior, Salesforce es el SP. Depende de Microsoft Azure AD (el IdP) para confirmar tu identidad. Una vez que Azure AD avala tu identidad, Salesforce te da acceso.

Cuando se habla de una “aplicación SAML,” generalmente se refiere al SP.

Usando el protocolo SAML, puedes configurar tu servicio como un IdP para admitir integraciones de aplicaciones (como Azure Ad / Google Workspace); o como un SP (como Salesforce / Slack) para admitir SSO para usuarios.

Una SAML Assertion es el corazón del protocolo SAML. Es una “nota” digital creada por el IdP y enviada a un SP que dice, “He confirmado la identidad de este usuario.” A continuación, cubriremos cómo funciona el proceso tanto para IdP como para SP.

Cuando actúas como un Proveedor de Identidad SAML#

Cuando tu servicio funciona como el IdP, habilitas la autenticación SAML a través de múltiples aplicaciones. Esto permite a los usuarios acceder a varios servicios a través de una sola identidad empresarial.

Aquí tienes un típico flujo de trabajo de SAML SSO para un IdP:

1. El usuario intenta acceder a una aplicación (SP), como Salesforce.
2. La aplicación redirige al usuario a tu IdP para autenticación.
3. El usuario ingresa sus credenciales en la página de inicio de sesión de tu IdP.
4. El IdP verifica las credenciales.
5. Si las credenciales son verificadas, el IdP envía una assertion SAML de regreso al SP.
6. El SP procesa la assertion, confirma su validez y otorga acceso al usuario.

Cuando actúas como un Proveedor de Servicios SAML#

Si tu servicio es el SP, te integrarás con varios proveedores de identidad para proporcionar a tus usuarios la capacidad de SSO. Esto permite que usuarios empresariales de diferentes organizaciones o inquilinos accedan de manera segura y eficiente a tu aplicación.

Aquí tienes un flujo de trabajo para SSO iniciado por el SP:

1. El usuario intenta iniciar sesión en tu aplicación.
2. Tu aplicación genera una solicitud SAML y redirige al usuario a la página de inicio de sesión del IdP.
3. El usuario inicia sesión en el IdP (o salta este paso si ya está conectado).
4. El IdP verifica la identidad del usuario y, una vez confirmada, empaca los detalles del usuario en una assertion SAML.
5. El IdP envía la assertion de regreso a tu aplicación.
6. Tu servicio verifica la assertion. Si es válida, el usuario obtiene acceso a tu aplicación.

Parámetros clave en SAML SSO#

Para una integración SAML SSO exitosa, tanto IdPs como SPs deben compartir parámetros específicos. Aquí tienes lo esencial:

Parámetros del IdP#

1. IdP Entity ID: Un identificador único para el IdP en las comunicaciones SAML, como una etiqueta de nombre digital.
2. SSO URL: El punto final de inicio de sesión (URL) donde el SP redirige a los usuarios para autenticación.
3. Certificado X.509: Una clave pública utilizada para firmar la assertion SAML, asegurando que sea segura. Este es el “sello” que verifica la autenticidad.

Consejo: Si tu IdP ofrece una URL de Metadata SAML, las cosas se hacen más fáciles. Esta URL contiene toda la información necesaria (como certificados, URLs de SSO y IdP Entity ID) en un solo lugar. Minimiza el riesgo de errores por copiar y pegar manualmente y elimina la molestia de actualizar manualmente los archivos de certificado.

Parámetros del SP#

1. SP Entity ID: El identificador único del SP, similar al IdP Entity ID.
2. Assertion Consumer Service (ACS) URL: Este es el punto final del SP donde el SP espera recibir la assertion SAML del IdP.
3. RelayState (Opcional): Utilizado para pasar datos durante el proceso SAML, como la URL que el usuario estaba intentando visitar originalmente.

Mapeo de atributos SAML y cifrado#

1. Formato NameID: Define el formato del identificador de usuario (por ejemplo, dirección de correo electrónico o nombre de usuario).
2. Atributos SAML: Estos son detalles adicionales del usuario, como roles, correo electrónico o departamento, que el IdP envía al SP.
   • Ejemplo: Si la assertion SAML firmada por el IdP incluye email ([email protected]), role (admin) y department (ingeniería). El SP puede usar role para asignar privilegios de administrador o department para agrupar al usuario dentro del equipo adecuado. Para obtener estos datos esenciales del usuario, tanto el IdP como el SP deben decidir cómo mapear los atributos. Por ejemplo, el IdP podría definir “department” como equipo, mientras el SP lo espera como grupo. Un mapeo adecuado asegura una comunicación fluida.
3. Assertions Encriptadas (Opcional): Para proteger datos sensibles de autenticación, las assertions SAML pueden ser encriptadas.
   • Rol del IdP: Cifra la assertion usando la clave pública del SP.
   • Rol del SP: Desencripta la assertion con su clave privada para leer los detalles del usuario.

A estas alturas, deberías tener la información necesaria para configurar una conexión SAML. Para integrar Salesforce (Proveedor de Servicios) con Azure AD (Proveedor de Identidad), sigue estos pasos:

• Obtén el IdP Entity ID, SSO URL y el certificado de Azure AD y configúralos en Salesforce.
• Proporciona el SP Entity ID y ACS URL de Salesforce a Azure AD.

Logto hace la integración SAML sencilla#

Logto puede actuar como un IdP o un SP para admitir SAML SSO para tus aplicaciones.

Usando Logto como un IdP SAML#

Logto permite que otras aplicaciones confíen en él para la autenticación de identidad federada y admite autenticación multi-factor (MFA) para una seguridad mejorada.

1. Crear una aplicación Logto Ve a Logto Console > Applications y crea una nueva aplicación SAML.
2. Configurar parámetros SAML Configura la aplicación con el Assertion Consumer Service URL y SP Entity ID del Proveedor de Servicios (SP).
3. Proporcionar URL de metadata Logto proporciona una URL de Metadata IdP que los SP pueden usar para recuperar automáticamente detalles esenciales, como URLs de SSO y certificados.
4. Configuración avanzada (Opcional)
   • Puedes crear múltiples nuevos certificados con huellas digitales y establecer fechas de expiración, pero solo un certificado puede estar activo a la vez.
   • Modifica el formato Name ID para adaptarlo a tus requisitos empresariales.
   • Habilita cifrado de assertions SAML copiando y pegando el certificado x509 de tu proveedor de servicios para cifrar las assertions.
5. Mapear atributos (Opcional) Personaliza fácilmente cómo se comparten los atributos de usuario con los Proveedores de Servicios (SPs).

Para una guía detallada, visita la documentación oficial aquí: SAML App

Usando Logto como un SP SAML#

Logto también se integra con cualquier IdP empresarial a través de los protocolos SAML u OIDC. Ya sea que estés habilitando SSO iniciado por SP para tus páginas de inicio de sesión unificadas o configurando SSO iniciado por IdP, el proceso es sencillo.

1. Crear un conector empresarial Ve a Logto Console > Enterprise SSO y crea un nuevo Conector Empresarial. Selecciona SAML como el estándar de protocolo.
2. Configurar parámetros SAML Proporciona la URL de metadata o el archivo XML de metadata de tu IdP. Si la metadata no está disponible, cambia a configuración manual ingresando el IdP Entity ID, SSO URL y subiendo el certificado de firma.
3. Compartir el ACS URL y SP Entity ID Proporciona el ACS URL y SP Entity ID de Logto a tu IdP para completar la configuración de la integración.
4. Mapear atributos (Opcional) Configura mapeos de datos de usuario, como correo electrónico o nombres, para asegurar que la información se pase correctamente entre el IdP y Logto.
5. Agregar dominios de correo electrónico empresariales En la pestaña “SSO Experience” para el conector empresarial, agrega uno o más dominios de correo electrónico. Esto asegura que solo los usuarios con los dominios especificados puedan autenticarse a través de SSO.
6. Habilitar SSO iniciado por IdP (Opcional) Habilita SSO iniciado por IdP solo si es requerido por tus clientes empresariales. Esta característica permite a los usuarios iniciar sesión en tus aplicaciones directamente desde el panel del IdP.

Para una guía detallada, visita la documentación oficial aquí: Enterprise SSO documentation.

Pensamientos finales#

SAML ofrece un método estandarizado y seguro para SSO, haciendo la autenticación más fluida. Logto simplifica el proceso ya sea que lo estés configurando como un IdP o SP. Con su interfaz fácil de usar y soporte tanto para versión en la nube como versión de código abierto, Logto elimina las complejidades de la integración SAML. Con solo configurar algunos parámetros, puedes conectar tus servicios a cualquier IdP o SP SAML y centrarte en crear excelentes experiencias para tus usuarios.