Otro nuevo e interesante proyecto dentro la iniciativa OpenSSO de Sun, esta vez para habilitar entornos de identidad federada desarrollados en PHP: Lightbulb.

Se trata en esencia de un Liberty Service Provider desarrollado en este lenguaje, y que utiliza SAML 2.0 para poder integrarse en un Círculo de Confianza, aunque se trata de un proyecto completamente experimental aún.

Hasta ahora la mayoría de las soluciones disponibles en el mercado, bien como producto comercial, bien en modo open source, se basaban en J2EE; dada la gran implantación de PHP como lenguaje de programación web en entornos libres, es muy interesante el poder disponer de la posibilidad de desarrollar componentes Liberty-compatibles y, en general, poder tener más opciones a la hora de elegir con que tecnología acceder al mundo de la identidad federada.

Para saber más, puede consultarse este artículo (en inglés) en el web de desarrolladores de Sun.

Al hilo de la publicación, más de tres años después de la última, de una nueva versión de WS-Federation, merece la pena hacer un breve análisis comparativo del estado del arte de esta tecnología y de SAML 2.0. Un buen punto de partida es este documento elaborado por el Gobierno de Dinamarca de cara a la adopción de una tecnología de federación de identidad. El documento es de lectura recomendada a pesar de estar en inglés, ya que más allá de lo interesante de su contenido, se trata de un análisis serio realizado por una entidad externa, lo que garantiza su neutralidad.

A modo de resumen, he aquí las principales conclusiones del estudio.

Cumplimiento de requisitos funcionales.

Los requisitos básicos que se planteó el Gobierno danés para comenzar el análisis fueron los siguientes:

• Posibilidad de uso de un sistema de autenticación común para todas las entidades involucradas.
• Single sign-on federado entre todas las entidades.
• Establecimiento de una infraestructura que sirva como base para la gestión de la identidad y los accesos en fases posteriores.
• Soporte para la interacción entre diferentes sistemas de control de autenticidad.

El estudio concluye que ambas tecnologías verifican estos requisitos, aunque WS-Fed más a nivel teórico (no existen aun experiencias en producción).

Disponibilidad de productos comerciales.

A excepción de Microsoft, todos los fabricantes en el mundo de la gestión de identidad disponen de productos que soportan SAML 2.0 o están en vías de hacerlo. Un pequeño subconjunto de estos soporta también el Passive Profile (es decir, web SSO) de WS-Fed.

Uso en producción en el sector público.

Existen varias referencias en producción con SAML 2.0: el Sikkerhetsportal noruego, el portal de la ciudad de Estocolmo, el portal del ciudadano en Francia o el portal del Servicio Nacional de Salud de UK (el mayor proyecto TI de Europa), entre otras. Los autores no han podido encontrar ninguna con WS-Federation, aunque asumen que habrá en un futuro cercano.

Comentarios de los analistas.

Tanto Gartner como Burton piensan que SAML 2.0 y WS-Federation se solapan y no son interoperables. En lo referente a requisitos específicos para federación de identidades, ambos recomiendan SAML 2.0.

Basado en estándares.

SAML 2.0 es un estándar de OASIS desde la primavera de 2005.

WS-Fed fue publicado en 2003 originariamente, pero aun no ha sido enviado a ningún organismo para su estandarización.

Interacción con otros estándares ya en uso.

Los autores identifican dos tecnologías fundamentales:

• XACML para la transmisión de información sobre derechos de acceso.
• SPML para la gestión del ciclo de vida de las identidades (i.e., provisión).

Existen protocolos descritos en XACML que explican su uso conjunto con SAML. Asimismo, se han desarrollado perfiles para la transmisión de información SPML a través de SAML. WS-Fed no dispone de ningún método descrito para el uso conjunto de estas tecnologías.

Desarrollo futuro del estándar.

Se espera una consolidación de ambas tecnologías en el futuro, aunque según los autores parte con ventaja SAML, debido a su mayor extensión en la actualidad.

Certificación de cumplimiento/interoperabilidad por algún organismo certificador.

Liberty Alliance dispone de pruebas de certificación para productos comerciales SAML 2.0. Actualmente no existe una entidad certificadora para productos que soporten WS-Federation.

Estas son las principales conclusiones del estudio, el cual, en mi opinión, es una descripción bastante exacta de la situación actual de ambas tecnologías.

El término "federación de identidades" es, paradójicamente, uno de los principales causantes de la dificultad en entender los conceptos relacionados con la identidad federada y es debido a que se trata de una mala traducción del inglés "identity federation". Si en su lugar dijéramos "asociación de identidades" o "enlace entre identidades" dispondríamos de un nombre mucho más descriptivo.

