Hi Robert, Our implementation complies with the OAuth specification described at http://forge.fi-ware.eu/plugins/mediawiki/wiki/fiware/index.php/FIWARE.ArchitectureDescription.Identity_Management_Generic_Enabler#OAuth However, I just discovered another endpoint definition at: http://forge.fi-ware.eu/plugins/mediawiki/wiki/fiware/index.php/Identity_Management_Generic_Enabler_API_Specification#Resources_Summary I think I would be nice if we agree in only one path for the endpoints. All the code is available at https://github.com/ging/fi-ware-idm There is documentation about how to use the deployed instance at https://github.com/ging/fi-ware-idm/wiki/Using-the-deployed-instance However, the API part regarding user information has to be revisited in order to comply with the SCIM standard. Kind regards. El 24/07/13 14:53, Seidl, Robert (NSN - DE/Munich) escribió: > > Hi Antonio, > > could you please send us some documentation about your development in > order to get an overview of the features? > > In addition it would be nice getting access to the portal and getting > some knowledge about the capabilities of the portal. > > Many thanks in advance > > Robert > > *From:*fiware-api-cross-bounces at lists.fi-ware.eu > [mailto:fiware-api-cross-bounces at lists.fi-ware.eu] *On Behalf Of *ext > Antonio Tapiador del Dujo > *Sent:* Tuesday, July 23, 2013 3:24 PM > *To:* fiware-api-cross at lists.fi-ware.eu > *Subject:* Re: [Fiware-api-cross] IMPORTANT status of IdM GE open > specifications and IdM solution in OIL > > 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> > <mailto:robert.seidl at nsn.com> > > *To: *** > > > > ext DANGERVILLE Cyril <cyril.dangerville at thalesgroup.com> > <mailto:cyril.dangerville at thalesgroup.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> > > 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 > <mailto:fiware-api-cross at lists.fi-ware.eu> > *Cc:* Wolfgang.Steigerwald at telekom.de > <mailto: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> > <mailto: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 <mailto: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/20130725/d3764f08/attachment.html>
You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy Cookies policy