[Fiware-portals] Single Sign out

[Javier Cerviño]

Hola Alvaro,

Solo una cosa relativa a los tokens. Para los GE una vez que usen el Proxy
de OAuth se podra usar tal cual el token del IDM. Pero ojo, que los GE del
Cloud (como es el caso del object storage) funcionan de forma diferente al
usar Keystone como punto de entrada. La solución pasa por pedir un segundo
token a Keystone usando el token del IDM. En breve haremos un webinar de
OAuth y explicaremos lo que hay que hacer.

Saludos,
Javi.


2013/9/11 Alvaro Arranz <aarranz at conwet.com>

> 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 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/c8ac10a3/attachment.html>