[Fiware-api-cross] IMPORTANT status of IdM GE open specifications and IdM solution in OIL

[Seidl, Robert (NSN - DE/Munich)]

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/20130724/31dfcbd2/attachment.html>