From cyril.dangerville at thalesgroup.com Wed Jun 5 15:49:14 2013 From: cyril.dangerville at thalesgroup.com (DANGERVILLE Cyril) Date: Wed, 5 Jun 2013 15:49:14 +0200 Subject: [Fiware-api-cross] Meeting in Paris In-Reply-To: References: Message-ID: <12328_1370440156_51AF41DC_12328_477_1_DDCC8EDACD06614C9CE3DFEA2835890070C5CF8989@THSONEA01CMS10P.one.grp> Hello IdM GE owners, I have a few technical issues that I'd like to discuss during the plenary meeting tomorrow, just for you to check, or you can answer by email if you prefer : - @Wolfgang (DT Global Customer Platform): o RESTful API for OAuth access token validation (i.e. send the access token to the IdM GE for validation): I think you mentioned such an API during one of our weekly conf calls but I could not find it in the latest documentation (GCP API documentation_v0-3.docx) you sent me/us. I would like to get more info on this to check whether there is any added value compared to validating the signature directly in the PDP. o OAuth client authentication to the OAuth Token service: require login/password authentication - or other standard auth method - to get an access token (e.g. in exchange for an authorization code) - @Robert (NSN One-IDM): o Creation of IdM instance for testing o Documentation on OAuth API usage, in particular: ? OAuth access token format (JWT?) ? How to validate the token: JWT signature checking? RESTful API? ? How to get extra attributes on the resource-owner and OAuth client (esp. client ID) associated to the token Regards, Cyril D De : fiware-security-bounces at lists.fi-ware.eu [mailto:fiware-security-bounces at lists.fi-ware.eu] De la part de Wolfgang.Steigerwald at telekom.de Envoy? : mercredi 5 juin 2013 11:11 ? : robert.seidl at nsn.com Cc : fiware-security at lists.fi-ware.eu Objet : [Fiware-security] Meeting in Paris Hallo Robert, here the filled slide for the meeting. Best regards Wolfgang -------------- next part -------------- An HTML attachment was scrubbed... URL: From cyril.dangerville at thalesgroup.com Sun Jun 9 14:39:08 2013 From: cyril.dangerville at thalesgroup.com (DANGERVILLE Cyril) Date: Sun, 9 Jun 2013 14:39:08 +0200 Subject: [Fiware-api-cross] IdM GE Common RESTful API proposal for getting/managing user attributes Message-ID: <16342_1370781550_51B4776E_16342_4429_1_DDCC8EDACD06614C9CE3DFEA2835890070C5DCA951@THSONEA01CMS10P.one.grp> 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 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 #< #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: > 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 > To: "Wolfgang.Steigerwald at telekom.de" >, "robert.seidl at nsn.com" > CC: "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: > <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> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.seidl at nsn.com Wed Jun 12 11:32:21 2013 From: robert.seidl at nsn.com (Seidl, Robert (NSN - DE/Munich)) Date: Wed, 12 Jun 2013 09:32:21 +0000 Subject: [Fiware-api-cross] IdM GE Common RESTful API proposal for getting/managing user attributes In-Reply-To: <16342_1370781550_51B4776E_16342_4429_1_DDCC8EDACD06614C9CE3DFEA2835890070C5DCA951@THSONEA01CMS10P.one.grp> References: <16342_1370781550_51B4776E_16342_4429_1_DDCC8EDACD06614C9CE3DFEA2835890070C5DCA951@THSONEA01CMS10P.one.grp> Message-ID: 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 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 #< #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: > 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 > To: "Wolfgang.Steigerwald at telekom.de" >, "robert.seidl at nsn.com" > CC: "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: > <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> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From cyril.dangerville at thalesgroup.com Wed Jun 12 17:26:27 2013 From: cyril.dangerville at thalesgroup.com (DANGERVILLE Cyril) Date: Wed, 12 Jun 2013 17:26:27 +0200 Subject: [Fiware-api-cross] Access Control GE Webinar - Next Friday 14 June 2013 Message-ID: <21962_1371050789_51B89325_21962_17770_1_DDCC8EDACD06614C9CE3DFEA2835890070C5E5FF1D@THSONEA01CMS10P.one.grp> FYI Webinar for Access Control GE is planned on Friday 14 June 2013, 17:00 CEST. Regards, Cyril -------------- next part -------------- An HTML attachment was scrubbed... URL: From cyril.dangerville at thalesgroup.com Mon Jun 17 10:43:15 2013 From: cyril.dangerville at thalesgroup.com (DANGERVILLE Cyril) Date: Mon, 17 Jun 2013 10:43:15 +0200 Subject: [Fiware-api-cross] IdM GE Common RESTful API proposal for getting/managing user attributes In-Reply-To: References: <16342_1370781550_51B4776E_16342_4429_1_DDCC8EDACD06614C9CE3DFEA2835890070C5DCA951@THSONEA01CMS10P.one.grp> Message-ID: <10443_1371458602_51BECC2A_10443_1997_1_DDCC8EDACD06614C9CE3DFEA2835890070C5EC7551@THSONEA01CMS10P.one.grp> Yes, fine with me ! De : Seidl, Robert (NSN - DE/Munich) [mailto:robert.seidl at nsn.com] Envoy? : mercredi 12 juin 2013 11:32 ? : DANGERVILLE Cyril Cc : Wolfgang.Steigerwald at telekom.de; fiware-api-cross at lists.fi-ware.eu Objet : RE: IdM GE Common RESTful API proposal for getting/managing user attributes 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 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 #< #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: > 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 > To: "Wolfgang.Steigerwald at telekom.de" >, "robert.seidl at nsn.com" > CC: "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: > <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> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From cyril.dangerville at thalesgroup.com Tue Jun 18 19:38:47 2013 From: cyril.dangerville at thalesgroup.com (DANGERVILLE Cyril) Date: Tue, 18 Jun 2013 19:38:47 +0200 Subject: [Fiware-api-cross] [FIWARE] Reminder: GCP Roadmap - OAuth client app authentication & client_id propagation References: <6733_1363347332_51430784_6733_15656_1_c9b02a2e-728f-481e-b271-d2ad9b8bd404@THSONEA01HUB01P.one.grp> <28056_1363617604_51472744_28056_15183_11_DDCC8EDACD06614C9CE3DFEA2835890070C3C26EE6@THSONEA01CMS10P.one.grp> <19883_1363687984_51483A30_19883_17288_2_DDCC8EDACD06614C9CE3DFEA2835890070C3C272F6@THSONEA01CMS10P.one.grp> <12455_1365081218_515D7C82_12455_2695_1_da1cdaae-9429-4638-afb9-e202fb513c05@THSONEA01HUB05P.one.grp> Message-ID: <32175_1371577133_51C09B2D_32175_3516_1_d094cd3d-436b-4730-8d58-1eb4fa3a9b14@THSONEA01HUB03P.one.grp> Hello, Following our discussion at the FIWARE plenary meeting for the Security Chapter on June 6th , and now that the rush of the review has passed, I would like to remind you of the following feature requests for DT's IdM GE (GCP): 1. OAuth client app authentication (using the client AppSecret as this is not used so far) to the OAuth Token endpoint in order to get an OAuth access token. See the mail thread below for more details. 2. A way to get the client app ID for which a given OAuth access token was generated (ID of the client that was granted access), either from the token itself or via some API. See the mail thread below as well. *Could you please check whether this is acceptable for you/DT in the technical roadmap of Release 3 or not?* Maybe it is already the case now... I think this can benefit to all users of the IdM and Access Control GE, as I am anticipating questions/Use Case requirements regarding feature 1, to achieve better compliance with the OAuth 2.0 standard and security overall; and for feature 2, regarding the ability to make access control based on various Client App attributes. Regards, Cyril Access Control GE owner De : DANGERVILLE Cyril Envoy? : vendredi 12 avril 2013 14:58 ? : 'Wolfgang.Steigerwald at telekom.de' Cc : Andreas.Wittwer at telekom.de; BISSON Pascal Objet : RE: [FIWARE] GCP OAuth API security - Require client app to authenticate to GCP with AppSecret Hello, Yes, I would much prefer to have a standard client authentication mechanism relying on the client credentials (client_id, client_secret). This would be more convincing to people/reviewers checking the compliance of the Access Control GE to OAuth 2.0 security considerations (see section 10.1 "Client Authentication" of OAuth 2.0 standard [1]) before they accept to use it. For now, this is not critical for the integration of the Thales Access control Asset with the IdM GE. What is more critical at least is simple client app identification (get the client_id info) based on the access token (in the token itself as extra attribute, or requesting the IdM GE with token id parameter to get the client_id), because it will be required by the Thales Asset to know WHO accesses what and use it in access control policies. Thanks. [1] http://tools.ietf.org/html/rfc6749#section-10.1 Regards, CD De : Wolfgang.Steigerwald at telekom.de [mailto:Wolfgang.Steigerwald at telekom.de] Envoy? : mercredi 10 avril 2013 17:15 ? : DANGERVILLE Cyril Cc : Andreas.Wittwer at telekom.de Objet : AW: [FIWARE] GCP OAuth API security - Require client app to authenticate to GCP with AppSecret Hello Cyril, the authentication of the client is currently not done by the ClientId and the ClientSecret. Currently verification is done by checking if the client has the right service in scope, is using the right redirect URI and the code is provided in a short timeframe. This was until now good enough for client authentication and that the flow is secure through the user authentication. If you think it is necessary validate also the clientsecret I have to check if I can get it in the GCP backlog. Best regards Wolfgang Von: Steigerwald, Wolfgang Gesendet: Dienstag, 9. April 2013 13:32 An: 'DANGERVILLE Cyril' Cc: Wittwer, Andreas Betreff: AW: [FIWARE] GCP OAuth API security - Require client app to authenticate to GCP with AppSecret Hello Cyril, Andreas and I are not sure about the answer to this question. Therefor I send it to a colleague, I came back to you as soon as possible. Best regards Wolfgang Von: DANGERVILLE Cyril [mailto:cyril.dangerville at thalesgroup.com] Gesendet: Donnerstag, 4. April 2013 15:09 An: Steigerwald, Wolfgang Cc: Wittwer, Andreas Betreff: [FIWARE] GCP OAuth API security - Require client app to authenticate to GCP with AppSecret Hello, I have a question regarding the security of the OAuth access token request to the GCP. When the client app does such a request, the client app does not authenticate (the client AppSecret configured in the GCP admin panel is not used) to get an access token: POST https://logint2.idm.toon.sul.t-online.de/gcp-web-api/oauth?grant_type=authorization_code&client_id=RbKaKyrKHB&code=2504572063178823&redirect_uri=https%3A%2F%2Fwww.nowhere.de According to the OAuth 2.0 standard [1], this is step (D) and it says "When making the request, the client authenticates with the authorization server". You can also see an example here [2] with Google where there is an extra parameter "client_secret" that must be sent. In the GCP, is there a way to require client authentication, by sending the AppSecret for instance, or is it some feature you've planned for a next release ? Regards, CD [1] http://tools.ietf.org/html/rfc6749#section-4.1 [2] https://developers.google.com/accounts/docs/OAuth2WebServer#handlingtheresponse -------------- next part -------------- An HTML attachment was scrubbed... URL: