Hola Javi, no sé si el webinar ya ha tenido lugar, ¿alguna documentación sobre este asunto? Un saludo. 2013/9/11 Javier Cerviño <jcague at gmail.com> > 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/20131002/55a38867/attachment.html>
You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy Cookies policy