Hola Javier, ok :). De todas formas, recordar que por ejemplo, nosotros no podemos hacer uso del vuestro proxy ni en Wirecloud ni en la Store, dado que tenemos parte de font-end que no puede requerir autenticación directamente (dado que en caso de no estar autenticado, la petición tiene que seguir siendo aceptada para redirigir al IdM) y parte de API Rest que, en general, si requieren que el usuario esté autenticado. Por lo tanto, dado que de momento nosotros tenemos nuestra propia integración con el IdM, necesitamos info para implementar y mimetizar vuestro comportamiento para pedir los segundos tokens. También indicar que si se va a seguir para adelante con la "migración de tokens", puede que se diera un problema de seguridad, y por lo tanto habría que proteger las peticiones al IdM con algo más, por ejemplo con el secret de la aplicación. Por ejemplo, si Wirecloud es capaz de generar un token para el object storage, este podría tanto usarlo para hacer peticiones al object storage como para hacer peticiones al IdM para pedir los roles que tiene el usuario dentro del object storage. Realmente no sé si esto es un fallo de seguridad o no es algo tan grave. Un caso de uso por parte de Wirecloud sería que los widget podrían saber los permisos de un usuario respecto al object storage y proporcionar una interfaz acorde a estos. Por ejemplo, si un usuario no tiene permisos para subir ficheros y hay un widget con un botón para subir ficheros, este podría deshabilitarlo o no mostrarlo. Un saludo. Álvaro 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/20130911/aca46a5e/attachment.html>
You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy Cookies policy