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
Autor:
01/01/2006
Votos:
Más sobre:      
   
| Más

Hoy en IDG.es

©2012 IDG COMMUNICATIONS, S. A. U. Prohibida la reproducción total o parcial en cualquier medio (escrito o electrónico) sin autorización expresa por escrito de la editorial. En particular, IDG COMMUNICATIONS, S.A.U., se opone de manera expresa, salvo consentimiento por escrito, a la reproducción, recopilación, distribución, comunicación pública o puesta a disposición por parte de terceros de los contenidos publicados en los medios de su titularidad (ya se editen éstos en papel, a través de Internet o cualquier otro soporte), de conformidad con lo establecido en el artículo 32 de la Ley 23/2006, de 7 de julio, por la que se modifica el texto refundido de la Ley de Propiedad Intelectual, aprobado por el Real Decreto Legislativo 1/1996, de 12 de abril. En caso de estar interesado en una autorización para reproducir, distribuir, comunicar, almacenar o utilizar en cualquier forma los contenidos titularidad de IDG COMMUNICATIONS, S.A.U. debe dirigir su petición a la siguiente dirección de correo electrónico : idg_nt@idg.es
idg.es