- SAML (Single Assertion Markup Language) es un estándar que define reglas para intercambiar mensajes relacionados con la seguridad en formato XML
- Se usa principalmente para el intercambio de mensajes entre 3 o más entidades independientes
- Un escenario común es cuando están involucrados dos sistemas de software creados por compañías distintas y un usuario
- Los dos sistemas necesitan intercambiar información sobre el usuario
- También se puede hacer una integración personalizada, pero es difícil de mantener
- SAML simplifica el trabajo de integración complejo al hacer que los sistemas sigan las mismas reglas
Formato de los mensajes SAML
- Los mensajes SAML están en formato XML
- Define la sintaxis de los mensajes e indica cómo procesar su contenido de forma segura
- Por ejemplo, si recibes una etiqueta
<Response>, sabes que debes buscar una etiqueta <Assertion>
- Proporciona lineamientos sobre cómo se ve una firma digital y cómo deben procesarse los mensajes para evitar problemas de seguridad
La flexibilidad de SAML
- SAML fue diseñado con énfasis en la flexibilidad. En principio, se pueden hacer muchas cosas con SAML, pero esa flexibilidad también lleva a la complejidad
- La especificación de SAML tiene muchísimas excepciones, además de muchos if y ejemplos, lo que agrega casos límite
- Como SAML es antiguo, algunas personas aprovechan esa flexibilidad
- En entornos reales de operación, especialmente en sistemas legacy, a veces SAML se comporta de forma inusual
- Para la mayoría, la vida se vuelve más fácil si se enfocan solo en un subconjunto pequeño de SAML
Para qué se usa realmente SAML
- SAML se usa principalmente para Single Sign-On (SSO)
- SAML define algunos tipos extraños de SSO, pero en general se usa el Web Browser SSO Profile
- El usuario final primero se autentica en un sistema centralizado y luego accede a la aplicación de software que desea
- El usuario no se autentica directamente en la aplicación
- Por ejemplo, si alguna vez usaste Okta para acceder a tu correo electrónico, entonces usaste el Web Browser SSO Profile
Entidades involucradas en SSO
- En SSO participan 3 actores:
- Usuario: la persona que quiere usar la aplicación
- Proveedor de servicios (SP): la aplicación en sí
- Proveedor de identidad (IDP): el servicio central que el usuario usa para autenticarse
- El IDP de cada cliente puede verse como una base de datos. Lleva el registro de los datos de las personas
- Las empresas suelen usar el proveedor de identidad para asignar empleados a departamentos y otorgar distintos permisos
- Cada vez que se inicia sesión de un usuario mediante SAML, hay que obtener información desde el IDP. En SSO, normalmente se le pide al IDP que confirme la identidad del usuario
- Se necesita una relación de confianza preconfigurada con el IDP
- Todos los clientes que usan SAML SSO necesitan su propia configuración dentro de la aplicación
- Sin embargo, no se intercambian mensajes directamente con el IDP. En SAML SSO, el proveedor de servicios y el proveedor de identidad se comunican a través del navegador del usuario
Cómo interactúan las entidades en SAML
- Proceso típico de SAML SSO:
- El usuario intenta acceder a alguna parte de la aplicación desde un navegador web
- Se verifica si el usuario tiene un contexto de seguridad válido
- Como el usuario no tiene un contexto de seguridad válido, se muestra la página de inicio de sesión
- El usuario ingresa cierta información (por ejemplo, su correo electrónico), que se usa para determinar el método de inicio de sesión adecuado
- Se redirige al usuario a la dirección web del IDP y se envía un mensaje SAML al IDP a través del navegador del usuario
- El IDP muestra un mensaje pidiendo las credenciales del usuario. El usuario se autentica correctamente
- El IDP redirige de nuevo al usuario a la aplicación junto con un mensaje SAML que transmite información sobre la autenticación del usuario
- Se procesa el mensaje SAML y se determina que debe establecerse un contexto de seguridad para el usuario
- Se le concede al usuario acceso a la parte deseada de la aplicación
- También es posible iniciar el proceso de SAML SSO desde el proveedor de identidad
- En ese caso, se recibe una respuesta de autenticación sin haber enviado una solicitud de autenticación
- Al implementar soporte para SAML SSO, hay que estar preparado para el SSO iniciado por el IDP
Mensajes que se intercambian en SAML
- En SAML SSO, principalmente interesan 2 tipos de mensajes
- Al mensaje que va del proveedor de servicios al IDP se le llama solicitud SAML (request)
- Al mensaje que regresa del IDP al proveedor de servicios se le llama respuesta SAML (response)
- La solicitud SAML en realidad no es tan compleja. Basta con enviar XML mediante una redirección HTTP
- Se incluye un ID en la etiqueta
<AuthnRequest> para que el IDP pueda devolver un <Response> asociado con la solicitud original
- También se envían datos envueltos en la etiqueta
<Issuer> para indicarle al IDP quién eres
- La respuesta SAML es más complicada. Normalmente se envía mediante POST
<Response> envuelve conceptualmente varias etiquetas <Assertion><Assertion> envuelve claims sobre el usuario (quién es, cómo se autenticó ante el IDP, etc.)- Se procesa la Assertion para decidir si se debe iniciar sesión al usuario o no
Precauciones
- Aquí se omitieron muchos detalles, especialmente los importantes desde el punto de vista de la seguridad
- A menos que tengas un interés personal en SAML o una razón profesional para investigarlo a fondo, no se recomienda implementar por tu cuenta un inicio de sesión basado en SAML. Es una pérdida de tiempo
- Si quieres configurar SAML lo antes posible, ofrecemos SSOReady, un proyecto open source que abstrae SAML. Te ahorrará mucho tiempo y sufrimiento
Aún no hay comentarios.