SAML: introducción al estándar XML

La identidad federada (en inglés: Federated Identity Management) es una de las soluciones más importantes que permite desarrollar aplicaciones web y estructuras en la nube accesibles por varias empresas sin que por ello la seguridad se vea comprometida. Las políticas y protocolos estandarizados garantizan a los usuarios el acceso a varios servicios, aunque no compartan una base de datos local común. De esta forma, es posible integrar el inicio de sesión único o Single Sign-on (SSO), una solución cada vez más popular entre los usuarios. Este proceso de autentificación única nos permite utilizar varias aplicaciones al mismo tiempo. Muchas empresas confían en el estándar XML SAML (Security Assertion Markup Language) a la hora de poner en marcha este mecanismo de seguridad.

El Lenguaje de Marcado para Confirmaciones de Seguridad, conocido como SAML (en inglés: Security Assertion Markeup Language), es un estándar de código abierto basado en XML para el intercambio de datos de autentificación y autorización. SAML es un producto desarrollado por el comité técnico del grupo OASIS (Organisation for the Advancement of Structured Information Standards) en 2001. Su primera versión (SAML 1.0) se lanzó en noviembre de 2002., si bien con el paso del tiempo el equipo del proyecto ha realizado numerosos ajustes disponibles en las versiones revisadas SAML 2.0 y 2.1 (y en la 1.1). El estándar SAML está formado por varios componentes que aportan todas lasfunciones necesarias para definir y transmitir información de forma segura. SAML constituye, por lo tanto, un fundamento muy apropiado para la gestión de la identidad federada o Federated Identity Management (FIM).

SAML permite, entre otras cosas, realizar declaraciones sobre las propiedades y autorizaciones de un usuario respecto de otros usuarios o empresas asociadas, aunque especialmente respecto de una aplicación (que a veces reciben el nombre de service provider oproveedor de servicio cuando estamos hablando de SAML). Con este fin, el denominado identity provider o proveedor de identidad (base de datos central del usuario), donde se almacena toda la información de un usuario concreto, hace uso de aserciones o assertions en formato XML. Un conjunto de seis protocolos diferentes, además de bindings y perfiles son los otros componentes que forman parte de la arquitectura de verificación basada en el estándar SAML:.

Una aserción o assertion SAML puede incluir una o más declaraciones o statements sobre las propiedades (identidad, atributos) y los permisos de un usuario. El responsable de crearla es el proveedor de identidad correspondiente, es decir, la base de datos que corresponda al usuario, que utiliza XML como lenguaje de marcado. Cada aserción recibe una firma digital, que primero tiene que ser comprobada y verificada por el service provider o proveedor de servicios al que se desea acceder, es decir, por la aplicación pertinente. De esta forma, es posible garantizar la integridad y autenticidad de la aserción, que recibe el nombre, una vez firmada, de token SAML. Después de realizar la verificación, el proveedor de servicios analiza el contenido concreto y luego decide si otorga o no acceso al usuario y en caso afirmativo, qué tipo de acceso otorga.

El estándar SAML 2.0 especifica los tres tipos siguientes de declaraciones en la aserción:

• Authentication Statements: son expedidas por la entidad que ha llevado a cabo el proceso de autentificación del usuario. En una declaración de este tipo se recoge quién la ha emitido, el sujeto autentificado, el período de validez y otros datos relacionados con la autentificación. Nos referiremos a ellas también como declaraciones o afirmaciones de autentificación.
• Attribute Statements: contienen detalles específicos sobre el usuario y pueden ser comunicadas a la aplicación mediante el token SAML correspondiente. Nos referiremos a ellas también como declaraciones o afirmaciones de atributos.
• Authorization Decision Statements: recogen datos sobre lo que le está o no permitido hacer al usuario. Por ejemplo, si está o no autorizado a acceder a un determinado recurso. Nos referiremos a ellas también como declaraciones o afirmaciones de autorización.

La especificación SAML 2.0 establece una serie de protocolos de solicitud o respuesta con los que la aplicación puede, por ejemplo, solicitar una aserción o pedir a un usuario que se autentifique. En concreto, se utilizan los siguientes protocolos:

• Authentication Request Protocol: define mensajes del tipo <AuthnRequest>, que son necesarios para consultar aserciones con Authentication Statements de un usuario seleccionado. Generalmente, es un proveedor de servicios el que emite la solicitud y suele utilizar un perfil SAML 2.0 navegador Web SSO (más información en el apartado sobre los perfiles) y contestada por un proveedor de identidad tras haber completado con éxito un proceso de autentificación del usuario.
• Assertion Query y Request Protocol: es necesario para solicitudes con las que, en general, se pueden obtener aserciones SAML ya existentes. Es posible solicitar una aserción siguiendo distintos parámetros como, por ejemplo, que contenga unas declaraciones determinadas.
• Single Logout Protocol: define solicitudes que inician el cierre cuasi simultáneo de todas las sesiones abiertas pertenecientes a un mismo usuario. Este tipo de mensajes pueden enviarse directamente tanto al usuario como a un proveedor de identidad o de servicio. Este último suele considerarse cuando la sesión de un usuario ha expirado.
• Artifact Resolution Protocol: se utiliza para transportar los mensajes SAML por separado a través de un canal seguro o en un tamaño reducido para ahorrar recursos. Permite el envío de referencias y aserciones que también se denominan “artifact” y son considerablemente más pequeñas que el propio mensaje. El protocolo también permite borrar estas referencias para recibir el mensaje original.
• Name Identifier Management Protocol: este protocolo proporciona mecanismos para modificar el valor o el formato del nombre de un usuario. La solicitud puede proceder de un proveedor de servicio o de un proveedor de identidad. Además, este protocolo también puede utilizarse para eliminar aquellos enlaces entre proveedores de servicio y proveedores de identidad que fueron creados para autentificar la identidad del usuario original.
• Name Identifier Mapping Protocol: este protocolo define mensajes de solicitud y de respuesta para que dos proveedores de servicio puedan comunicarse. Basándose en este tipo de mensaje, una aplicación puede solicitar un identificador para un usuario al proveedor de identidad con el fin de acceder a otra aplicación.

