Hola Alvaro, efectivamente. Serían peticiones AJAX a cada una de las aplicaciones. Nosotros proporcionaríamos el javascript integrado en la barra superior, pero cada portal nos tendríais que proporcionar la llamada HTTP correspondiente, además de gestionar el tema de CORS ¿Cómo lo véis? El 18/09/13 15:05, Alvaro Arranz escribió: > 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 > <mailto: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 <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 <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 > <mailto: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/4618a02e/attachment.html>
You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy Cookies policy