Dear all, As you know, UPM started to develop an open source FI-WARE IdM GEi (GE implementation). It is our intend to make it comply with the FI-WARE IdM GE specifications. We started this development upon request from Telefonica, as coordinator of FI-WARE. Our open source FI-WARE IdM GEi relies on previous work so we didn't need to start it from the scratch. This allowed us to get a demo of the OAuth-based access control framework, integrating with Thales' Access Control GEi, ready for the last FI-WARE project official review. Regarding the standard OAuth REST API, we already support the full specification of OAuth 2.0 and Bearer token Usage, as specified in RFC 6749 http://tools.ietf.org/html/rfc6749 and RFC 6750 http://tools.ietf.org/html/rfc6750 Regarding steps of the presentation sent by Juanjo, we already support all the steps related to the IdM GE, and we are finishing the policy storage step with Thales' PDP. Regarding the API to be supported for user/groups creation, and updates about info for user/groups, including roles assigned to users/groups, we agree that adoption of the SCIM 2.0 as part of the FI-WARE IdM GE specifications could be a good approach and we are happy to evolve our software to comply with the SCIM 2.0 open specifications. As already explained by Juanjo, we are developing a portal, which can be integrated as part of the FI-WARE OIL portal, that deals with base user/groups account management, as well as definition of roles and permissions linked to applications. That version of the portal commits to be compatible with any FI-WARE IdM GEi that supports the standard APIs we can agree on for the IdM GE. It will rely on the current set of APIs from our FI-WARE IdM GEi (those dealing with user/groups account management being proprietary) until we confirm to adopt the SCIM 2.0 specifications, but we commit to migrate it as to use SCIM 2.0 APIs as soon as possible, in parallel to support of the SCIM 2.0 open specifications by our FI-WARE IdM GEi. Kind regards. El 22/07/13 09:29, Juanjo Hierro escribió: > Hi all, > > I have seen litlle activity on the mailing list so I would like to > catch-up and double-check where we are. Besides this, I want to > share with you what my proposed plan is regarding the FI-WARE Testbed > and OIL. > > *1. About FI-WARE IdM GE Open Specifications.* > > I believe that what has been delivered at: > > http://forge.fi-ware.eu/plugins/mediawiki/wiki/fiware/index.php/Identity_Management_Generic_Enabler_API_Specification > > > still remains not to be what is expected. As simple as that. A > developer or potential implementor of the specs will expect to see a > complete RESTful API specification. What we are delivering there is > just a reference to the sites where two GEis (the one from NSN and DT) > are supposed to be deployed and delivering IdM functions "as a > Service". However, that is totally different from a RESTful API > specification, which is the complete specifications of the operations > to be supported through the API. > > As discussed several times, the IdM GEs shall comprise a set of > RESTful APIs, some of which will map to certain standard > specification. It should be ok to provide a link to the website > where such standard specifications can be found. We don't need to > clone them in our wiki pages. In any case, some clarifications maybe > needed (e.g., describing how we have addressed those parts of the > specifications that may be a bit ambiguous or what choices we have > adopted whenever multiple options are allowed). But a link to the > spec should be there, rather than a link to the service end point > where some concrete FI-WARE IdM GEi instances have been deployed. > That information belongs to the FI-WARE Catalogue instead (tab > "Instances" of the corresponding entry). > > Therefore, I hope that you will implement the necessary changes to > the FI-WARE IdM GE open specs to comply with what is necessary. > > Besides this, all we know that, as part of the complete set of APIs > to be supported, an IdM GE shall support an API that allows to define > user and user groups, attributes to link to each of them, including > roles. Therefore, I expect a spec covering the mentioned operations > to be published as part of the FI-WARE IdM GE open specifications. > Some people may argue that there is not widely adopted standard here, > but precisely one of the added values of FI-WARE should be that of > proposing a standard for areas where such a standard may not exist or > may have not yet gained enough momentum (FI-WARE hopefully helping > those candidate standards to gain that momentum). > > So far, Thales (Cyril) proposed SCIM 2.0, which I found simple yet > powerful enough and, moreover, seems to take the direction of becoming > a IETF standard. Can we agree in embracing that spec ? Hopefully > yes, in which case I would like to know who from the existing FI-WARE > GEis in the game (NSN, DT and, now, UPM) is going to support which > subset of the SCIM 2.0 as part of Release 2 (although not delivered by > end of June). Besides, we should capture the agreement about > embracing the SCIM 2.0 specs as part of the FI-WARE IdM GE Open > Specifications (how much each FI-WARE IdM GEi would comply with this > specification would be specified in the corresponding entry at the > FI-WARE Catalogue) > > Last but not least, we should take a final decision whether we are > going to adopt the approach outlined in slide 1 or slide 2 of the > attached presentation. Personally, I have got convinced that we > should go for the option described in slide 2 but I'm happy to > adapt. In any case, the final approach should be documented > somewhere in the specs (either of the whole chapter or the IdM GE). > What should stand clear, on the other hand, is that the operation in > step 10 of slide 2 (or step 11 of slide 1) should be part of the > FI-WARE IdM GE Open Specifications. I trust that can organize to > achieve that goal. > > Can Thales confirm it will take the necessary steps to organize the > revision of the specs, to be made publicly available on the FI-WARE > wiki, according to the above ? > > > *2. About IdM solution in OIL* > > We need to go for a IdM solution in OIL and it is rather clear that > such solution should comply with the following requirements: > > 1. It should come with a portal that complies with the FI-WARE style > guidelines for websites and which coordinates with the rest of > portals of the FI-WARE OIL (Cloud, Store, WireCloud, potentially > Dev) as to ensure a common user experience > 2. It should provide a mechanism enabling users (any third party) to > self-register in the FI-WARE OIL. > 3. Someone has to assume the responsibility of handling privacy of > data from users who have registered an account. In more formal > terms, someone should be able to assume the role and > responsibilities of the Account Management Provider as described > in the last drafts of the FI-WARE Open Innovation Lab Terms and > Conditions. > 4. It should provide a standard RESTful API for all the interactions > described in the API Access Control framework (see attached > presentation) > 5. It should provide a enough meaningful subset of the SCIM 2.0 > RESTful API > > > As per now, the only one IdM GEi that I know complies with 1/ is the > one coming from UPM. I know that UPM's supports 2/ but honestly > don't know about the others. Using UPM's IdM GEi, Telefonica is > happy to assume point 3/ and, pending of their confirmation, I assume > UPM's IdM GEi could cover 4/ and 5/. > > What would be the situation regarding NSN's and DT's IdM GEis ? Do > they comply with 1/ ? Do they support 2/ ? Who would assume 3/ ? > Could you confirm 4/ ? What is your take with respect to 5/ ? > > This is what respect to OIL. Regarding the FI-WARE Testbed > (environment to be provided to UC projects), I guess we can still > provide the three IdM GEis (UPM's properly integrated with the FI-WARE > Cloud portal). > > Your feedback is welcome. > > Best regards, > > > -- Juanjo > > > -------- Original Message -------- > Subject: Re: [Fiware-api-cross] IdM GE Common RESTful API proposal > for getting/managing user attributes > Date: Wed, 12 Jun 2013 09:32:21 +0000 > From: Seidl, Robert (NSN - DE/Munich) <robert.seidl at nsn.com> > To: ext DANGERVILLE Cyril <cyril.dangerville at thalesgroup.com> > CC: fiware-api-cross at lists.fi-ware.eu > <fiware-api-cross at lists.fi-ware.eu> > > > > Hi Cyril, > > we checked it internally and the result is, that it works fine for NSN. > > The specification seems to be clear and understandable, so that we > don't need any additional information by now. > > Only thing is that we estimated that we would need 3-4 weeks for > implementation. > > Since we have to submit our second release of the IDM end of June, we > could start in July. > > Would this fit your time plan? > > Greetings > > Robert > > *From:*ext DANGERVILLE Cyril [mailto:cyril.dangerville at thalesgroup.com] > *Sent:* Sunday, June 09, 2013 2:39 PM > *To:* fiware-api-cross at lists.fi-ware.eu > *Cc:* Wolfgang.Steigerwald at telekom.de; Seidl, Robert (NSN - DE/Munich) > *Subject:* IdM GE Common RESTful API proposal for getting/managing > user attributes > > Hello, > > I though this message had made its way to the mailing list but > apparently not (see mail at the bottom). This is an interesting matter > for this mailing list since it's about common APIs. > > Following up the meeting of June 6, here is the link to a candidate > **standard for "simple" user identity management** that you may > consider for the IdM GE Open specification: > > **System for Cross-domain Identity Management** (SCIM): > > http://www.simplecloud.info/ > > If you go to "Specifications" you have a link to "REST API" for each > release. > > As the owner of the Access Control GE, I am only interested in the API > for getting user attributes (user = OAuth resource owner OR client in > the context of the GE), i.e. section 3.2.1 Retrieving a known > Resource. (A user is particular type of Resource for example, see the > Overview or Core schema for more info.) > > Just a suggestion, please consider, thanks. > > Regards, > > Cyril D > > Access Control GE Owner > > *Delivery has failed to these recipients or distribution lists:* > > fiware-api-cross at lists.fi-ware.eu > <mailto:fiware-api-cross at lists.fi-ware.eu> > A problem occurred during the delivery of this message. Microsoft > Exchange will not try to redeliver this message for you. Please try > resending this message later, or provide the following diagnostic text > to your system administrator. > > *Diagnostic information for administrators:* > > Generating server: thsbbfxrt01p.thalesgroup.com > > fiware-api-cross at lists.fi-ware.eu > <mailto:fiware-api-cross at lists.fi-ware.eu> > #< #5.4.4 X-Postfix; Host or domain name not found. Name service error > for name=lists.fi-ware.eu type=AAAA: Host not found> #SMTP# > > Original message headers: > > Return-Path: <cyril.dangerville at thalesgroup.com > <mailto:cyril.dangerville at thalesgroup.com>> > Received: from thsbbfxrt01p.thalesgroup.com (localhost > [127.0.0.1]) by > localhost (Postfix) with SMTP id 8762D6C9; Thu, 6 Jun 2013 > 14:46:40 +0200 > (CEST) > X-Thales-IRT1: IRT11 > X-Thales-IRT1: IRT11 > X-Thales-IRT1: IRT11 > From: DANGERVILLE Cyril <cyril.dangerville at thalesgroup.com > <mailto:cyril.dangerville at thalesgroup.com>> > To: "Wolfgang.Steigerwald at telekom.de > <mailto:Wolfgang.Steigerwald at telekom.de>" > <Wolfgang.Steigerwald at telekom.de > <mailto:Wolfgang.Steigerwald at telekom.de>>, > "robert.seidl at nsn.com <mailto:robert.seidl at nsn.com>" > <robert.seidl at nsn.com <mailto:robert.seidl at nsn.com>> > CC: "fiware-api-cross at lists.fi-ware.eu > <mailto:fiware-api-cross at lists.fi-ware.eu>" > <fiware-api-cross at lists.fi-ware.eu > <mailto:fiware-api-cross at lists.fi-ware.eu>> > Date: Thu, 6 Jun 2013 14:46:37 +0200 > Subject: IdM GE Common RESTful API proposal for getting/managing user > attributes > Thread-Topic: IdM GE Common RESTful API proposal for getting/managing user > attributes > Thread-Index: Ac5hzJanc6oeXwigTkygMJC8vg1iXgAIm3zQAC8rujA= > Message-ID: > <14379_1370522800_51B084B0_14379_14127_2_DDCC8EDACD06614C9CE3DFEA2835890070C5CF8E71 at THSONEA01CMS10P.one.grp> > References: > <CE8995AB5D178F44A2154F5C9A97CAF40255A5BB8424 at HE111541.emea1.cds.t-internal.com > <mailto:CE8995AB5D178F44A2154F5C9A97CAF40255A5BB8424 at HE111541.emea1.cds.t-internal.com>> > <12328_1370440156_51AF41DC_12328_477_1_DDCC8EDACD06614C9CE3DFEA2835890070C5CF8989 at THSONEA01CMS10P.one.grp > <mailto:12328_1370440156_51AF41DC_12328_477_1_DDCC8EDACD06614C9CE3DFEA2835890070C5CF8989 at THSONEA01CMS10P.one.grp>> > In-Reply-To: > <12328_1370440156_51AF41DC_12328_477_1_DDCC8EDACD06614C9CE3DFEA2835890070C5CF8989 at THSONEA01CMS10P.one.grp > <mailto:12328_1370440156_51AF41DC_12328_477_1_DDCC8EDACD06614C9CE3DFEA2835890070C5CF8989 at THSONEA01CMS10P.one.grp>> > Accept-Language: en-US, fr-FR > Content-Language: fr-FR > X-MS-Has-Attach: > X-MS-TNEF-Correlator: > acceptlanguage: en-US, fr-FR > x-pmwin-version: 3.1.0.0, Antivirus-Engine: 3.43.0, Antivirus-Data: 4.89G > Content-Type: multipart/alternative; > > boundary="_000_DDCC8EDACD06614C9CE3DFEA2835890070C5CF8E71THSONEA01CMS1_" > MIME-Version: 1.0 > > > > > ------------------------------------------------------------------------ > > 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-api-cross mailing list > Fiware-api-cross at lists.fi-ware.eu > https://lists.fi-ware.eu/listinfo/fiware-api-cross -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.fiware.org/private/fiware-api-cross/attachments/20130723/696fa0d4/attachment.html>
You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy Cookies policy