Firma única con SAML
Apoyado tanto por Liberty Alliance Project como por Microsoft (aunque con su toque peculiar habitual), el estándar de firma única Security Assertion Markup Language (SAML) se está consolidando como una de las piezas clave del futuro de los sistemas de gestión de identidades federadas.
SAML permite que distintos dominios intercambien información de autorización y autenticación sobre usuarios, dispositivos o cualquier otra entidad identificable; es decir, sobre “sujetos”, según la terminología del estándar. Mediante un subconjunto de la norma XML, SAML define el protocolo de pregunta-respuesta por el cual los sistemas aceptan o rechazan las “declaraciones” de los sujetos. Su potencial, por tanto, es crítico para la consecución de un entorno global de “comercio federado” y los servicios Web, por cuanto es capaz de crear un sistema online seguro interoperativo de extremo a extremo, tanto dentro de las empresas como en las relaciones que éstas establecen entre sí
Desarrollado por la Organization for the Advancement of Structured Information Standards (OASIS), SAML 1.0 cuenta con el apoyo de Liberty Aliance Project y, en parte, de Microsoft, y se basa en XML para definir interacciones SOAP (Simple Object Access Protocol) sobre HTTP, soportando firma única (SSO – Single Sign-On), autenticación y autorización. El estándar define mensajes de “declaración” pregunta-respuesta que los dominios de seguridad intercambian para confirmar decisiones de autenticación y autorización, así como los “atributos” relacionados con recursos y usuarios. Especifica, además, entidades funcionales tales como autoridades de autenticación, autoridades de atributos, y puntos de decisión y de reforzamiento de políticas.
Tipos de declaraciones
Esquemáticamente, SAML 1.0 define tres tipos de declaraciones:
Autenticación. Indica que un sujeto ha sido autenticado previamente mediante medios como contraseñas, token de hardware o clave pública X.509.
Autorización. Proceso por el que se permite a un “sujeto” acceder a un determinado recurso.
Atribución. Indica que a un sujeto se le asocian determinados atributos.
Así, por ejemplo, en un entorno de comercio electrónico “federado” un usuario podría “firmar” en un sitio Web, y si es autorizado, su autenticación sería comunicada al resto de sitios “asociados” a los que le llevase su navegación. De este modo, se podría simplificar considerablemente, por ejemplo, la reserva de viajes: el usuario firmaría en un portal de una línea aérea y rápidamente alquilar un coche y reservar una habitación de hotel en otros sitios Web sin tener que pasar por sus respectivos procesos de autenticación.
Es de destacar que SAML no especifica el nivel de confianza que pueda suponer una determinada declaración. Son los sistemas locales los que deciden si los niveles de seguridad y las políticas de una aplicación dada son suficientes para proteger a una empresa de los daños que le pueda causar una decisión de autorización basada en una declaración insegura. Lejos de ser una limitación, esta característica de SAML pretende impulsar las relaciones seguras y los acuerdos operacionales entre los sitios Web de las empresas, de modo que cada una pueda acordar adherirse a un determinado nivel básico de verificación antes de aceptar una declaración.
SAML opera sin cookies siguiendo uno de los dos siguientes perfiles: browser/artifact y browser/post. Con browser/artifact, un “artefacto” o indicador de una declaración SAML es transportado como parte de una cadena de consulta URL. Con browser/post, las declaraciones SAML son cargadas en el navegador y transportada al sitio correspondiente como parte de la carga útil de un destino HTTP.
A vueltas con Microsoft
Aunque SAML está consiguiendo con gran rapidez la aceptación del mercado, se trata de una nueva especificación cuyo futuro a largo plazo todavía no está asegurado. La prueba de fuego, será, como sucede siempre con los estándares, el número de productos que lo soporten y el grado de interoperatividad que aporte en la realidad. Y en este sentido, el respaldo conseguido por la norma no es desdeñable por lo que a Liberty Alliance Project se refiere, pero un tanto ambiguo en lo que respecta al siempre apoyo clave de Microsoft. También en este terreno las diferencias entre ambos antagonistas son evidentes.
Liberty Alliance no sólo incorpora –y extiende– SAML 1.0 en la Versión 1.1 de su especificación, sino que además éste estándar de facto se convertirá en documento base de SAML 2.0, en desarrollo en el seno de OASIS desde hace poco más de un año. Y el peso de los 160 miembros de Liberty es evidente.
La historia con Microsoft es otra. Si ya en 2001 la compañía con sede en Redmon se comprometía a implementar SAML 1.0 en su entorno operativo, mostrando así que, pese a su posición de dominio, no podía mantenerse ajena a las fuerzas del mercado que llaman a la convergencia en lo que a seguridad Web se refiere, lo cierto es que lo hacía sin avanzar demasiados detalles sobre el cómo. Y es aquí donde aparecen las sombras.
Microsoft presentó una visión completa de los entornos de seguridad .Net federados que incorpora, junto a SAML 1.0, especificaciones tales como Kerberos, Passport, Web Services Security (WS-Security), TrustBridge, certificados de clave pública X.509 y licencias de control de accesos Extensible Rights Markup Language. Y en este marco, SAML 1.0 será utilizado fundamentalmente como una sintaxis XML para describir estructuras de datos de “declaración” de autorización y autenticación que serán intercambiados entre .Net y otros entornos operativos y de seguridad.
Pero también en este caso Microsoft quiere seguir su particular camino a la hora de adoptar estándares abiertos: la firma anunció que no implementará las principales porciones de SAML 1.0, incluyendo el uso que el estándar hace de SOAP, los perfiles de navegación Web y el protocolo de mensajería de pregunta-respuesta. En vez de situar las declaraciones SAML en la carga útil de los mensajes SOAP, tal como hace la norma de OASIS, Microsoft las situará en la cabecera de dichos mensajes, junto a las etiquetas Kerberos, según la especificación WS-Security co desarrollada por la compañía con IBM y Verisign. Así, pues, no está muy claro cómo esta implementación de SAML interoperará con los productos de seguridad de servicios Web de otros fabricantes.
En este terreno, parece que Microsoft está siguiendo el mismo modelo de negocio que en el resto del mercado de software corporativo, mezclando estándares abiertos y tecnologías propietarias con el fin de ganar cuota de mercado más rápidamente. Puede que algunas características de la iniciativa WS-Security de Microsoft e IBM acabe adoptando realmente futuras versiones de SAML, pero por el momento lo que se encuentra en los productos de muchos fabricantes es la versión 1.0 del estándar. La interoperatividad global y real tendrá que esperar.
Otros estándares de seguridad de OASIS
---------------------------------------------------------
Extensible Access Control Markup Language (XACML). En la actualidad, las políticas de control de accesos están escritas en lenguajes propietarios espec
SAML permite que distintos dominios intercambien información de autorización y autenticación sobre usuarios, dispositivos o cualquier otra entidad identificable; es decir, sobre “sujetos”, según la terminología del estándar. Mediante un subconjunto de la norma XML, SAML define el protocolo de pregunta-respuesta por el cual los sistemas aceptan o rechazan las “declaraciones” de los sujetos. Su potencial, por tanto, es crítico para la consecución de un entorno global de “comercio federado” y los servicios Web, por cuanto es capaz de crear un sistema online seguro interoperativo de extremo a extremo, tanto dentro de las empresas como en las relaciones que éstas establecen entre sí
Desarrollado por la Organization for the Advancement of Structured Information Standards (OASIS), SAML 1.0 cuenta con el apoyo de Liberty Aliance Project y, en parte, de Microsoft, y se basa en XML para definir interacciones SOAP (Simple Object Access Protocol) sobre HTTP, soportando firma única (SSO – Single Sign-On), autenticación y autorización. El estándar define mensajes de “declaración” pregunta-respuesta que los dominios de seguridad intercambian para confirmar decisiones de autenticación y autorización, así como los “atributos” relacionados con recursos y usuarios. Especifica, además, entidades funcionales tales como autoridades de autenticación, autoridades de atributos, y puntos de decisión y de reforzamiento de políticas.
Tipos de declaraciones
Esquemáticamente, SAML 1.0 define tres tipos de declaraciones:
Autenticación. Indica que un sujeto ha sido autenticado previamente mediante medios como contraseñas, token de hardware o clave pública X.509.
Autorización. Proceso por el que se permite a un “sujeto” acceder a un determinado recurso.
Atribución. Indica que a un sujeto se le asocian determinados atributos.
Así, por ejemplo, en un entorno de comercio electrónico “federado” un usuario podría “firmar” en un sitio Web, y si es autorizado, su autenticación sería comunicada al resto de sitios “asociados” a los que le llevase su navegación. De este modo, se podría simplificar considerablemente, por ejemplo, la reserva de viajes: el usuario firmaría en un portal de una línea aérea y rápidamente alquilar un coche y reservar una habitación de hotel en otros sitios Web sin tener que pasar por sus respectivos procesos de autenticación.
Es de destacar que SAML no especifica el nivel de confianza que pueda suponer una determinada declaración. Son los sistemas locales los que deciden si los niveles de seguridad y las políticas de una aplicación dada son suficientes para proteger a una empresa de los daños que le pueda causar una decisión de autorización basada en una declaración insegura. Lejos de ser una limitación, esta característica de SAML pretende impulsar las relaciones seguras y los acuerdos operacionales entre los sitios Web de las empresas, de modo que cada una pueda acordar adherirse a un determinado nivel básico de verificación antes de aceptar una declaración.
SAML opera sin cookies siguiendo uno de los dos siguientes perfiles: browser/artifact y browser/post. Con browser/artifact, un “artefacto” o indicador de una declaración SAML es transportado como parte de una cadena de consulta URL. Con browser/post, las declaraciones SAML son cargadas en el navegador y transportada al sitio correspondiente como parte de la carga útil de un destino HTTP.
A vueltas con Microsoft
Aunque SAML está consiguiendo con gran rapidez la aceptación del mercado, se trata de una nueva especificación cuyo futuro a largo plazo todavía no está asegurado. La prueba de fuego, será, como sucede siempre con los estándares, el número de productos que lo soporten y el grado de interoperatividad que aporte en la realidad. Y en este sentido, el respaldo conseguido por la norma no es desdeñable por lo que a Liberty Alliance Project se refiere, pero un tanto ambiguo en lo que respecta al siempre apoyo clave de Microsoft. También en este terreno las diferencias entre ambos antagonistas son evidentes.
Liberty Alliance no sólo incorpora –y extiende– SAML 1.0 en la Versión 1.1 de su especificación, sino que además éste estándar de facto se convertirá en documento base de SAML 2.0, en desarrollo en el seno de OASIS desde hace poco más de un año. Y el peso de los 160 miembros de Liberty es evidente.
La historia con Microsoft es otra. Si ya en 2001 la compañía con sede en Redmon se comprometía a implementar SAML 1.0 en su entorno operativo, mostrando así que, pese a su posición de dominio, no podía mantenerse ajena a las fuerzas del mercado que llaman a la convergencia en lo que a seguridad Web se refiere, lo cierto es que lo hacía sin avanzar demasiados detalles sobre el cómo. Y es aquí donde aparecen las sombras.
Microsoft presentó una visión completa de los entornos de seguridad .Net federados que incorpora, junto a SAML 1.0, especificaciones tales como Kerberos, Passport, Web Services Security (WS-Security), TrustBridge, certificados de clave pública X.509 y licencias de control de accesos Extensible Rights Markup Language. Y en este marco, SAML 1.0 será utilizado fundamentalmente como una sintaxis XML para describir estructuras de datos de “declaración” de autorización y autenticación que serán intercambiados entre .Net y otros entornos operativos y de seguridad.
Pero también en este caso Microsoft quiere seguir su particular camino a la hora de adoptar estándares abiertos: la firma anunció que no implementará las principales porciones de SAML 1.0, incluyendo el uso que el estándar hace de SOAP, los perfiles de navegación Web y el protocolo de mensajería de pregunta-respuesta. En vez de situar las declaraciones SAML en la carga útil de los mensajes SOAP, tal como hace la norma de OASIS, Microsoft las situará en la cabecera de dichos mensajes, junto a las etiquetas Kerberos, según la especificación WS-Security co desarrollada por la compañía con IBM y Verisign. Así, pues, no está muy claro cómo esta implementación de SAML interoperará con los productos de seguridad de servicios Web de otros fabricantes.
En este terreno, parece que Microsoft está siguiendo el mismo modelo de negocio que en el resto del mercado de software corporativo, mezclando estándares abiertos y tecnologías propietarias con el fin de ganar cuota de mercado más rápidamente. Puede que algunas características de la iniciativa WS-Security de Microsoft e IBM acabe adoptando realmente futuras versiones de SAML, pero por el momento lo que se encuentra en los productos de muchos fabricantes es la versión 1.0 del estándar. La interoperatividad global y real tendrá que esperar.
Otros estándares de seguridad de OASIS
---------------------------------------------------------
Extensible Access Control Markup Language (XACML). En la actualidad, las políticas de control de accesos están escritas en lenguajes propietarios espec
