[Fiware-portals] Single Sign out

[Alvaro Arranz]

Hola Juanjo,

realmente el problema es que no se dio una solución, se comentó que iba a
haber ese problema y que habría que darle una solución. Esto paso en la
primera reunión de agosto. Yo propuse en la segunda reunión de agosto que
esto podría solucionarse si el IdM notificara a las aplicaciones implicadas
de que el usuario ha cerrado la sesión, pero evidentemente era algo para
estudiar, sobre todo entiendo que estudiar por el equipo del IdM dado que
son los que conocen mejor que es lo que se puede hacer y que es lo que
realmente puede encajar en la arquitectura.

Personalmente he estado pensando y puede que tenga algunas lagunas, de
tipo, si un usuario está loggeado en dos ordenadores, ¿tiene sentido que si
te desconectas de uno se cierre la sesión del otro?. Son casos extremos,
pero que por otra parte, por ejemplo Google, los cuidan muy bien, y yo no
sé que posibilidades hay de que esto funcione igual si se implementa el
single sign off usando la estrategia que propuse. El problema estaría en
que el IdM da un token diferente a cada Applicación, por lo tanto, la única
forma que veo ahora mismo para notificar que un usuario ha cerrado la
sesión es indicando el identificador del usuario, y por lo tanto las
aplicaciones no sabrían diferenciar que sesión tienen que cerrar. ¿Podría
el idm guardar una lista con los tokens que ha dado usando la misma sesión
interna del IdM?¿podría esta ser la solución?

De todas formas, lo que yo si veo claro es que es el idm el que se tiene
que encargar de proporcionar esta solución, dado que es la pieza central
que conoce a que aplicaciones tiene acceso un usuario.

Por otro lado, ya aviso, que nuestra idea es que los widgets de wirecloud
accedan al resto de servicios (context broker, object storage, etc...)
usando el token que le haya dado el IdM a wirecloud. El principal problema
es que ese token sirve para pedir info al IdM en nombre de la aplicación a
la que está asociada el token. Ejemplo:

   1. Wirecloud le pasa el token que tiene a una instancia del object
   storage.
   2. El object storage usaría el token para ver si el usuario tiene
   permisos para acceder, pero el token siempre le daría acceso dado que
   realmente está ligado a wirecloud y dado que el IdM ya se lo ha dado,
   siempre sería válido, *independientemente de si el usuario tiene acceso
   a esa instancia*.
   3. Si el object storage usa ese token para pedir la información de roles
   y tal al IdM, este *recibiría la info correspondiente a los roles de
   Wirecloud*, no a los del object storage.

Nosotros, para el store y para la campus party, la solución que hemos usado
es que el store cuando recibe peticiones de wirecloud usando tokens del
IdM, es la siguiente: el token se utiliza para obtener info del usuario,
con esa información se busca el último token que el IdM le ha dado a la
Store para ese usuario y este es el que se utiliza para pedir la
información necesaria del IdM para la store (posiblemente el token ha
caducado de alguna manera, y es el caso en el que el store refresca el
token).

Evidentemente con la Campus Party y tal, no ha habido tiempo para entra en
más detalles, pero ya iré mandando más correos con problemas con esta parte
de la integración.

Un saludo.



2013/9/10 Juanjo Hierro <jhierro at tid.es>

>  Hola,
>
>   Ahora que ha pasado la Campus, deberíamos ponernos manos a la obra con
> el desarrollo de lo que hiciera falta para implementar el Single Sign-out
> ...
>
>   ¿ Quiere alguien romper el hielo en esta misma lista y recordarnos que
> solución se había propuesto y acordado allá por finales de Julio o
> principios de Agosto para confirmar que todos estamos de acuerdo con la
> misma y pasar a implementarla ?
>
>   Gracias,
>
>  -- Juanjo
>
> -------------
> Product Development and Innovation (PDI) - Telefonica Digital
> website: www.tid.es
> email: jhierro at tid.es
> twitter: twitter.com/JuanjoHierro
>
> FI-WARE (European Future Internet Core Platform) Coordinator
> and Chief Architect
>
> FI-PPP Architecture Board chairman
>
> You can follow FI-WARE at:
>   website:  http://www.fi-ware.eu
>   facebook: http://www.facebook.com/pages/FI-WARE/251366491587242
>   twitter:  http://twitter.com/FIware
>   linkedIn: http://www.linkedin.com/groups/FIWARE-4239932
>
>
> ------------------------------
>
> Este mensaje se dirige exclusivamente a su destinatario. Puede consultar
> nuestra política de envío y recepción de correo electrónico en el enlace
> situado más abajo.
> This message is intended exclusively for its addressee. We only send and
> receive email on the basis of the terms set out at:
> http://www.tid.es/ES/PAGINAS/disclaimer.aspx
>
> _______________________________________________
> Fiware-portals mailing list
> Fiware-portals at lists.fi-ware.eu
> https://lists.fi-ware.eu/listinfo/fiware-portals
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fiware.org/private/fiware-portals/attachments/20130911/4bbd4efb/attachment.html>