¿Qué es SAML?

Cada vez más compañías apuestan por SAML, una excelente solución completa para la administración de identidad federada (FIM), que permite integrar el inicio de sesión único o Single Sign-on (SSO), un proceso de autentificación única que permite utilizar varias aplicaciones al mismo tiempo. Los componentes individuales de SAML, entre los cuales encontramos una base de datos central de usuarios y seis protocolos diferentes, proporcionan todas las funciones relevantes para describir y transferir características de seguridad.

SAML (Security Assertion Markup Language) es un estándar de código abierto basado en XML que permite el intercambio de información, tanto de autenticación como de autorización entre diferentes partes: un identity provider (proveedor de identidad) y un service provider (proveedor de servicios).

Por un lado, un proveedor de servicios necesita la autenticación del proveedor de identidad para otorgar autorización al usuario. Salesforce suele ser proveedor de servicios, ya que dependen de un proveedor de identidad para la autenticación del usuario. Por otro lado, un proveedor de identidad realiza la autenticación de que el usuario final es quien dice ser y envía esos datos al proveedor del servicio junto con los derechos de acceso del usuario al servicio. Un ejemplo es OKTA, uno de los líderes en el suministro de soluciones de identidad.

Autenticación SAML

Así, la autenticación SAML es el proceso por el cual se verifica la identidad y las credenciales del usuario (contraseña, autenticación de dos factores, etc.). La autorización SAML es la que le dice al proveedor de servicios qué acceso otorga al usuario autenticado.

Los componentes SAML

SAML tiene diversas utilidades. Una de sus funciones es la de hacer declaraciones sobre las propiedades y autorizaciones de un usuario para otros usuarios o empresas asociadas, pero en especial sobre aplicaciones, es decir, a los «proveedores de servicios». Esto es posible gracias a que el identity provider, base de datos central en la que se almacena la correspondiente información del usuario, utiliza aserciones en un formato XML. Pero además, cuenta con otros componentes, como protocolos, enlaces y perfiles, que explicamos a continuación.

Aserciones

Una aserción SAML es el documento XML creado por el proveedor de identidad que envía al proveedor de servicios, y puede contener una o más declaraciones. De hecho, existen tres tipos diferentes de aserciones SAML, que se especifican en SAML 2.0: autenticación, atributo y decisión de autorización.

  • Authentication statements: el identity provider informa a la aplicación que el usuario se ha autenticado mediante declaraciones de autenticación. Este tipo de declaración también proporciona información en una afirmación sobre cuándo se realizó la autenticación y qué método se utilizó.
  • Attribute statements: las declaraciones de atributos son atributos que están vinculados al usuario respectivo y se pueden comunicar a la aplicación utilizando el token SAML correspondiente.
  • Authorization decision statements: cuando las declaraciones de decisión de autorización se incluyen en una aserción SAML, al usuario se le ha otorgado acceso a recursos específicos o se le ha denegado el acceso a recursos específicos.

Cada una de las aserciones también recibe una firma digital, la cual debe ser verificada por el proveedor que accede al servicio. Esta es la forma mediante la que se garantiza la integridad y autenticidad del token SAML, que es el nombre que recibe la aserción tras haber sido firmada. Una vez se ha procedido a la correcta verificación, es el proveedor de servicios quien analiza el contenido real, con la finalidad de decidir, si corresponde, el tipo de acceso que se le otorga al usuario.

Protocolos

La especificación SAML 2.0 define un conjunto de protocolos de consulta / respuesta. A través de ellos, la aplicación puede solicitar o consultar una aserción, o bien solicitar a un usuario que se autentifique. Estos son los siguientes protocolos:

  • Authentication request protocol: el protocolo de solicitud de autenticación define mensajes de tipo <AuthnRequest> que son necesarios para consultar aserciones con declaraciones de autenticación para un usuario seleccionado. En base a este protocolo, la información se transfiere de la base de datos al proveedor de servicios, generalmente utilizando un «Perfil SSO del navegador web SAML 2.0».
  • Assertion query and request protocol: para consultas que se pueden usar para recuperar aserciones SAML en general, el marco contiene el protocolo de consulta y solicitud de afirmación. Las aserciones pueden consultarse en función de diversos parámetros, como los tipos de declaraciones que contiene.
  • Single logout protocol: el protocolo de cierre de sesión único define consultas que inician un cierre de sesión casi simultáneo de todas las sesiones activas de un usuario. El usuario, el proveedor de identidad o el proveedor de servicios pueden enviar este tipo de mensajes.
  • Artifact resolution protocol: si los mensajes SAML deben transportarse por separado a través de un canal seguro o en un tamaño que ahorre recursos, se utiliza el protocolo de resolución de artefactos. Le permite enviar referencias a aserciones, también llamadas artefactos, que son mucho más pequeños que el mensaje real. El registro también le permite resolver estas referencias para recibir el mensaje original.
  • Name identifier management protocol: este protocolo proporciona medios para cambiar el valor del nombre o el formato de una identidad de usuario. La solicitud puede ser escrita por el proveedor de servicios o el proveedor de identidad. También puede usar el protocolo de administración del identificador de nombre para eliminar los enlaces entre los proveedores de servicios e identidades que se crearon para autenticar la identidad del usuario original.
  • Name identifier mapping protocol: el protocolo de asignación de identificador de nombre define mensajes de consulta y respuesta para la comunicación entre dos proveedores de servicios. Según este tipo de mensaje, una aplicación puede consultar un identity provider para que un usuario acceda a otra aplicación.

