SAML (Security Assertion Markup Language)

La identidad federada (en inglés: Federated Identity Ma­na­ge­me­nt) es una de las so­lu­cio­nes más im­po­r­ta­n­tes que permite de­sa­rro­llar apli­ca­cio­nes web y es­tru­c­tu­ras en la nube ac­ce­si­bles por varias empresas sin que por ello la seguridad se vea co­m­pro­me­ti­da. Las políticas y pro­to­co­los es­ta­n­da­ri­za­dos ga­ra­n­ti­zan 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 au­te­n­ti­fi­ca­ción única nos permite utilizar varias apli­ca­cio­nes 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 Co­n­fi­r­ma­cio­nes 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 in­te­r­ca­m­bio de datos de au­te­n­ti­fi­ca­ción y au­to­ri­za­ción. SAML es un producto de­sa­rro­lla­do por el comité técnico del grupo OASIS (Orga­ni­sa­tion for the Adva­n­ce­me­nt of Structured Info­r­ma­tion 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 di­s­po­ni­bles en las versiones revisadas SAML 2.0 y 2.1 (y en la 1.1). El estándar SAML está formado por varios co­m­po­ne­n­tes que aportan todas las funciones ne­ce­sa­rias para definir y tra­n­s­mi­tir in­fo­r­ma­ción de forma segura. SAML co­n­s­ti­tu­ye, por lo tanto, un fu­n­da­me­n­to muy apropiado para la gestión de la identidad federada o Federated Identity Ma­na­ge­me­nt (FIM).

SAML permite, entre otras cosas, realizar de­cla­ra­cio­nes sobre las pro­pie­da­des y au­to­ri­za­cio­nes de un usuario respecto de otros usuarios o empresas asociadas, aunque es­pe­cia­l­me­n­te respecto de una apli­ca­ción (que a veces reciben el nombre de service provider o proveedor de servicio cuando estamos hablando de SAML). Con este fin, el de­no­mi­na­do identity provider o proveedor de identidad (base de datos central del usuario), donde se almacena toda la in­fo­r­ma­ción de un usuario concreto, hace uso de ase­r­cio­nes o as­se­r­tio­ns en formato XML. Un conjunto de seis pro­to­co­los di­fe­re­n­tes, además de bindings y perfiles son los otros co­m­po­ne­n­tes que forman parte de la ar­qui­te­c­tu­ra de ve­ri­fi­ca­ción basada en el estándar SAML:.

Una aserción o assertion SAML puede incluir una o más de­cla­ra­cio­nes o sta­te­me­nts sobre las pro­pie­da­des (identidad, atributos) y los permisos de un usuario. El re­s­po­n­sa­ble de crearla es el proveedor de identidad co­rre­s­po­n­die­n­te, es decir, la base de datos que co­rre­s­po­n­da al usuario, que utiliza XML como lenguaje de marcado. Cada aserción recibe una firma digital, que primero tiene que ser co­m­pro­ba­da y ve­ri­fi­ca­da por el service provider o proveedor de servicios al que se desea acceder, es decir, por la apli­ca­ción pe­r­ti­ne­n­te. De esta forma, es posible ga­ra­n­ti­zar la in­te­gri­dad y au­te­n­ti­ci­dad de la aserción, que recibe el nombre, una vez firmada, de token SAML. Después de realizar la ve­ri­fi­ca­ción, el proveedor de servicios analiza el contenido concreto y luego decide si otorga o no acceso al usuario y en caso afi­r­ma­ti­vo, qué tipo de acceso otorga.

El estándar SAML 2.0 es­pe­ci­fi­ca los tres tipos si­guie­n­tes de de­cla­ra­cio­nes en la aserción:

• Au­the­n­ti­ca­tion Sta­te­me­nts: son expedidas por la entidad que ha llevado a cabo el proceso de au­te­n­ti­fi­ca­ción del usuario. En una de­cla­ra­ción de este tipo se recoge quién la ha emitido, el sujeto au­te­n­ti­fi­ca­do, el período de validez y otros datos re­la­cio­na­dos con la au­te­n­ti­fi­ca­ción. Nos re­fe­ri­re­mos a ellas también como de­cla­ra­cio­nes o afi­r­ma­cio­nes de au­te­n­ti­fi­ca­ción.
• Attribute Sta­te­me­nts: contienen detalles es­pe­cí­fi­cos sobre el usuario y pueden ser co­mu­ni­ca­das a la apli­ca­ción mediante el token SAML co­rre­s­po­n­die­n­te. Nos re­fe­ri­re­mos a ellas también como de­cla­ra­cio­nes o afi­r­ma­cio­nes de atributos.
• Au­tho­ri­za­tion Decision Sta­te­me­nts: recogen datos sobre lo que le está o no permitido hacer al usuario. Por ejemplo, si está o no au­to­ri­za­do a acceder a un de­te­r­mi­na­do recurso. Nos re­fe­ri­re­mos a ellas también como de­cla­ra­cio­nes o afi­r­ma­cio­nes de au­to­ri­za­ción.

La es­pe­ci­fi­ca­ción SAML 2.0 establece una serie de pro­to­co­los de solicitud o respuesta con los que la apli­ca­ción puede, por ejemplo, solicitar una aserción o pedir a un usuario que se au­te­n­ti­fi­que. En concreto, se utilizan los si­guie­n­tes pro­to­co­los:

• Au­the­n­ti­ca­tion Request Protocol: define mensajes del tipo <Au­th­n­Re­que­st>, que son ne­ce­sa­rios para consultar ase­r­cio­nes con Au­the­n­ti­ca­tion Sta­te­me­nts de un usuario se­le­c­cio­na­do. Ge­ne­ra­l­me­n­te, es un proveedor de servicios el que emite la solicitud y suele utilizar un perfil SAML 2.0 navegador Web SSO (más in­fo­r­ma­ción en el apartado sobre los perfiles) y co­n­te­s­ta­da por un proveedor de identidad tras haber co­m­ple­ta­do con éxito un proceso de au­te­n­ti­fi­ca­ción del usuario.
• Assertion Query y Request Protocol: es necesario para so­li­ci­tu­des con las que, en general, se pueden obtener ase­r­cio­nes SAML ya exi­s­te­n­tes. Es posible solicitar una aserción siguiendo distintos pa­rá­me­tros como, por ejemplo, que contenga unas de­cla­ra­cio­nes de­te­r­mi­na­das.
• Single Logout Protocol: define so­li­ci­tu­des que inician el cierre cuasi si­mu­l­tá­neo de todas las sesiones abiertas pe­r­te­ne­cie­n­tes a un mismo usuario. Este tipo de mensajes pueden enviarse di­re­c­ta­me­n­te tanto al usuario como a un proveedor de identidad o de servicio. Este último suele co­n­si­de­rar­se cuando la sesión de un usuario ha expirado.
• Artifact Re­so­lu­tion Protocol: se utiliza para tra­n­s­po­r­tar 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 re­fe­re­n­cias y ase­r­cio­nes que también se denominan “artifact” y son co­n­si­de­ra­ble­me­n­te más pequeñas que el propio mensaje. El protocolo también permite borrar estas re­fe­re­n­cias para recibir el mensaje original.
• Name Ide­n­ti­fier Ma­na­ge­me­nt Protocol: este protocolo pro­po­r­cio­na me­ca­ni­s­mos 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 uti­li­zar­se para eliminar aquellos enlaces entre pro­vee­do­res de servicio y pro­vee­do­res de identidad que fueron creados para au­te­n­ti­fi­car la identidad del usuario original.
• Name Ide­n­ti­fier Mapping Protocol: este protocolo define mensajes de solicitud y de respuesta para que dos pro­vee­do­res de servicio puedan co­mu­ni­car­se. Basándose en este tipo de mensaje, una apli­ca­ción puede solicitar un ide­n­ti­fi­ca­dor para un usuario al proveedor de identidad con el fin de acceder a otra apli­ca­ción.

Las es­pe­ci­fi­ca­cio­nes para “mapear” (en inglés: mapping) un protocolo SAML sobre un de­te­r­mi­na­do protocolo de tra­n­s­po­r­te reciben el nombre de binding. Se definen varios tipos, entre los que en­co­n­tra­mos, por ejemplo, el SOAP Binding, que sirve para definir cómo los mensajes del protocolo SAML se in­te­r­ca­m­bian, in­te­gra­dos en mensajes de SOAP, y es­pe­ci­fi­ca cómo dichos mensajes SOAP se tra­n­s­po­r­tan sobre HTTP. Por su parte, el HTTP Redirect Binding define cómo se pueden tra­n­s­po­r­tar mensajes del protocolo SAML a través del pro­ce­di­mie­n­to de re­di­re­c­ció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 ca­ra­c­te­ri­za por su fle­xi­bi­li­dad, lo que le permite poder ser utilizado como marco en muchos supuestos di­fe­re­n­tes. Sin embargo, para que ciertas apli­ca­cio­nes puedan ser co­m­pa­ti­bles con SAML, a veces es necesario re­s­tri­n­gir esa fle­xi­bi­li­dad. Un perfil o profile se utiliza para combinar de­te­r­mi­na­das ase­r­cio­nes, pro­to­co­los y bindings para componer en la práctica un supuesto de uso concreto de la es­pe­ci­fi­ca­ción SAML. Uno de los perfiles más uti­li­za­dos es el ya me­n­cio­na­do SAML 2.0 Web Browser SSO Profile, que es­pe­ci­fi­ca el marco para poner en marcha la au­te­n­ti­fi­ca­ción única SSO en SAML. Incluye todos los co­m­po­ne­n­tes ne­ce­sa­rios para definir la co­mu­ni­ca­ción de las garantías de au­te­n­ti­fi­ca­ción SAML entre el proveedor de identidad y el proveedor de servicios, que son ne­ce­sa­rias para la au­te­n­ti­fi­ca­ción única en un navegador web. El estándar también define los si­guie­n­tes perfiles adi­cio­na­les:

• Enhanced Client and Proxy (ECP) Profile
• Identity Provider Discovery Profile
• Single Logout Profile
• Name Ide­n­ti­fier Ma­na­ge­me­nt Profile
• Artifact Re­so­lu­tion Profile
• Assertion Query/Request Profile
• Name Ide­n­ti­fier Mapping Profile

Más de 24 empresas y or­ga­ni­za­cio­nes pa­r­ti­ci­pa­ron en el diseño y de­sa­rro­llo de la versión SAML 2.0, que fi­na­l­me­n­te vio la luz en marzo de 2005 como sucesora oficial de las versiones SAML 1.0 y 1.1 re­s­pe­c­ti­va­me­n­te. Además de las numerosas mejoras aplicadas a las funciones ya exi­s­te­n­tes, el nuevo marco introdujo funciones to­ta­l­me­n­te nuevas pro­ce­de­n­tes de la es­tru­c­tu­ra Liberty Alliance Identity Fe­de­ra­tion Framework (ID-FF) 1.2 y de la ar­qui­te­c­tu­ra de­sa­rro­lla­da por Internet2 de Shi­b­bo­le­th-Ar­chi­te­k­tur.

En la siguiente lista te contamos cuáles han sido los cambios más im­po­r­ta­n­tes in­tro­du­ci­dos en el marco a partir de la pu­bli­ca­ción de su versión 2.0:

• Eli­mi­na­ción de algunos elementos obsoletos como <Au­tho­ri­t­y­Bi­n­di­ng> o <Re­s­po­n­d­Wi­th> y el formato del ide­n­ti­fi­ca­dor.
• Puesta en marcha de la firma XML y el cifrado XML (conforme al estándar W3C).
• Reemplazo del atributo As­se­r­tio­nID por un atributo XML ID general.
• In­tro­du­c­ción de la gestión de sesiones para ayudar a los cierres de sesión au­to­má­ti­cos en todas las apli­ca­cio­nes (por ejemplo, cuando se detectan periodos de inac­ti­vi­dad pro­lo­n­ga­dos).
• Ada­p­ta­ción de los metadatos para si­m­pli­fi­car el uso de SAML (entre otras cosas, la nueva versión di­fe­re­n­cia ahora también in­s­ta­n­cias in­vo­lu­cra­das como el proveedor de identidad y el proveedor de servicio en los metadatos).
• Puesta en marcha de me­ca­ni­s­mos que permiten a los pro­vee­do­res comunicar políticas y co­n­fi­gu­ra­cio­nes de pri­va­ci­dad.
• Soporte para di­s­po­si­ti­vos móviles mejorado.
• Puesta en marcha de todos los pro­to­co­los me­n­cio­na­dos (en las versiones SAML 1.0 y 1.1 solo existían el Assertion Query y el Request Protocol).
• Op­ti­mi­za­ció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”).