La asociación entre las cuentas que un usuario determinado posee en diferentes sitios es el fundamento de los servicios que es posible construir usando las especificaciones de Liberty Alliance. En ellas, en concreto en el Identity Federation Framework (ID-FF), se explica como es posible establecer dichos enlaces sin intercambio de información sensible entre los participantes. Vamos a ver cómo funciona este mecanismo supuestamente mágico de relacionar las cuentas.

La idea de federar las cuentas es obtener una identidad única, de forma que todos los participantes perciban al usuario como una entidad homogénea y no como un conjunto de porciones de información sin relación entre ellas. El mecanismo que Liberty proporciona para ello se denomina identificador opaco y consiste en un código alfanumérico sin significado propio que representa el enlace o asociación entre la cuenta del usuario en un Service Provider y la que posee en el Identity Provider. Como se aprecia en la figura, el IdP es el único que posee todos los identificadores y conoce por tanto las relaciones entre cuentas. De esta forma un SP es capaz de hacer referencia al usuario sin conocer de él más que sus propios datos, nunca los albergados en otros proveedores (salvo que el propio usuario lo consienta, pero eso es otra historia de la que hablaremos en el futuro).

Todo esto, junto con el hecho de que los identificadores pueden ser incluso, si se desea, de un solo uso (es decir, se crea uno nuevo en cada autenticación) para impedir que un SP pueda trazar los accesos de un usuario, garantiza la privacidad de los datos. Además, las federaciones (asociaciones) son establecidas por el propio usuario la primera vez que se requieren (posiblemente camufladas como algún tipo de acuerdo de condiciones de servicio, por ejemplo) y también pueden ser revocadas por él en cualquier momento. Existen mecanismos para federar las cuentas de forma masiva entre todos los proveedores, pero no son estándar y dependen por tanto del producto comercial que se escoja (por ejemplo, Sun Access Manager y Sun Federation Manager disponen de una funcionalidad denominada bulk federation que consigue precisamente esto).

Liberty Alliance define dos grupos de especificaciones relacionadas con la federación de identidades:

• Identitity Federation Framework (ID-FF).
• Identity Web Services Framework (ID-WSF) e Identity Services Interface Specification (ID-SIS).
  

ID-FF fue la primera especificación Liberty en aparecer y define los roles de las entidades participantes en un entorno de identidad federada, así como los protocolos necesarios para efectuar las operaciones siguientes:

• Federación (asociación) de cuentas.
• Single Sign-on.
• Single Log-out.
• De-federación de cuentas.

El concepto fundamental en ID-FF es el círculo de confianza (Circle of Trust), un conjunto de entidades (compañías, departamentos, admones. públicas, etc.) que han firmado un acuerdo de negocio para suministrar una serie de servicios a sus usuarios comunes, basado en una relación de confianza entre ellos, en principio a efectos de la autenticación de dichos usuarios.

Es fundamental entender que este acuerdo previo, en el que probablemente se contemple la definición de qué servicios concretos se ofrecerán a los usuarios del círculo de confianza, es un paso fundamental, sin el cual no es posible utilizar los estándares tecnológicos definidos por Liberty Alliance. En otras palabras, la confianza a la que se hace alusión en el término se sustenta en este acuerdo rubricado entre los participantes.

Los participantes en el círculo de confianza son, además de los propios usuarios, de dos tipos (ver diagrama a continuación):

• Identity Provider (IdP): dispone de toda la infraestructura necesaria para la autenticación de los usuarios federados en el círculo de confianza, aunque no necesita ningún dato privado de los mismos, salvo las credenciales necesarias para autenticarlos. El resto de entidades participantes depositan su confianza en él respecto a la validez de la autenticación de los usuarios.
• Service Provider (SP): ofrece servicios conjuntos con otros participantes como él, pero delegando toda la autenticación en el IdP y manteniendo una infraestructura Liberty mínima.
  

Para el acceso de los usuarios, Liberty define dos conceptos:

• Liberty-enabled Client: aplicación que es capaz de comunicarse con el IdP que el usuario desea usar para autenticarse.
• Liberty-enabled Proxy: es un proxy HTTP (habitualmente un gateway WAP) que emula un cliente como el anterior.
  

Continuará...

Dentro de la iniciativa global de liberar el código fuente de toda la plataforma de software empresarial de Sun, recientemente ha aparecido un nuevo componente: Open Federation, dentro del proyecto Open SSO.

Vayamos por partes. Open SSO es el proyecto a través del cual Sun está liberando el código fuente de Sun Access Manager y Sun Federation Manager, a fin de ofrecer a la comunidad un entorno de control de acceso, autenticación, single sign on web y federación de identidades completamente abierto.

En el marco de este proyecto, se ha anunciado la disponibilidad de Open Federation, es decir, la liberación de todo el código fuente Java correspondiente a las especificaciones Federation Framework y Web Services Framework de Liberty Alliance incluido en Access/Federation Manager.

