I would go for 2.0 because that way FI-WARE will provide the value of implementing the very last version of the specs. It's true that it may be a bit risky, but the advantages of being one of the first players providing an implementation of 2.0 pay the risk because it will foster adoption and awareness 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) 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
On 29/07/13 15:10, Seidl, Robert (NSN - DE/Munich) wrote:
Hi Cyril,
when you're back from holiday we have to agree on which version of SCIM we should use for our implementation.
Gabor mentioned that he couldn't find any major difference between version 1.1. and 2.0.
>From our side it doesn't matter which version we will choose, so we will rely on your experience :)
Greetings
Robert
From: ext DANGERVILLE Cyril [mailto:cyril.dangerville at thalesgroup.com]
Sent: Thursday, July 25, 2013 5:20 PM
To: Seidl, Robert (NSN - DE/Munich); ext Juanjo Hierro; Fiware-api-cross at lists.fi-ware.eu<mailto:Fiware-api-cross at lists.fi-ware.eu>
Cc: Goetze, Norbert (NSN - DE/Munich); Gesztesi, Gabor (EXT-Other - HU/Budapest); 'istvan.zolyomi at gmail.com<mailto:istvan.zolyomi at gmail.com>'; Bauer-Hermann, Markus (EXT-Tieto - DE/Munich); Meyer, Gerald (NSN - DE/Munich); ext Wolfgang.Steigerwald at telekom.de<mailto:Wolfgang.Steigerwald at telekom.de>; GIDOIN Daniel; BISSON Pascal
Subject: RE: [Fiware-api-cross] IMPORTANT status of IdM GE open specification and IdM solution in OIL
Hello Juanjo,
To the question "Can Thales confirm it will take...", I am prepared to revise the specs, at least the ones to be used by the Access Control GE. In details, these are:
1) OAuth access token validation
2) Retrieving end-user (resource owner) or client attributes, with an access token as request parameter (it may be done in the same operation as 1) as seen with Gabor)
3) Retrieving end-user/client attributes with a userID/clientID as parameter (see SCIM).
For APIs that are related to OTHER aspects of IdM (not listed above), I would prefer to leave the decisions completely to IdM GE owners/experts. Unless you or Pascal (Bisson)see some specific reason for Thales to do it, besides the fact I was the one to propose SCIM.
Besides, I have just a couple of comments regarding the SCIM version, and which architecture alternative to use:
1. I recommended SCIM indeed, but not a specific version. In fact, I think the v1.1 is less risky (and good enough?) for the moment as it is stable. The v2.0 is still a draft and therefore potentially subject to big changes, so I suggest we consider it only when it is stable. This comment aside, I have a feeling that IdM GE owners are eager to support/implement SCIM 2.0 draft right away, and I will not try to fight the wave here. As far as the Access Control GE is concerned, SCIM 1.1 is enough.
2. It is hard to keep only one approach between slides 1 and 2 (and another intermediary option 3 that I presented only in the webinar so far), because there are pros and cons for both of them, depending on the use case. Robert gave good arguments for 1st solution, and you may have good arguments for the 2nd solution as well. So I would prefer to keep options, but make them look like different profiles of the same solution, addressing different use cases. I think a sequence diagram would be better than the flow diagrams in the slides to show alternatives. This is current practice among standards (e.g. Oauth) to have such profiles. We will then provide hints to the implementers/developers/use case projects to decide on which one to select for their needs. We can also promote one option more than the other (slide 2 more than slide 1 ?), and keep the other one(s) for "advanced" use cases.
Regards,
Cyril
--
Cyril DANGERVILLE, Thales Services
FI-WARE WP8 Security Chapter
Access Control GE Owner
Thales R&T
Campus Polytechnique
1, avenue Augustin Fresnel
91767 Palaiseau cedex
France
Office: +33 (0)1 69 41 59 66
Fax: +33 (0)1 69 41 55 63
De : Seidl, Robert (NSN - DE/Munich) [mailto:robert.seidl at nsn.com]
Envoyé : jeudi 25 juillet 2013 11:53
À : ext Juanjo Hierro; Fiware-api-cross at lists.fi-ware.eu<mailto:Fiware-api-cross at lists.fi-ware.eu>
Cc : Goetze, Norbert (NSN - DE/Munich); Gesztesi, Gabor (EXT-Other - HU/Budapest); 'istvan.zolyomi at gmail.com<mailto:istvan.zolyomi at gmail.com>'; Bauer-Hermann, Markus (EXT-Tieto - DE/Munich); Meyer, Gerald (NSN - DE/Munich); ext Wolfgang.Steigerwald at telekom.de<mailto:Wolfgang.Steigerwald at telekom.de>; GIDOIN Daniel; BISSON Pascal; DANGERVILLE Cyril
Objet : RE: [Fiware-api-cross] IMPORTANT status of IdM GE open specification and IdM solution in OIL
Dear Juanjo, all,
please find the answers related to NSN IDM GE (Deutsche Telekom will follow due to holiday season) to your first bullet point (1. About FI-WARE IdM GE Open Specifications) hereafter and the answers to your second bullet point (2. About IdM solution in OIL) directly in your email text below.
Furthermore you will receive a separate email from Thales regarding the questions addressed to them.
NSN's answer to "About FI-WARE IdM GE Open Specifications ":
Please find attached to this email a table providing an overview about the supported protocols/interfaces for the NSN IDM GE.
Here a short summery of the data in the table:
- OAuth 2.0 and Bearer token Usage are also supported by NSN IDM GE. They are as much RESTful as the corresponding standards are.
- We also support OpenID Connect for standard Single Sign-On extension to OAuth.
- A subset of SCIM 2.0 will be supported for user and role management. It is implemented in 2 phases with operations required by FI-PPP Use Case Projects first.
- Not all functionalities required by the IDM + AC GE integration are supported by the standards, so an additional token information REST endpoint will be provided as an extension.
- Additionally SAML 2.0 SSO and attributes are supported. However there was a major version change and this functionality is not yet moved to the new version. Therefore the old version is also kept available.
For the question related to the slides, we would vote for the 1st solution (when the Access Control GE asks the IDM for attributes). It has several advantages. For example:
- There is only one AC GE, while there will be several PEPs depending on the interfaces to be protected. So this way the client need to be implemented only once
- Only the AC GE need to have access to the sensitive interface (less certificates needed, easier setup, less points to attack)
- The PDP can better decide which XACML attributes are necessary to evaluate the request.
It makes little difference from our point-of-view, so we can live with both options.
We are not even sure it is necessary to make a centralized decision.
Like the XACML standard it can be implemented in different ways.
If the attribute is not included in the request, the PDP can ask (using the PIP) the IdM.
NSN's answer to "2. About IdM solution in OIL":
Please refer to the answers inline in your email below.
Greetings
Robert
From: fiware-api-cross-bounces at lists.fi-ware.eu<mailto:fiware-api-cross-bounces at lists.fi-ware.eu> [mailto:fiware-api-cross-bounces at lists.fi-ware.eu] On Behalf Of ext Juanjo Hierro
Sent: Monday, July 22, 2013 9:30 AM
To: Fiware-api-cross at lists.fi-ware.eu<mailto:Fiware-api-cross at lists.fi-ware.eu>
Subject: [Fiware-api-cross] IMPORTANT status of IdM GE open specifications and IdM solution in OIL
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
--> The NSN IDM GE is flexible in order to integrate different style guides. It is possible to switch between different styles in order to get different "look and feel" views.
1. It should provide a mechanism enabling users (any third party) to self-register in the FI-WARE OIL.
--> This will be supported (see attached table). The operations and functionalities are already there, the business logic is under development (supported via SCIM api).
1. 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.
--> There is a shared responsibility between the Access Control GE owner and the IDM GE owner.
For the data stored in the IDM data base (residing next to the IDM GE at NSN premises) they can be considered as privacy respecting, however the requests from the access control GE have to be controlled since the IDM is simply executing these requests.
1. It should provide a standard RESTful API for all the interactions described in the API Access Control framework (see attached presentation)
--> We will provide this RESTful api's. It will be not standard since SCIM doesn't support all the functionalities which are required, but it can be seen as an extension to SCIM.
We were also searching for alternative solutions, but didn't find anything else which is standard and can be used.
1. It should provide a enough meaningful subset of the SCIM 2.0 RESTful API
--> Please have a look at the table, limited subset will be supported in the first release in order to support the UC projects which requested to integrate the IDM solution.
A full version will be supported in the final version.
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
________________________________
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/fiware-api-cross/attachments/20130805/03028ad7/attachment.html>
You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy Cookies policy