Re: Federation Process

Hola:

las respuestas son:
No, el usuario no se puede federar a otro servoce provider si no cuenta con=
 una identidad local, esto es parte de las especificaciones de Liberty, pue=
s es un protocolo de Federaci=F3n de Identidades, no de Single SO, cuando e=
n liberty leemos SSO se trata de Simplified SO.
Hace algun tiempo escribi esto para una presentaci=F3n en M=E9xico de ident=
idades

ojal=E1 y te sirva.
Sergio Mart=EDnez



Liberty Aliance Project

Resolviendo la crisis de identidad

Por Sergio E. Mart=EDnez Pacheco

 

Desde el surgimiento de Internet hasta nuestros d=EDas, la cantidad de serv=
icios que podemos obtener ha crecido exponencialmente. Lamentablemente, tam=
bi=E9n ha crecido la necesidad de identificar y conocer algunas caracter=
=EDsticas de los visitantes con el fin de que los proveedores de servicios =
les brinden un valor agregado. Por tal motivo, en cada lugar que visitamos =
surge la necesidad de registrarnos, registrarnos y volvernos a registrar, y=
 aprendernos una contrase=F1a, y otra y una m=E1s, sitio por sitio o servic=
io por servicio, volvi=E9ndose en algunos casos algo inmanejable.

 

Microsoft propuso una soluci=F3n para esta crisis de identidades: Passport.=
 Un servicio proveedor de identidades al cual el sitio tiene que pagar una =
renta con el fin de que los usuarios afiliados a Passport puedan interactua=
r con nuestro sitio mediante un nombre y una clave =FAnica dentro de todos =
los sitios afiliados a Passport, y donde a cada usuario se le asigna un =
=FAnico GUID (Global Unique Identifier) que es compartido entre todos los s=
itios miembros. Si salimos de Passport, dejamos de tener una identificaci=
=F3n de nuestros usuarios ya que =E9sta y la autenticaci=F3n de los mismos =
est=E1 centralizada en el sitio Passport.

 

A muchas empresas no les agrad=F3 la idea de que la informaci=F3n de sus us=
uarios residiera en otro sitio, por lo que alrededor de 120 empresas decidi=
eron crear un medio para facilitarle al usuario utilizar su identidad, sin =
delegarle esta informaci=F3n a un tercero: de ah=ED nace la iniciativa Libe=
rty Aliance; con la visi=F3n de fomentar un mundo comunicado en la red, en =
donde los individuos y las empresas puedan lograr virtualmente cualquier tr=
ansacci=F3n sin comprometer la privacidad y la seguridad de la informaci=
=F3n vital de una identidad.

 

Pero =BFQu=E9 es una identidad?

 

Podemos navegar en Internet y saltar de un sitio a otro, pero normalmente c=
uanto deseamos tener una interacci=F3n m=E1s personal con un sitio (como so=
licitar informaci=F3n, hacer una compra, apuntarse a una lista de publicaci=
ones, etc) tenemos que decirle qui=E9n somos, qu=E9 nos gusta, en d=F3nde p=
odr=EDa contactarnos o a qu=E9 cuenta puede realizar cobros por los servici=
os o art=EDculos adquiridos. A esta informaci=F3n en conjunto se le conoce =
como identidad, pues le indica al sitio c=F3mo interactuar con nosotros.

 

En el est=E1ndar Liberty, se le conoce como Principal a cualquier entidad c=
apaz de adquirir una identidad, tomar decisiones por su cuenta y ser respon=
sable por sus acciones, las cuales pueden ser autenticadas. 

 

Como objetivos Liberty pretende:

Facilitar la protecci=F3n y seguridad de la identidad de un Principal. 
Lograr que los sistemas manejen y mantengan sus relaciones con clientes sin=
 la participaci=F3n de un tercero. 
