[Fiware-portals] Single Sign out

[Alvaro Arranz]

Hola Antonio,

ok, entonces lo que propones es que hagamos una petición ajax a cada una de
las URL de las aplicaciones para el sign out, ¿no?, la lista de URLs nos la
tendrá que pasar el IDM, supongo.

Un saludo.


2013/9/16 Antonio Tapiador del Dujo <atapiador at dit.upm.es>

>  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>
>
>>  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
>>
>>
>
>
> _______________________________________________
> Fiware-portals mailing listFiware-portals at lists.fi-ware.euhttps://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/20130918/30eb9642/attachment.html>