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 (Security Assertion Markup Language) es un estándar de código abierto basado en XML que permite intercambiar información de autentificación y autorización. Cada uno de los componentes que forman SAML, entre los que encontramos una base de datos central de usuario y seis protocolos diferentes, proporcionan todas las funciones necesarias para definir y transmitir información de las funciones de seguridad. Por esta razón, SAML se considera una solución excelente y completa 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:
El número de declaraciones en una aserción depende principalmente del ámbito de aplicación del estándar SAML. Por ejemplo, si se va a poner en marcha una solución Single Sign-on, un token SAML suele contener un único Authentication Statement y un Attribute Statement.
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:
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:
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:
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.
La base de datos de autentificación central se conoce como “Identity Provider” solo a partir de la versión SAML 2.0. Esta terminología procede de la que utiliza Liberty Alliance. En las versiones anteriores, esta instancia recibe el nombre de “Authentication Authority”.
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:
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.
En la práctica, existe una diferencia entre “Service Provider initiated SAML” e “Identity Provider initiated SAML”. Los dos conceptos se diferencian en la instancia a la que se envía la solicitud de autentificación del usuario (proveedor de servicio o proveedor de identidad).
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.
Eran Hammer-Lahav describió el protocolo de seguridad OAuth 2.0, en el que había trabajado durante años, como “el camino hacia el infierno”. Sin embargo, muchos analistas de seguridad consideran que este estándar abierto sí cumple debidamente con su función: permitir a los usuarios utilizar datos y funcionalidades en múltiples servicios a través de una autorización API segura. Descubre cómo...
La vida online sería muy fácil si pudiéramos introducir los datos de acceso una sola vez e iniciar sesión en todas las cuentas y plataformas sin tener que recordar decenas de contraseñas. Este sueño se ha hecho realidad gracias al SSO (single sign on), un servicio que utilizan cada vez más usuarios, aunque la comodidad y la supuesta seguridad de los datos que ofrece van acompañadas de algunas...
JSON Web Token (JWT) es un estándar abierto que ayuda a flexibilizar la autentificación del usuario. Con este método, los datos se transfieren de forma segura entre las dos partes y se verifican con una firma digital que garantiza su fiabilidad. Te explicamos qué son los JWT, cómo funcionan y por qué vale la pena utilizarlos.
Ofrece un servicio fiable y de alto rendimiento a tus clientes con un pack hosting de IONOS.
Ver packs