En­co­n­tra­rás una lista detallada con todas las di­fe­re­n­cias exi­s­te­n­tes entre SAML 2.0 y SAML 1.1 en la página de la comunidad SAML saml.xml.org.

El ámbito de apli­ca­ción del estándar SAML se puede definir de forma muy sencilla: si se tienen los co­no­ci­mie­n­tos apro­pia­dos, es posible poner en marcha una instancia de au­te­n­ti­fi­ca­ción central basada en el lenguaje de marcado que destaca por su efi­cie­n­cia y elevado estándar de seguridad. La seguridad que aporta este protocolo se debe pri­n­ci­pa­l­me­n­te al hecho de que las apli­ca­cio­nes no tienen que almacenar ni si­n­cro­ni­zar los datos de los usuarios, lo que minimiza co­n­si­de­ra­ble­me­n­te el número de posibles fi­l­tra­cio­nes de seguridad. Este marco ofrece un equi­li­brio de­s­ta­ca­ble entre fu­n­cio­na­li­dad y seguridad, ya que es co­m­pa­ti­ble, por ejemplo, con el me­n­cio­na­do sistema de inicio de sesión único (Single Sign-On) a través de la puesta en marcha de pro­to­co­los y formatos de mensaje.

El pro­ce­di­mie­n­to SAML SSO, que permite al usuario utilizar varias apli­ca­cio­nes con un único inicio de sesión, se utiliza más allá de los procesos y apli­ca­cio­nes internas de las empresas: ac­tua­l­me­n­te el inicio de sesión único está co­n­so­li­da­do en los servicios que ofrecen muchas webs, es­pe­cia­l­me­n­te dentro de los sectores de la banca online y de las apli­ca­cio­nes móviles. A veces, el usuario ni si quiera se da cuenta de que ha pasado de una apli­ca­ció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 te­c­no­lo­gía SAML, el usuario piensa que todas esas acciones han tenido lugar en un mismo programa.