Estupendo. No hay problema entonces tanto en Mashup como en Store? Cuando tengáis la URL y el verbo HTTP, pasádnoslo por favor. Un saludo. El 02/10/13 22:47, Alvaro Arranz escribió: > Hola, > > siento tardar en responder, el proporcionar un endpoint para que se > haga el logout de nuestras aplicaciones no es ningún problema. Ahora, > ¿el CORS te refieres para hacer peticiones al IdM? vamos en principio > el problema con el CORS es para leer las respuestas, supongo que no es > interesante la respuesta que pueda devolver este endpoint de logout, > si funciona bien y si no ha funcionado seguramente sea porque no > estaba el usuario loggeado, ¿no?. De todas formas, otra vez, nosotros > no tenemos ningún problema en hacer que este endpoint devuelva las > cabeceras necesarias para que funcione el CORS. > > Un saludo. > > 2013/9/18 Antonio Tapiador del Dujo <atapiador at dit.upm.es > <mailto:atapiador at dit.upm.es>> > > 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/20131003/ed5567cb/attachment.html>
You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy Cookies policy