[Fiware-portals] Single Sign out

[Antonio Tapiador del Dujo]

Hola,

Otra opción que se barajó en la reunión sería implementarlo en la parte 
cliente con javascript, de manera que sea el navegador el que hacer las 
llamadas de sign out a las aplicaciones del portal. De esta manera 
resolveríamos el tema de las sesiones. ¿Qué os parece?

Un saludo.

El 11/09/13 11:38, Alvaro Arranz escribió:
> 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 <mailto: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  <http://www.tid.es>
>     email:jhierro at tid.es  <mailto:jhierro at tid.es>
>     twitter:twitter.com/JuanjoHierro  <http://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
>     <mailto:Fiware-portals at lists.fi-ware.eu>
>     https://lists.fi-ware.eu/listinfo/fiware-portals
>
>
>
>
> _______________________________________________
> 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/20130916/69246b68/attachment.html>