Las especificaciones para “mapear” (en inglés: mapping) un protocolo SAML sobre un determinado protocolo de transporte reciben el nombre de binding. Se definen varios tipos, entre los que encontramos, por ejemplo, el SOAP Binding, que sirve para definir cómo los mensajes del protocolo SAML se intercambian, integrados en mensajes de SOAP, y especifica cómo dichos mensajes SOAP se transportan sobre HTTP. Por su parte, el HTTP Redirect Binding define cómo se pueden transportar mensajes del protocolo SAML a través del procedimiento de redirección HTTP. Podemos citar como ejemplo de otros tipos de bindings en el estándar SAML 2.0:

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

SAML es un estándar general y se caracteriza por su flexibilidad, lo que le permite poder ser utilizado como marco en muchos supuestos diferentes. Sin embargo, para que ciertas aplicaciones puedan ser compatibles con SAML, a veces es necesario restringir esa flexibilidad. Un perfil o profile se utiliza para combinar determinadas aserciones, protocolos y bindings para componer en la práctica un supuesto de uso concreto de la especificación SAML. Uno de los perfiles más utilizados es el ya mencionado SAML 2.0 Web Browser SSO Profile, que especifica el marco para poner en marcha la autentificación única SSO en SAML. Incluye todos los componentes necesarios para definir la comunicación de las garantías de autentificación SAML entre el proveedor de identidad y el proveedor de servicios, que son necesarias para la autentificación única en un navegador web. El estándar también define los siguientes perfiles adicionales:

• 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

Más de 24 empresas y organizaciones participaron en el diseño y desarrollo de la versión SAML 2.0, que finalmente vio la luz en marzo de 2005 como sucesora oficial de las versiones SAML 1.0 y 1.1 respectivamente. Además de las numerosas mejoras aplicadas a las funciones ya existentes, el nuevo marco introdujo funciones totalmente nuevas procedentes de la estructura Liberty Alliance Identity Federation Framework (ID-FF) 1.2 y de la arquitectura desarrollada por Internet2 de Shibboleth-Architektur.

En la siguiente lista te contamos cuáles han sido los cambios más importantes introducidos en el marco a partir de la publicación de su versión 2.0:

• Eliminación de algunos elementos obsoletos como <AuthorityBinding> o <RespondWith> y el formato del identificador.
• Puesta en marcha de la firma XML y el cifrado XML (conforme al estándar W3C).
• Reemplazo del atributo AssertionID por un atributo XML ID general.
• Introducción de la gestión de sesiones para ayudar a los cierres de sesión automáticos en todas las aplicaciones (por ejemplo, cuando se detectan periodos de inactividad prolongados).
• Adaptación de los metadatos para simplificar el uso de SAML (entre otras cosas, la nueva versión diferencia ahora también instancias involucradas como el proveedor de identidad y el proveedor de servicio en los metadatos).
• Puesta en marcha de mecanismos que permiten a los proveedores comunicar políticas y configuraciones de privacidad.
• Soporte para dispositivos móviles mejorado.
• Puesta en marcha de todos los protocolos mencionados (en las versiones SAML 1.0 y 1.1 solo existían el Assertion Query y el Request Protocol).
• Optimización de los perfiles o profiles (se han fusionado los perfiles “Browser/Artifact” y “Browser/Post” en uno único, el “SAML 2.0 Web Browser SSO Profile”).

Encontrarás una lista detallada con todas las diferencias existentes entre SAML 2.0 y SAML 1.1 en la página de la comunidad SAML saml.xml.org.

El ámbito de aplicación del estándar SAML se puede definir de forma muy sencilla: si se tienen los conocimientos apropiados, es posible poner en marcha una instancia de autentificación central basada en el lenguaje de marcado que destaca por su eficiencia y elevado estándar de seguridad. La seguridad que aporta este protocolo se debe principalmente al hecho de que las aplicaciones no tienen que almacenar ni sincronizar los datos de los usuarios, lo que minimiza considerablemente el número de posibles filtraciones de seguridad. Este marco ofrece un equilibrio destacable entre funcionalidad y seguridad, ya que es compatible, por ejemplo, con el mencionado sistema de inicio de sesión único (Single Sign-On) a través de la puesta en marcha de protocolos y formatos de mensaje.

El procedimiento SAML SSO, que permite al usuario utilizar varias aplicaciones con un único inicio de sesión, se utiliza más allá de los procesos y aplicaciones internas de las empresas: actualmente el inicio de sesión único está consolidado en los servicios que ofrecen muchas webs, especialmente dentro de los sectores de la banca online y de las aplicaciones móviles. A veces, el usuario ni si quiera se da cuenta de que ha pasado de una aplicación a otra mediante este tipo de servicios. Por ejemplo, un cliente inicia sesión en la página web de su banco y es probable que acceda a otros sistemas backend sin darse cuenta. Esto ocurre, por ejemplo, si abre una cuenta de ahorro, un depósito o una cuenta de tarjeta de crédito. Gracias a la tecnología SAML, el usuario piensa que todas esas acciones han tenido lugar en un mismo programa.