Bindings

Las asignaciones de mensajes SAML en los protocolos estándar de mensajería o comunicación se denominan «enlaces de protocolo SAML» o simplemente «enlaces». Por ejemplo, el enlace SOAP define cómo se pueden intercambiar mensajes SAML dentro de entornos SOAP, mientras que el enlace de redireccionamiento HTTP define cómo se pueden transportar los mensajes del protocolo SAML mediante el reenvío HTTP. Otros enlaces que ya están predefinidos en SAML 2.0:

  • Reverse SOAP Binding
  • HTTP POST Binding
  • HTTP Artifact Binding
  • SAML URI Binding

Perfiles

Una de las principales cualidades de SAML es su gran flexibilidad, que facilita su uso para una amplia variedad de propósitos. No obstante, hay que tener en cuenta que esa flexibilidad puede ser la causa de que algunas aplicaciones no lo admitan. Aunque en estos casos existe una solución que consiste en limitarla. La forma de hacerlo es usar los llamados perfiles. En general, un perfil de SAML define restricciones y / o extensiones en apoyo del uso de SAML para una aplicación en particular; su finalidad es mejorar la interoperabilidad al eliminar parte de la flexibilidad inevitable en un estándar de uso general. Por ejemplo, el «SAML 2.0 Web Browser SSO Profile», uno de los perfiles más destacados, contiene todos los componentes esenciales para definir la comunicación de los requisitos de autenticación SAML entre los proveedores de identidad y servicios. Además, de esto, se ofrecen otros perfiles muy interesantes, que pueden ser de mucha utilidad:

  • Enhanced Client and Proxy (ECP) Profile.
  • Identity Provider Discovery Profile.
  • Single Logout Profile.
  • Name Identifier Management Profile.
  • Artifact Resolution Profile.
  • Assertion Query/Request Profile.
  • Name Identifier Mapping Profile.

Estos son los principales cambios en SAML 2.0

SAML se desarrolló en 2001 por los servicios de seguridad del comité técnico del consorcio OASIS (Organization for the Advancement of Structured Information Standards). Su primera versión, SAML v1.0, se publicó en noviembre de 2002. En 2005, a partir de varias adaptaciones, aparecieron las revisiones llamadas SAML 2.0 y 2.1.

Con las últimas versiones, aplicaron importantes cambios y se añadieron nuevas características derivadas del marco de la federación de identidad de la alianza libertad (ID-FF) 1.2 y de la arquitectura shibboleth, como las que señalamos a continuación:

  • Eliminación de algunos elementos obsoletos como <AuthorityBinding> o <RespondWith>
  • Implementación de firma XML y encriptación XML (según W3C)
  • Reemplazo del atributo AssertionID con un atributo de ID XML general
  • Introducción de la gestión de sesiones para admitir el cierre de sesión automático de todas las aplicaciones (por ejemplo, durante ausencias prolongadas.
  • Adaptación de los metadatos para simplificar el uso de SAML (por ejemplo, el proveedor de identidad y el proveedor de servicios ahora también están marcados en los metadatos).
  • El uso de mecanismos que permiten a los proveedores comunicar políticas y configuraciones de privacidad.
  • Soporte mejorado para dispositivos móvil.
  • Implementación de los registros ya enumerados (solo existía el protocolo de consulta y solicitud de aserción en SAML 1.0 y 1.1)
  • Optimización de perfil (por ejemplo, Fusión de los perfiles «navegador / artefacto» y «navegador / publicación» en el «SAML 2.0 Web Browser SSO Profile»).

¿Para qué es adecuado el estándar SAML?

El estándar SAML resulta muy útil para implementar una instancia de autenticación central en función del lenguaje de marcado. Una de sus grandes ventajas es que ofrece un elevado grado de eficiencia y un alto estándar de seguridad. En particular, se minimiza el número de posibles fugas de seguridad, gracias a que las aplicaciones individuales no tienen que almacenar ni sincronizar ningún dato del usuario. De esta forma se logra uno de los objetivos primordiales, que es el compatibilizar un alto grado de seguridad con el mejor nivel posible de facilidad de uso.

Su uso es muy recomendable en diferentes ámbitos, y se puede utilizar tanto para los procesos internos de solicitud de la empresa como para varios servicios web como, por ejemplo, los de banca en línea o aplicaciones móviles. Como cliente, notará que está tratando con varias aplicaciones diferentes cuando usa este tipo de servicios ya que, aunque el usuario, en realidad, acceda a más de un sistema de fondo. SAML creará la ilusión de que se ha ingresado en un solo programa.

SAML es uno de los protocolos usados por los diferentes productos de OKTA, una de las mejores soluciones de autenticación moderna. OKTA proporciona herramientas que facilitan la identificación, autenticación y autorización mediante soluciones Single Sign-On (SSO), Directorio Universal (UD), Autenticación Adaptativa Multifactor (Adaptative MFA), Acceso Condicional, etc.

En NTS, como partners de OKTA para España, ofrecemos servicios de consultora, implantación e integración y migración de los sistemas informáticos ‘legacy’.