Proveer de un est=E1ndar de Single Sign-On que incluya autenticaci=F3n desc=
entralizada del principal a trav=E9s de m=FAltiples proveedores de identida=
des. 
Crear una infraestructura para identidades en red que soporte todos los dis=
positivos actuales y futuros de navegaci=F3n en Internet. 
 

Para lo cual Liberty propone que existan las siguientes funcionalidades:

Federaci=F3n de Identidades 
Es la acci=F3n mediante la cual, un principal puede ligar sus cuentas de di=
versos sitios de una federaci=F3n, para que sea reconocido en estos sitios =
sin la necesidad de proporcionar sus credenciales nuevamente en cada uno de=
 ellos. 

 

Autenticaci=F3n
Soportar cualquier m=E9todo de navegaci=F3n entre proveedores de identidade=
s y proveedores de servicios desde el punto de vista del usuario (incluyend=
o ligas, favoritos o que =E9l mismo teclee la direcci=F3n del sitio en cues=
ti=F3n) y dar m=E9todos de autenticaci=F3n tanto al sitio como al usuario a=
ntes de intercambiar credenciales, as=ED como brindar soporte a los m=E9tod=
os actuales de autenticaci=F3n de usuario sin comprometer contrase=F1as, ce=
rtificados o informaci=F3n privilegiada. 
 

Pseud=F3nimos
Soportar el uso de pseud=F3nimos =FAnicos por federaci=F3n a trav=E9s de to=
dos los proveedores de identidad y servicios 
 

Log-out Global 
Implementar mecanismos para avisar a los proveedores de servicios cuando un=
 principal sale del sistema (log-out)

 

En cuanto a seguridad, existen dos puntos a considerar: 1) el canal de comu=
nicaciones deber=E1 estar encriptado y se deber=E1 proporcionar un medio pa=
ra verificar la autenticidad del proveedor de identidades antes de dar la c=
ontrase=F1a, as=ED como usar certificados en las comunicaciones entre el pr=
oveedor de identidades y el proveedor de servicios; 2) por otro lado, los m=
ensajes en s=ED deber=E1n firmarse y verificarse contra alteraciones, as=
=ED como validar que correspondan a la conversaci=F3n correcta en el tiempo=
 correcto para evitar que alguien reutilice un mensaje anterior.

 

Como arquitectura, Liberty propone que la autenticaci=F3n del usuario ocurr=
a utilizando el redireccionamiento. La redirecci=F3n es un mecanismo del pr=
otocolo http con el cual se puede instruir al dispositivo de navegaci=F3n q=
ue salte a otra p=E1gina, en este caso, al proveedor de identidades para ve=
rificar mediante alg=FAn mecanismo qui=E9n es el principal que nos visita. =
Supongamos que entramos a un sitio habilitado con Liberty y para hacer uso =
de los servicios ofrecidos por este sitio nos pide nuestro usuario y nuestr=
a contrase=F1a; para proporcionarla, el sitio proveer=E1 de una redirecci=
=F3n que nos env=EDe al proveedor de identidades, a=F1adiendo la identifica=
ci=F3n del sitio al que deseamos entrar; de esta forma, el proveedor de ide=
ntidades puede autenticarnos mediante alg=FAn m=E9todo preestablecido (usua=
rio-contrase=F1a, PKI, smartcard, etc) y una vez autenticado, el proveedor =
de identidades env=EDa una nueva redirecci=F3n para que regresemos al sitio=
 original, junto con informaci=F3n codificada que le indique al proveedor d=
e servicios que el usuario fue efectivamente autenticado, el m=E9todo de au=
tenticaci=F3n que se us=F3 y la referencia =FAnica del principal en cuesti=
=F3n, en este proveedor de identidades. De esta manera, el sitio puede conf=
iar en el principal y proveerle los servicios propios de su sitio.

 

=BFY que hay de las cookies (galletas)?

 

Las galletas (cookies) son un mecanismo mediante el cual podemos guardar in=
formaci=F3n en el navegador del principal, o lo que es lo mismo, guardar un=
 seguimiento del mismo. Normalmente los navegadores s=F3lo permiten que un =
