FYI We will re-address this email and demand that came to us at our WP8 audio conf of Friday. Also to be further discussed in the context of Access Control GE we had in mind for Second Major Release of FI-WARE. As said next week Daniel and I will organize an audio conf to debrief on OUTSMART - FI-WARE meeting where access control reqts where also reported. Keep you posted and talk with you on Friday. Best Regards, Pascal De : Juanjo Hierro [mailto:jhierro at tid.es] Envoyé : mardi 25 septembre 2012 18:59 À : BISSON Pascal; GIDOIN Daniel; fiware-wpa at lists.fi-ware.eu; stefano de panfilis; robert.seidl at nsn.com; Wolfgang.Steigerwald at telekom.de; jhierro >> "Juan J. Hierro" Objet : Re: [Fiware-wpa] Security aspects and access control to FI-WARE GEs deployed on the FI-WARE Testbed Hi, Thanks to all who attended for the productive confcall. I hope it has helped to put things in the right perspective and understand that it is critical that we tackle the development of all the components that are needed to provide a full framework that supports OAuth2.0-based authenticated access control to APIs provided by any kind of FI-WARE GE. I have updated the slide that I brought for the discussion and shared it with all participants. It is slide 5 in the shared slides in google docs that we have used, which is the one which basically would summarize how OAuth2.0 would be used. I have also write down some notes on slide 4 based on our discussion: https://docs.google.com/presentation/d/1FyaGSaoBif5Avv-Li3m1X6bopk-deG8_OoNC0jYCl0A/edit#slide=id.gfcfffda_2_11 From my perspective, and this is not the first time I have said this but probably not strong enough, I believe that providing all the pieces that are still missing to provide a complete OAuth2.0 framework is critical and one of the tasks we should assign the highest priority for Release 2 of FI-WARE. I believe the whole FI-WARE will be criticized (indeed I would) if we cannot provide such support to FI-PPP Trials in phase 2. I have marked on red in slide 5 the pieces that I'm afraid are missing (not just with circles but in the text). I hope we will plan their development as part of the roadmap of the Security Chapter. One point that we didn't discuss during the confcall but I believe it is also rather important to bear in mind is that we should address development of the Access Control GE in a way that it may also serve for accounting the usage of APIs (accounting of access, you can see this that way). That would pave the way for going the next step beyond and enable to support pay-per-use schemas linked to usage of FI-WARE GE APIs. Usage "CDRs" can be transmitted to the Revenue Share System in the Apps Chapter by the Access Control GE, in order to implement calculation of revenues. Given said all this, we now have to give a response to the UC projects regarding what we can deliver in the short term. In this respect, I would go for the following: * Promise them a paper that will describe the OAuth2.0 framework we aim to support. It doesn't need to be a paper that brings all the details but at least explain what we have in mind (I see this as an elaboration of slides 4 and 5 in the shared presentation). I would rather like to see a first draft of this paper presented during the next virtual FI-PPP AB meeting scheduled on October 18. Furthermore, It would be nice to provide some insights or sketch of the envisioned architecture in the FI-WARE FAQ even earlier to that date. This would be important because the different proposers of UC Trials in the second phase are monitoring this FAQ to design their proposals in a way that they can align with the FI-WARE Vision (see http://forge.fi-ware.eu/plugins/mediawiki/wiki/fiware/index.php/FI-WARE_FAQ). Then, afterwards, we can refine it as part of the contributions from the Security Chapter to the FI-WARE Technical Whitepaper we have asked to develop. A document that we should try to plan delivering for sure before the next project review (i.e., should be available end of October). * Find a quick&dirty solution that we may offer to the UC projects in order to implement their Proof of Concepts that can workaround their control access problems. This is something I have already asked Miguel, as proxy of the FI-WARE Testbed team in the meeting, to look for. Anyway, I believe this is not a major issue and we should come with some solution in the coming days. We would state that the final solution will come with the Second Release of FI-WARE, but therefore will arrive late for their Proof of Concepts. I hope we can agree, please confirm or provide feedback. This is a quite important issue to address properly in the Second Release of FI-WARE. Best regards, -- 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 FI-WARE (European Future Internet Core Platform) Chief Architect 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 On 25/09/12 08:46, Juanjo Hierro wrote: Hi, Just to make sure that we all arrive with the same understanding and expectations to the meeting this afternoon ... I expect that the Security team will come with several alternative ideas we can adopt to solve the question raised by the UC projects. In this respect, I also expect/hope that the Security team will share with us some slides that may help us to understand how they propose that UC projects set up their architecture relying on GEs available on the FI-WARE Testbed. The scenario we want to solve is pretty simple: UC project applications need to invoke APIs provided by some GEs available on the FI-WARE Testbed (just consider the Pub/Sub Broker GE or the Complex Event Processing GE). They need to invoke those APIs from applications that are a) hosted in the FI-WARE Testbed, b) hosted somewhere else, remotely or even c) running on smartphones. They need to do so in a secured way and we also want that no one can invoke APIs exported by our GEs running on the FI-WARE Testbed if it doesn't have the necessary credentials. One issue to solve here is that the GEs that export APIs are not dealing with authentication or management credentials themselves. APIs have mostly been implemented assuming they are invoked by clients with the right credentials. Therefore, I guess we need to co-locate some proxy that intercepts requests in the first place, validate them using some authentication mechanism (OAuth ? here is where I'm looking for your recommendation) and, based on results of such validation, forward the request to the GE instance or reject it (probably reporting to the Security Monitoring GE about a potential risk of attack). I would like to see a sketch of the reference architecture for this simple and critical scenario, where we can envision what pieces (GEs, other auxiliary software) we have to place where. One thing I would like you to bring ideas about is that I would like to approach the target architecture in a way that helps us to perform some accountability about usage of APIs. This may be helpful to integrate with the business framework and support scenarios where a pay-per-use(-of-API) kind of monetization is applied for some GEs. Hope it helps to introduce the meeting this afternoon. For sharing slides, we can use https://join.me You just need to download a very small client application on your windows or mac and then run it locally. It would allow you to share your desktop and generate an URI that you will send to rest of attendees to watch your desktop in their browsers. Depending on the complexity of the slides to be share, it would also be a rather great idea to upload the slides into google docs and produce a shared google docs presentation. This would allow us to share changes in the slides dynamically while we discuss, using it like some sort of whiteboard/blackboard. I have created a blank presentation at: https://docs.google.com/presentation/d/1FyaGSaoBif5Avv-Li3m1X6bopk-deG8_OoNC0jYCl0A/edit#slide=id.p You can try uploading some of your slides by means of clicking on File->Import Slides ... don't worry if the results are not "pretty printable", what matters is that we can play with the shapes, boxes, arrows, etc of any architecture sketch you want to share with us. Thanks, -- 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 FI-WARE (European Future Internet Core Platform) Chief Architect 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 On 20/09/12 12:22, JUAN JOSE HIERRO SUREDA wrote: Event Invitation Title: Security aspects and access control to FI-WARE GEs deployed on the FI-WARE Testbed Location: When: 25 de septiembre de 2012 14:00 - 16:30 Organizer: JUAN JOSE HIERRO SUREDA <jhierro at tid.es><mailto:jhierro at tid.es> Description: When: Tuesday, September 25, 2012 2:00 PM-4:30 PM. (UTC+01:00) Brussels, Copenhagen, Madrid, Paris We'll use powwownow. PIN: 050662. Local dial-in phone numbers at: http://pdf.powwownow.com/pdf/USA_en_pwn-dial-in-numbers.pdf We can use https://join.me<http://join.me<https://join.me%3Chttp:/join.me>> for sharing the screen Background info: one of the issues that were discussed during the last FI-PPP Architecture Board was the issue about access control to APIs exported by FI-WARE GEs deployed on the FI-WARE Testbed. As per know, we are simply applying a filtering on IP addresses that can access to APIs exported by FI-WARE GEs. However, this is not suitable for scenarios where the IP address from which access will be requested in advance (e.g, access from mobile smartphones). A more smart/flexible approach should be feasible relying on the Identity Management GE that should enable filtering not based on the IP addresses but the authenticated entity on behalf requests to APIs are issued. We need to establish a recommendation about how the Use Case projects should design their architecture of their PoC in order to implement an authenticated and single sign-on access architecture to APIs based on the Identity Management GEs. Such recommendation may help to enrich documentation of the FI-WARE Reference Architecture. I believe that this, far to be a problem, is an opportunity to push usage of Identity Management GEs by Use Case Projects. ________________________________ 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 Comment: Attendees: BISSON Pascal <pascal.bisson at thalesgroup.com><mailto:pascal.bisson at thalesgroup.com> GIDOIN Daniel <daniel.gidoin at thalesgroup.com><mailto:daniel.gidoin at thalesgroup.com> fiware-wpa at lists.fi-ware.eu<mailto:fiware-wpa at lists.fi-ware.eu> <fiware-wpa at lists.fi-ware.eu><mailto:fiware-wpa at lists.fi-ware.eu> stefano de panfilis <stefano.depanfilis at eng.it><mailto:stefano.depanfilis at eng.it> robert.seidl at nsn.com<mailto:robert.seidl at nsn.com> <robert.seidl at nsn.com><mailto:robert.seidl at nsn.com> Wolfgang.Steigerwald at telekom.de<mailto:Wolfgang.Steigerwald at telekom.de> <Wolfgang.Steigerwald at telekom.de><mailto:Wolfgang.Steigerwald at telekom.de> _______________________________________________ Fiware-wpa mailing list Fiware-wpa at lists.fi-ware.eu<mailto:Fiware-wpa at lists.fi-ware.eu> http://lists.fi-ware.eu/listinfo/fiware-wpa ________________________________ 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-wpa mailing list Fiware-wpa at lists.fi-ware.eu<mailto:Fiware-wpa at lists.fi-ware.eu> http://lists.fi-ware.eu/listinfo/fiware-wpa ________________________________ 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.fiware.org/private/old-fiware-security/attachments/20120926/48091c2f/attachment.html>
You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy Cookies policy