Creo que este anuncio es de gran importancia: se trata del primer entorno disponible en modo open source - y con calidad empresarial - que implementa las especificaciones completas de Liberty Alliance para federación de identidad y web services. Hasta la fecha existían iniciativas abiertas relacionadas con federación y Liberty como OpenSAML y Lasso, pero se trataba únicamente de librerías para desarrollo de aplicaciones SAML y Liberty, no de una plataforma software completa.

A pesar de que la frase "identidad federada" o "federación de identidades" está en boca de todos, aún hay muchas dudas y malentendidos sobre el concepto y la tecnología que hay debajo, sobre todo porque creo que hay poca documentación que proporcione un nivel de entrada asequible a este mundo. Voy a intentar aportar mi granito de arena sobre ello...

Todo el mundo posee identidad digital, es decir, una serie de datos asociados a su persona y que le definen ante diferentes instancias, como por ejemplo nombre, apellidos, NIF, teléfono, correo electrónico, etc. Solo que ninguno tenemos una identidad digital, sino que tenemos decenas de ellas: una en la empresa para la que trabajamos, una en nuestra compañía de telefonía móvil, una en nuestro banco, una asociada a nuestra tarjeta de crédito, una para nuestra tarjeta de viajero frecuente en alguna línea aérea, etc.

Supongamos que eres el presidente de tu propia compañía de telecomunicaciones y que planeas lanzar un nuevo servicio que incremente los ingresos de la empresa, digamos un servicio que permita consultar el buzón de voz por Internet. Para hacer esto, habrás de utilizar conjuntamente toda una serie de servicios ya existentes: ventas, provisión, soporte técnico, facturación, etc. y que además están externalizados a otras empresas u otras unidades de negocio dentro de tu compañía. Con estas premisas comienzas a elaborar la descripción del nuevo servicio.

En primer lugar, tu nuevo servicio de buzón de voz online deberá ser capaz de usar el resto de servicios mencionados de forma que tu cliente perciba un único servicio. Sin embargo, dicho cliente probablemente tenga diferentes identificadores de usuario y contraseñas para la autenticación en cada uno de esos servicios y además tu no querrás suministrar datos de tus clientes a tus empresas colaboradoras externas, por motivos de negocio. Lo que necesitas es poder decirle a los diferentes poseedores de los servicios (partners o unidades de negocio internas): "Este cliente es quien dice ser (yo os lo aseguro). Dejadle utilizar el servicio correspondiente".

Para poder hacer esto, todos los participantes deben convenir una serie de reglas y protocolos para comunicarse y además fijar ciertos niveles de seguridad en las comunicaciones, privacidad de los datos del cliente y cumplimiento de las normativas legales correspondientes (no querrías que lanzar tu nuevo servicio te llevara directamente a la cárcel).

El primer enfoque que uno puede imaginar es implementar integraciones punto a punto entre los diferentes proveedores; es fácil deducir que esto es muy complejo y costará mucho dinero, además de ser un planteamiento incapaz de crecer o de responder a cambios de forma ágil, especialmente si las infraestructuras de TI de los proveedores son muy diferentes entre sí.

Por tanto, se hace indispensable algún tipo de procedimiento automatizado. Si pensamos en como funciona un servicio de fax, tendremos la clave: uno teclea el número de fax y pulsa un botón; las máquinas hacen el resto, negociando como intercambiarán la información en función de sus respectivas capacidades.

Es decir, necesitamos algo que posibilite a los distintos sistemas de gestión de identidad de los participantes negociar automáticamente, basándose en sus capacidades, como se intercambiarán ciertos datos de identidad de los usuarios (obviamente no el identificador de usuario y la contraseña), garantizando en el proceso la seguridad, privacidad de los datos y el cumplimiento de la ley. Esto es exactamente lo que permite la federación de identidades.

La identidad federada facilita de esta forma a las compañías crear nuevas oportunidades de negocio (nuevos servicios) que incrementen sus ingresos, ahorrando de paso costes al facilitar la externalización de aquellos servicios necesarios pero fuera del núcleo de su negocio y aumentando la satisfacción de los clientes haciéndoles la vida más fácil.

Sun dispone de una solución completa para desplegar infraestructuras de identidad federada:

• Sun Access Manager proporciona control de acceso a las aplicaciones basado en políticas y proporciona autenticación y single-sign on entre ellas, tanto en entorno intranet como extranet (esto es, entre los distintos partners).
• Sun Identity Manager permite realizar la provisión de cuentas de usuario en los diferente sistemas.
• Sun Directory Server Enterprise Edition proporciona un repositorio LDAP altamente escalable para los datos de los usuarios
• Sun Federation Manager posibilita extender el entorno de identidad federada a aquellos partners que requieran una solución sencilla y de bajo coste.

En sucesivos posts profundizaré en aspectos técnicos de la identidad federada: como se enlazan mis diferentes identidades entre sí, como se garantiza la privacidad de mis datos y como se consigue desplegar servicios de forma segura y con single-sign on entre ellos.