sitio lea las galletas que fueron escritas por ese sitio; si quisi=E9ramos =
que muchos servidores en diferentes dominios pudieran leer una misma gallet=
a, tendr=EDamos que pedirle al principal que bajara el nivel de seguridad d=
e su navegador, algo que seguramente no querr=E1 hacer; sin mencionar que e=
n algunas compa=F1=EDas, por pol=EDticas internas, tienen deshabilitado el =
uso de galletas. Por lo anterior, las galletas solo se deber=E1n usar para =
mantener el estado local de una sesi=F3n y se sugiere que no se pase inform=
aci=F3n sensible a trav=E9s de las mismas.

 

Desde la perspectiva del principal, una vez que ha federado su identidad, s=
i visita alguno de los sitios de su c=EDrculo de confianza y proporciona su=
 nombre de usuario y su contrase=F1a, al cambiarse a alg=FAn otro sitio al =
cual ha federado su identidad, el sitio lo reconocer=E1 y no ser=E1 necesar=
io proporcionar contrase=F1a alguna, a menos que as=ED se requiera por la m=
isma seguridad de la operaci=F3n a realizar (pago de servicios, trasferenci=
a de dinero, tr=E1mites, etc).

 

Quiz=E1s la parte m=E1s complicada es la federaci=F3n de identidades de un =
principal en un c=EDrculo de confianza; esto consiste en ligar las diversas=
 cuentas que un principal puede tener en varios sitios que forman un c=EDrc=
ulo de confianza. El proceso inicia en el momento en que el principal, una =
vez proporcionada su contrase=F1a, cambia a otro sitio dentro del c=EDrculo=
 de confianza; en ese momento, este nuevo sitio detecta que el principal po=
see una identidad y le pregunta si desea federarla con el sitio actual, par=
a lo cual el principal tendr=E1 que dar su contrase=F1a local e indicar al =
proveedor de identidades para este c=EDrculo de confianza, qu=E9 atributos =
desea compartir entre estos sitios. Es importante recordar que ning=FAn sit=
io de la federaci=F3n puede ver los datos de las cuentas de este usuario en=
 otros sitios, y que todos los intercambios de informaci=F3n pasan a trav=
=E9s del proveedor de identidades, protegiendo de esta manera, la informaci=
=F3n que el principal decide no compartir en su c=EDrculo de confianza.

 

Para mayor informaci=F3n consulte el sitio http://www.projectliberty.org



---------- Original Message ----------------------------------
From: Ruth del Campo <[email protected]>
Reply-To: SourceID Developers List <[email protected]>
Date:  Thu, 16 Dec 2004 13:00:56 +0100 (CET)

>Hello all, 
>
>I sent the following email to sso users, but I think
>this list should be more apropiate, 
>
>thanks in advance 
>ruth
>
>Hi, 
>
>I am a student and I am doing my diploma thesis about
>identity management.
>
>I have installed SourceID Liberty ID-FF 1.2 toolkit on
>my computer.  I have tested the demo and I have
>noticed that starting from the sp application, it is
>not possible to federate the idp with the sp without
>authenticating first against the sp. That is, the user
>should have an existing account with the sp and
>another with the idp before initializing the
>federation process. 
>Could the user federate to another sp without having
>an account with that sp?   
>Is this implementation specific or does it come from
>Liberty specs?  I was reading liberty specs but it is
>still not  clear to me.
>
>Thanks in advance, 
>Best Regards, 
>
>Ruth del Campo
>
>
>		
>______________________________________________ 
>Renovamos el Correo Yahoo!: =A1250 MB GRATIS! 
>Nuevos servicios, m=E1s seguridad 
>http://correo.yahoo.es
>_______________________________________________
>sso-dev mailing list
>[email protected]
>http://lists.sourceid.org/mailman/listinfo/sso-dev
>