| Artículos | 01 ENE 2006

SAML 2.0 simplifica la federación de identidades

El estándar SAML 2.0, ratificado por OASIS el pasado mes de marzo, fomenta la adopción de la federación de identidades, al eliminar los obstáculos que representaba tener que tratar múltiples protocolos.

Hasta hace poco, la federación de identidades ha venido sufriendo el problema que representa la existencia de varios estándares. Las empresas que adoptaban este tipo de soluciones se veían forzadas a tratar con cinco protocolos incompatibles: SALM (Security Assertion Markup Language) 1.0 y 1.1 de OASIS, ID-FF 1.1 y 1.2 de Liberty Alliance y Shibboleth. Tal multiplicidad de implementaciones y métodos de uso ralentizaba la difusión y aumentaba los costes del despliegue de la federación de identidades.
A fin de eliminar este obstáculo, OASIS (Organization for the Advancement of Structured Information Standards), Liberty Alliance y Shibboleth unieron sus fuerzas para crear un estándar único que superase las limitaciones de sus desarrollos anteriores. El resultado es SAML 2.0, ratificado por OASIS el pasado mes de marzo y ya presente en algunos productos comerciales.
Antes de la aparición de SAML 2.0, las organizaciones que deseaban desplegar identidades federadas se veían obligadas a negociar el protocolo a utilizar con cada socio de la federación. De este modo, tenían que soportar múltiples protocolos mediante técnicas de conversión que no siempre garantizaban la integridad de las características clave de estas soluciones. Este problema ha quedado resuelto con SAML 2.0, que tiene la ventaja de incorporar en una sola norma todas las características y funciones críticas de sus predecesores. En este sentido, al representar un superconjunto funcional que integra todas las características de los cinco protocolos anteriores, les hace obsoletos.

Procesos y roles
SAML 2.0 describe dos roles de federación: el de proveedor del servicio, que es la entidad que da acceso al usuario a un recurso o aplicación; y el de proveedor de identidad, responsable de la autenticación del usuario. Ambos, proveedor del servicio y proveedor de identidad, intercambian mensajes para permitir la firma única y un único log de acceso. Tal intercambio de mensajes puede ser iniciado por cualquiera de las dos entidades.
Para la firma única, el proveedor de identidad se responsabiliza de crear y enviar al proveedor de servicio una “aserción” (assertion), que contiene la identidad del usuario. El proveedor de servicio, por su parte, se hace cargo de validar la aserción SAML antes de permitirle acceder a la aplicación.
Una aserción SAML es un documento XML que contiene diversos elementos relativos a la identidad del usuario, como la forma en que el usuario ha sido autenticado y, opcionalmente, atributos sobre su identidad. El intercambio de tales mensajes puede producirse por medios diferentes, ya sea en forma HTTP vía el navegador o una interacción SOA.
La convergencia de las formas de uso que aporta SAML 2.0 tendrá un efecto fundamental sobre el interés de las empresas por el uso de la federación como medio de compartir información sobre identidades sin restricciones. Simplifica, además, la elección de la tecnología a adoptar y elimina la necesidad de soluciones multiprotocolo confusas, complejas y caras de mantener. Muy probablemente, los actuales despliegues basados en SAML 1.0 y 1.1, o Liberty ID-FF 1.1 y 1.2 serán actualizados a SAML 2.0 en 2006.


Cómo funciona
----------------------
El estándar de federación SALM 2.0 permite que un sitio Web dé acceso a un usuario que ya ha sido autenticado en otro dominio.

Un usuario intenta acceder a un sitio Web. Si no ha sido autenticado, el sitio redirecciona su navegador a un servidor de federación local.
El servidor de federación local redirige al usuario a un servidor de federación remoto, el cual se encarga de comprobar su identidad. El usuario proporciona su nombre y contraseña.
El servidor de federación remoto verifica la identidad del usuario en un servidor LDAP (Lightweight Directory Access Protocol). Si las credenciales del usuario son verificadas, el servidor de federación remoto crea una aserción SAML, la integra en su navegador y le devuelve al servidor de federación local.
El servidor de federación local extrae la aserción SAML y crea una cookie de sesión. El navegador de usuario se redirige al sitio Web.

Más información en www.oasis-open.org/specs/index.php#samlv2.0

Contenidos recomendados...

Comentar
Para comentar, es necesario iniciar sesión
Se muestran 0 comentarios
X

Uso de cookies

Esta web utiliza cookies técnicas, de personalización y análisis, propias y de terceros, para facilitarle la navegación de forma anónima y analizar estadísticas del uso de la web. Consideramos que si continúa navegando, acepta su uso. Obtener más información