From jhierro at tid.es Mon May 6 04:07:07 2013 From: jhierro at tid.es (Juanjo Hierro) Date: Mon, 06 May 2013 04:07:07 +0200 Subject: [Fiware-api-cross] Session about API Access Control on Monday May 13 afternoon Message-ID: <5187104B.8070804@tid.es> Dear colleagues, I would like to have a session on Monday May 13 afternoon (Part II of the weekly joint WPLs/WPAs follow-up confcalls, from 14:30 to 16:00) to push activities related to the API Access Control framework we agree to offer to FI-WARE application developers in Release 2 (attached, for your convenience, the slides we agreed upon with the final reference architecture represented in the last slide). Despite I may come later this week with more details, there are a number of points I would like to tackle during that session which I can anticipate at this point: * @NSN/DT: status regarding support of OAuth messages (steps 4, 6, 7, 11 and 12 in the last slide of the attached presentation illustrating the final reference architecture). Could you point me out where in the IdM GE Open Specifications can I find the specification of the REST API that comprises the operations supporting these steps ? If that REST API specification is a standard specification, it would be nice to see a link to it together with a statement about its support by the IdM GE. It may have passed unadvertised to me, but I couldn't find anything like that ... * @UPM: I would like to see an analysis of the APIs provided by the XACML PDP component (Access Control GE) to be provided by Thales: * APIs to be invoked by the Proxy component * APIs to be used by the FI-WARE OIL Portal, or application-specific portals, to configure access control policies to be enforced by the XACML PDP component (Access Control GE) by Thales * @UPM: status of the implementation of the Proxy component that may interact both with Keystone components from OpenStack and the XACML PDP component (Access Control GE) by Thales * @NSN/DT: status about implementation of APIs enabling creation/deletion/management of users and organization of users as well as the definition of attributes for both ... This would enable application providers or FI-WARE Instance Providers, among others, to define portals for management of application users ... (note that very much related to this, I raise a hot issue below) Please book the proposed slot in your agendas. If you can provide some input to the above questions in advance to the meeting, it would be rather nice. I take this opportunity to raise a number of hot issues I have detected while reviewing contents of the Security Chapter in the FI-WARE Architecture. It would be nice to see some clarifications on your side ASAP: * IdM GE API Open Specifications: Frankly speaking, I can't find any API specification associated to the FI-WARE IdM GE ... what you have there are the URLs of service endpoints linked to concrete instances of the IdM GE, provided by DT and NSN. This might be useful information to publish in the tab "instances" linked to entries in the FI-WARE Catalogue associated to the IdM GEis implemented by NSN and DT ... but why is this stuff published as part of the IdM GE Open Specifications ? I have found that a similar comment was raised by TID/UPM during the peer review but seems like it had been ignored ... If part of the IdM GE API Open Specifications matches a given standard then you should provide a link to the published specs together with comments regarding level of support of the referred spec (e.g., may be not all the operations in the standard API you make a link to are supported in your implementation). Besides, at one point you state: "Additional to the authentication and authorization interfaces the Identity Management GEs delivers a REST API for all functionalities regarding user and profile management" ... however I can't see that REST API specified anywhere ... Where is it ? Last but not least, I have read in one of the comments that some of the examples you provide were related to OAuth 1.0 rather than OAuth 2.0 ... could you confirm that you will support OAuth 2.0 ? * Access Control GE: I read the following as part of the Open Specs and it rather seems inadmissible to me: "The API operations and associated datatypes are fully described in the Access Control GE - Authorization Restful API (fiware.access_control_ge.authz.api.wadl.zip) package available in document folder Cross Topics > APIs access control, monitoring and accounting of project FI-WARE Private". Please, FI-WARE Open Specifications are public ! we cannot deliver something like this ! Best regards, -- Juanjo Hierro ------------- Product Development and Innovation (PDI) - Telefonica Digital website: www.tid.es email: jhierro at tid.es twitter: twitter.com/JuanjoHierro FI-WARE (European Future Internet Core Platform) Coordinator and Chief Architect 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 ________________________________ 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: FI-WARE Security 13-02-25.pptx Type: application/vnd.openxmlformats-officedocument.presentationml.presentation Size: 136175 bytes Desc: not available URL: From robert.seidl at nsn.com Wed May 8 11:55:24 2013 From: robert.seidl at nsn.com (Seidl, Robert (NSN - DE/Munich)) Date: Wed, 8 May 2013 09:55:24 +0000 Subject: [Fiware-api-cross] Session about API Access Control on Monday May 13 afternoon In-Reply-To: <5187104B.8070804@tid.es> References: <5187104B.8070804@tid.es> Message-ID: Hi Juanjo, please find our comments in the text. One more thing: Please forward us the telco and document sharing details for Monday. We don't have it. Greetings 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 Juanjo Hierro Sent: Monday, May 06, 2013 4:07 AM To: Fiware-api-cross at lists.fi-ware.eu Subject: [Fiware-api-cross] Session about API Access Control on Monday May 13 afternoon Dear colleagues, I would like to have a session on Monday May 13 afternoon (Part II of the weekly joint WPLs/WPAs follow-up confcalls, from 14:30 to 16:00) to push activities related to the API Access Control framework we agree to offer to FI-WARE application developers in Release 2 (attached, for your convenience, the slides we agreed upon with the final reference architecture represented in the last slide). Despite I may come later this week with more details, there are a number of points I would like to tackle during that session which I can anticipate at this point: * @NSN/DT: status regarding support of OAuth messages (steps 4, 6, 7, 11 and 12 in the last slide of the attached presentation illustrating the final reference architecture). ? Regarding the access control GE and related steps in the message flow we have to check with our technical experts, but our first impression is that it should work. ? We will come back to you. Could you point me out where in the IdM GE Open Specifications can I find the specification of the REST API that comprises the operations supporting these steps ? If that REST API specification is a standard specification, it would be nice to see a link to it together with a statement about its support by the IdM GE. It may have passed unadvertised to me, but I couldn't find anything like that ? In the specification of the IDM GE open specification you will find the standard interface description for SAML2.0, OAuth 2.0, OpenID and eID. ? In addition we provide to interested Use Case projects an example service for SAML2.0 in the case of the One-IDM and a specific document describing the REST api in the case of GCP. ? IN case of GCP we could provide the REST specification if we would know where we could upload it. Wolfgang will write a separate email to you. * @UPM: I would like to see an analysis of the APIs provided by the XACML PDP component (Access Control GE) to be provided by Thales: * APIs to be invoked by the Proxy component * APIs to be used by the FI-WARE OIL Portal, or application-specific portals, to configure access control policies to be enforced by the XACML PDP component (Access Control GE) by Thales * @UPM: status of the implementation of the Proxy component that may interact both with Keystone components from OpenStack and the XACML PDP component (Access Control GE) by Thales * @NSN/DT: status about implementation of APIs enabling creation/deletion/management of users and organization of users as well as the definition of attributes for both ... This would enable application providers or FI-WARE Instance Providers, among others, to define portals for management of application users ... (note that very much related to this, I raise a hot issue below) ? For GCP this is described in the REST api document (Wolfgang will send you an email). ? For One-IDM this has to be done by the admin of the system and can't be done by the user. Please book the proposed slot in your agendas. If you can provide some input to the above questions in advance to the meeting, it would be rather nice. I take this opportunity to raise a number of hot issues I have detected while reviewing contents of the Security Chapter in the FI-WARE Architecture. It would be nice to see some clarifications on your side ASAP: * IdM GE API Open Specifications: Frankly speaking, I can't find any API specification associated to the FI-WARE IdM GE ... what you have there are the URLs of service endpoints linked to concrete instances of the IdM GE, provided by DT and NSN. This might be useful information to publish in the tab "instances" linked to entries in the FI-WARE Catalogue associated to the IdM GEis implemented by NSN and DT ... but why is this stuff published as part of the IdM GE Open Specifications ? I have found that a similar comment was raised by TID/UPM during the peer review but seems like it had been ignored ... If part of the IdM GE API Open Specifications matches a given standard then you should provide a link to the published specs together with comments regarding level of support of the referred spec (e.g., may be not all the operations in the standard API you make a link to are supported in your implementation). Besides, at one point you state: "Additional to the authentication and authorization interfaces the Identity Management GEs delivers a REST API for all functionalities regarding user and profile management" ... however I can't see that REST API specified anywhere ... Where is it ? Last but not least, I have read in one of the comments that some of the examples you provide were related to OAuth 1.0 rather than OAuth 2.0 ... could you confirm that you will support OAuth 2.0 ? ? Please refer to the answer above. ? We have already adapted the description of OAuth1.0 to OAuth2.0. ? The two IDM GE are provided on request, when sending an email to the owners DT and NSN. There is no kind of self deployment for these GE. * Access Control GE: I read the following as part of the Open Specs and it rather seems inadmissible to me: "The API operations and associated datatypes are fully described in the Access Control GE - Authorization Restful API (fiware.access_control_ge.authz.api.wadl.zip) package available in document folder Cross Topics > APIs access control, monitoring and accounting of project FI-WARE Private". Please, FI-WARE Open Specifications are public ! we cannot deliver something like this ! Best regards, -- Juanjo Hierro ------------- Product Development and Innovation (PDI) - Telefonica Digital website: www.tid.es email: jhierro at tid.es twitter: twitter.com/JuanjoHierro FI-WARE (European Future Internet Core Platform) Coordinator and Chief Architect 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 ________________________________ 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: From jhierro at tid.es Fri May 10 11:28:00 2013 From: jhierro at tid.es (Juanjo Hierro) Date: Fri, 10 May 2013 11:28:00 +0200 Subject: [Fiware-api-cross] Session about API Access Control on Monday May 13 afternoon In-Reply-To: <5187104B.8070804@tid.es> References: <5187104B.8070804@tid.es> Message-ID: <518CBDA0.6030204@tid.es> Hi, I would like you to confirm your availability for this topic in the agenda of our joint WPLs/WPAs follow-up confcall on Monday May 13 afternoon. Feedback on the several questions would be also welcome. Cheers, -- Juanjo ------------- Product Development and Innovation (PDI) - Telefonica Digital website: www.tid.es email: jhierro at tid.es twitter: twitter.com/JuanjoHierro FI-WARE (European Future Internet Core Platform) Coordinator and Chief Architect 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 06/05/13 04:07, Juanjo Hierro wrote: Dear colleagues, I would like to have a session on Monday May 13 afternoon (Part II of the weekly joint WPLs/WPAs follow-up confcalls, from 14:30 to 16:00) to push activities related to the API Access Control framework we agree to offer to FI-WARE application developers in Release 2 (attached, for your convenience, the slides we agreed upon with the final reference architecture represented in the last slide). Despite I may come later this week with more details, there are a number of points I would like to tackle during that session which I can anticipate at this point: * @NSN/DT: status regarding support of OAuth messages (steps 4, 6, 7, 11 and 12 in the last slide of the attached presentation illustrating the final reference architecture). Could you point me out where in the IdM GE Open Specifications can I find the specification of the REST API that comprises the operations supporting these steps ? If that REST API specification is a standard specification, it would be nice to see a link to it together with a statement about its support by the IdM GE. It may have passed unadvertised to me, but I couldn't find anything like that ... * @UPM: I would like to see an analysis of the APIs provided by the XACML PDP component (Access Control GE) to be provided by Thales: * APIs to be invoked by the Proxy component * APIs to be used by the FI-WARE OIL Portal, or application-specific portals, to configure access control policies to be enforced by the XACML PDP component (Access Control GE) by Thales * @UPM: status of the implementation of the Proxy component that may interact both with Keystone components from OpenStack and the XACML PDP component (Access Control GE) by Thales * @NSN/DT: status about implementation of APIs enabling creation/deletion/management of users and organization of users as well as the definition of attributes for both ... This would enable application providers or FI-WARE Instance Providers, among others, to define portals for management of application users ... (note that very much related to this, I raise a hot issue below) Please book the proposed slot in your agendas. If you can provide some input to the above questions in advance to the meeting, it would be rather nice. I take this opportunity to raise a number of hot issues I have detected while reviewing contents of the Security Chapter in the FI-WARE Architecture. It would be nice to see some clarifications on your side ASAP: * IdM GE API Open Specifications: Frankly speaking, I can't find any API specification associated to the FI-WARE IdM GE ... what you have there are the URLs of service endpoints linked to concrete instances of the IdM GE, provided by DT and NSN. This might be useful information to publish in the tab "instances" linked to entries in the FI-WARE Catalogue associated to the IdM GEis implemented by NSN and DT ... but why is this stuff published as part of the IdM GE Open Specifications ? I have found that a similar comment was raised by TID/UPM during the peer review but seems like it had been ignored ... If part of the IdM GE API Open Specifications matches a given standard then you should provide a link to the published specs together with comments regarding level of support of the referred spec (e.g., may be not all the operations in the standard API you make a link to are supported in your implementation). Besides, at one point you state: "Additional to the authentication and authorization interfaces the Identity Management GEs delivers a REST API for all functionalities regarding user and profile management" ... however I can't see that REST API specified anywhere ... Where is it ? Last but not least, I have read in one of the comments that some of the examples you provide were related to OAuth 1.0 rather than OAuth 2.0 ... could you confirm that you will support OAuth 2.0 ? * Access Control GE: I read the following as part of the Open Specs and it rather seems inadmissible to me: "The API operations and associated datatypes are fully described in the Access Control GE - Authorization Restful API (fiware.access_control_ge.authz.api.wadl.zip) package available in document folder Cross Topics > APIs access control, monitoring and accounting of project FI-WARE Private". Please, FI-WARE Open Specifications are public ! we cannot deliver something like this ! Best regards, -- Juanjo Hierro ------------- Product Development and Innovation (PDI) - Telefonica Digital website: www.tid.es email: jhierro at tid.es twitter: twitter.com/JuanjoHierro FI-WARE (European Future Internet Core Platform) Coordinator and Chief Architect 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 ________________________________ 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: From fermin at tid.es Mon May 13 12:45:18 2013 From: fermin at tid.es (=?ISO-8859-1?Q?Ferm=EDn_Gal=E1n_M=E1rquez?=) Date: Mon, 13 May 2013 12:45:18 +0200 Subject: [Fiware-api-cross] Session about API Access Control on Monday May 13 afternoon In-Reply-To: <5187104B.8070804@tid.es> References: <5187104B.8070804@tid.es> Message-ID: <5190C43E.6030408@tid.es> Hi, I have an additional broad question related with API Access Control and Live Demo Application for all the involved partners (NSN/DT/UPM/Thales): Will the API Access Control functionality be ready to be included as part of the next iteration of Live Demo Application during next review (June 12-13)? That means of course that it has to be ready in advance to that date, considering the integration and testing times. In affirmative case, I need to know the contact point for this in order to define the utilization scenario in Live Demo Application. Thanks! Best regards, ------ Ferm?n El 06/05/2013 4:07, Juanjo Hierro escribi?: Dear colleagues, I would like to have a session on Monday May 13 afternoon (Part II of the weekly joint WPLs/WPAs follow-up confcalls, from 14:30 to 16:00) to push activities related to the API Access Control framework we agree to offer to FI-WARE application developers in Release 2 (attached, for your convenience, the slides we agreed upon with the final reference architecture represented in the last slide). Despite I may come later this week with more details, there are a number of points I would like to tackle during that session which I can anticipate at this point: * @NSN/DT: status regarding support of OAuth messages (steps 4, 6, 7, 11 and 12 in the last slide of the attached presentation illustrating the final reference architecture). Could you point me out where in the IdM GE Open Specifications can I find the specification of the REST API that comprises the operations supporting these steps ? If that REST API specification is a standard specification, it would be nice to see a link to it together with a statement about its support by the IdM GE. It may have passed unadvertised to me, but I couldn't find anything like that ... * @UPM: I would like to see an analysis of the APIs provided by the XACML PDP component (Access Control GE) to be provided by Thales: * APIs to be invoked by the Proxy component * APIs to be used by the FI-WARE OIL Portal, or application-specific portals, to configure access control policies to be enforced by the XACML PDP component (Access Control GE) by Thales * @UPM: status of the implementation of the Proxy component that may interact both with Keystone components from OpenStack and the XACML PDP component (Access Control GE) by Thales * @NSN/DT: status about implementation of APIs enabling creation/deletion/management of users and organization of users as well as the definition of attributes for both ... This would enable application providers or FI-WARE Instance Providers, among others, to define portals for management of application users ... (note that very much related to this, I raise a hot issue below) Please book the proposed slot in your agendas. If you can provide some input to the above questions in advance to the meeting, it would be rather nice. I take this opportunity to raise a number of hot issues I have detected while reviewing contents of the Security Chapter in the FI-WARE Architecture. It would be nice to see some clarifications on your side ASAP: * IdM GE API Open Specifications: Frankly speaking, I can't find any API specification associated to the FI-WARE IdM GE ... what you have there are the URLs of service endpoints linked to concrete instances of the IdM GE, provided by DT and NSN. This might be useful information to publish in the tab "instances" linked to entries in the FI-WARE Catalogue associated to the IdM GEis implemented by NSN and DT ... but why is this stuff published as part of the IdM GE Open Specifications ? I have found that a similar comment was raised by TID/UPM during the peer review but seems like it had been ignored ... If part of the IdM GE API Open Specifications matches a given standard then you should provide a link to the published specs together with comments regarding level of support of the referred spec (e.g., may be not all the operations in the standard API you make a link to are supported in your implementation). Besides, at one point you state: "Additional to the authentication and authorization interfaces the Identity Management GEs delivers a REST API for all functionalities regarding user and profile management" ... however I can't see that REST API specified anywhere ... Where is it ? Last but not least, I have read in one of the comments that some of the examples you provide were related to OAuth 1.0 rather than OAuth 2.0 ... could you confirm that you will support OAuth 2.0 ? * Access Control GE: I read the following as part of the Open Specs and it rather seems inadmissible to me: "The API operations and associated datatypes are fully described in the Access Control GE - Authorization Restful API (fiware.access_control_ge.authz.api.wadl.zip) package available in document folder Cross Topics > APIs access control, monitoring and accounting of project FI-WARE Private". Please, FI-WARE Open Specifications are public ! we cannot deliver something like this ! Best regards, -- Juanjo Hierro ------------- Product Development and Innovation (PDI) - Telefonica Digital website: www.tid.es email: jhierro at tid.es twitter: twitter.com/JuanjoHierro FI-WARE (European Future Internet Core Platform) Coordinator and Chief Architect 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 ________________________________ 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: From cyril.dangerville at thalesgroup.com Mon May 13 12:47:07 2013 From: cyril.dangerville at thalesgroup.com (DANGERVILLE Cyril) Date: Mon, 13 May 2013 12:47:07 +0200 Subject: [Fiware-api-cross] Session about API Access Control on Monday May 13 afternoon In-Reply-To: <5187104B.8070804@tid.es> References: <5187104B.8070804@tid.es> Message-ID: <21058_1368442030_5190C4AE_21058_8258_1_DDCC8EDACD06614C9CE3DFEA2835890070C43B9B3D@THSONEA01CMS10P.one.grp> Hello Juanjo, To address your comment on Access Control GE below, the incriminated ZIP package is now *publicly* available. I have updated the wiki page that you quoted below, to point to that new public link instead. Kind regards, CD --- Cyril Dangerville, CISSP Thales Services ThereSIS Innovation lab, ICT Security Unit Thales Research & Technology 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 : fiware-api-cross-bounces at lists.fi-ware.eu [mailto:fiware-api-cross-bounces at lists.fi-ware.eu] De la part de Juanjo Hierro Envoy? : lundi 6 mai 2013 04:07 ? : Fiware-api-cross at lists.fi-ware.eu Objet : [Fiware-api-cross] Session about API Access Control on Monday May 13 afternoon [...] I take this opportunity to raise a number of hot issues I have detected while reviewing contents of the Security Chapter in the FI-WARE Architecture. It would be nice to see some clarifications on your side ASAP: * IdM GE API Open Specifications: Frankly speaking, I can't find any API specification associated to the FI-WARE IdM GE ... what you have there are the URLs of service endpoints linked to concrete instances of the IdM GE, provided by DT and NSN. This might be useful information to publish in the tab "instances" linked to entries in the FI-WARE Catalogue associated to the IdM GEis implemented by NSN and DT ... but why is this stuff published as part of the IdM GE Open Specifications ? I have found that a similar comment was raised by TID/UPM during the peer review but seems like it had been ignored ... If part of the IdM GE API Open Specifications matches a given standard then you should provide a link to the published specs together with comments regarding level of support of the referred spec (e.g., may be not all the operations in the standard API you make a link to are supported in your implementation). Besides, at one point you state: "Additional to the authentication and authorization interfaces the Identity Management GEs delivers a REST API for all functionalities regarding user and profile management" ... however I can't see that REST API specified anywhere ... Where is it ? Last but not least, I have read in one of the comments that some of the examples you provide were related to OAuth 1.0 rather than OAuth 2.0 ... could you confirm that you will support OAuth 2.0 ? * Access Control GE: I read the following as part of the Open Specs and it rather seems inadmissible to me: "The API operations and associated datatypes are fully described in the Access Control GE - Authorization Restful API (fiware.access_control_ge.authz.api.wadl.zip) package available in document folder Cross Topics > APIs access control, monitoring and accounting of project FI-WARE Private". Please, FI-WARE Open Specifications are public ! we cannot deliver something like this ! Best regards, -- Juanjo Hierro ------------- Product Development and Innovation (PDI) - Telefonica Digital website: www.tid.es email: jhierro at tid.es twitter: twitter.com/JuanjoHierro FI-WARE (European Future Internet Core Platform) Coordinator and Chief Architect 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 ________________________________ 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: From cyril.dangerville at thalesgroup.com Mon May 13 14:27:05 2013 From: cyril.dangerville at thalesgroup.com (DANGERVILLE Cyril) Date: Mon, 13 May 2013 14:27:05 +0200 Subject: [Fiware-api-cross] Session about API Access Control on Monday May 13 afternoon In-Reply-To: <5190C43E.6030408@tid.es> References: <5187104B.8070804@tid.es> <5190C43E.6030408@tid.es> Message-ID: <25680_1368448027_5190DC1B_25680_409_1_DDCC8EDACD06614C9CE3DFEA2835890070C43B9C0C@THSONEA01CMS10P.one.grp> Hello, I am one of the contact points; and yes, there is a first release of the Access Control GE that enables API access Control (combining Identity Management GE and XACML asset), which can be improved until June, of course. New features are already planned. Yet, if we have to define a use case scenario for the Live Demo, we have to do it quite in advance to make sure all the requirements are *actually* met by the current status of the GE, which is far from obvious, since there is a great range of possibilities in that domain. We also have to make sure we have time to integrate the GE with the Demo Application in the time frame, depending on the complexity of the application. Regards, CD --- Cyril Dangerville, CISSP Thales Services ThereSIS Innovation lab, ICT Security Unit De : fiware-api-cross-bounces at lists.fi-ware.eu [mailto:fiware-api-cross-bounces at lists.fi-ware.eu] De la part de Ferm?n Gal?n M?rquez Envoy? : lundi 13 mai 2013 12:45 ? : fiware-api-cross at lists.fi-ware.eu Objet : Re: [Fiware-api-cross] Session about API Access Control on Monday May 13 afternoon Hi, I have an additional broad question related with API Access Control and Live Demo Application for all the involved partners (NSN/DT/UPM/Thales): Will the API Access Control functionality be ready to be included as part of the next iteration of Live Demo Application during next review (June 12-13)? That means of course that it has to be ready in advance to that date, considering the integration and testing times. In affirmative case, I need to know the contact point for this in order to define the utilization scenario in Live Demo Application. Thanks! Best regards, ------ Ferm?n El 06/05/2013 4:07, Juanjo Hierro escribi?: Dear colleagues, I would like to have a session on Monday May 13 afternoon (Part II of the weekly joint WPLs/WPAs follow-up confcalls, from 14:30 to 16:00) to push activities related to the API Access Control framework we agree to offer to FI-WARE application developers in Release 2 (attached, for your convenience, the slides we agreed upon with the final reference architecture represented in the last slide). Despite I may come later this week with more details, there are a number of points I would like to tackle during that session which I can anticipate at this point: * @NSN/DT: status regarding support of OAuth messages (steps 4, 6, 7, 11 and 12 in the last slide of the attached presentation illustrating the final reference architecture). Could you point me out where in the IdM GE Open Specifications can I find the specification of the REST API that comprises the operations supporting these steps ? If that REST API specification is a standard specification, it would be nice to see a link to it together with a statement about its support by the IdM GE. It may have passed unadvertised to me, but I couldn't find anything like that ... * @UPM: I would like to see an analysis of the APIs provided by the XACML PDP component (Access Control GE) to be provided by Thales: * APIs to be invoked by the Proxy component * APIs to be used by the FI-WARE OIL Portal, or application-specific portals, to configure access control policies to be enforced by the XACML PDP component (Access Control GE) by Thales * @UPM: status of the implementation of the Proxy component that may interact both with Keystone components from OpenStack and the XACML PDP component (Access Control GE) by Thales * @NSN/DT: status about implementation of APIs enabling creation/deletion/management of users and organization of users as well as the definition of attributes for both ... This would enable application providers or FI-WARE Instance Providers, among others, to define portals for management of application users ... (note that very much related to this, I raise a hot issue below) Please book the proposed slot in your agendas. If you can provide some input to the above questions in advance to the meeting, it would be rather nice. I take this opportunity to raise a number of hot issues I have detected while reviewing contents of the Security Chapter in the FI-WARE Architecture. It would be nice to see some clarifications on your side ASAP: * IdM GE API Open Specifications: Frankly speaking, I can't find any API specification associated to the FI-WARE IdM GE ... what you have there are the URLs of service endpoints linked to concrete instances of the IdM GE, provided by DT and NSN. This might be useful information to publish in the tab "instances" linked to entries in the FI-WARE Catalogue associated to the IdM GEis implemented by NSN and DT ... but why is this stuff published as part of the IdM GE Open Specifications ? I have found that a similar comment was raised by TID/UPM during the peer review but seems like it had been ignored ... If part of the IdM GE API Open Specifications matches a given standard then you should provide a link to the published specs together with comments regarding level of support of the referred spec (e.g., may be not all the operations in the standard API you make a link to are supported in your implementation). Besides, at one point you state: "Additional to the authentication and authorization interfaces the Identity Management GEs delivers a REST API for all functionalities regarding user and profile management" ... however I can't see that REST API specified anywhere ... Where is it ? Last but not least, I have read in one of the comments that some of the examples you provide were related to OAuth 1.0 rather than OAuth 2.0 ... could you confirm that you will support OAuth 2.0 ? * Access Control GE: I read the following as part of the Open Specs and it rather seems inadmissible to me: "The API operations and associated datatypes are fully described in the Access Control GE - Authorization Restful API (fiware.access_control_ge.authz.api.wadl.zip) package available in document folder Cross Topics > APIs access control, monitoring and accounting of project FI-WARE Private". Please, FI-WARE Open Specifications are public ! we cannot deliver something like this ! Best regards, -- Juanjo Hierro ------------- Product Development and Innovation (PDI) - Telefonica Digital website: www.tid.es email: jhierro at tid.es twitter: twitter.com/JuanjoHierro FI-WARE (European Future Internet Core Platform) Coordinator and Chief Architect 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 ________________________________ 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: From fermin at tid.es Thu May 16 13:20:42 2013 From: fermin at tid.es (=?ISO-8859-1?Q?Ferm=EDn_Gal=E1n_M=E1rquez?=) Date: Thu, 16 May 2013 13:20:42 +0200 Subject: [Fiware-api-cross] Session about API Access Control on Monday May 13 afternoon In-Reply-To: <25680_1368448027_5190DC1B_25680_409_1_DDCC8EDACD06614C9CE3DFEA2835890070C43B9C0C@THSONEA01CMS10P.one.grp> References: <5187104B.8070804@tid.es> <5190C43E.6030408@tid.es> <25680_1368448027_5190DC1B_25680_409_1_DDCC8EDACD06614C9CE3DFEA2835890070C43B9C0C@THSONEA01CMS10P.one.grp> Message-ID: <5194C10A.3010809@tid.es> Dear Cyril, Thank you for commitment. Currently we are working in integrating the different GEs that take part in the LiveDemo (Wirecloud, ContextBroker, CEP and Backend Device Management). I think that the best strategy (considering focus and limited bandwidth in the Live Demo team) is that once the basic integration is ok, then analyze how to apply API access control and involve the different GEs that are needed for that. If this moment happens enough time in advance regarding project review date, then we will show API access control in the review. Otherwise, we could defer it to a next execution of Live Demo. Best regards, ------ Ferm?n El 13/05/2013 14:27, DANGERVILLE Cyril escribi?: Hello, I am one of the contact points; and yes, there is a first release of the Access Control GE that enables API access Control (combining Identity Management GE and XACML asset), which can be improved until June, of course. New features are already planned. Yet, if we have to define a use case scenario for the Live Demo, we have to do it quite in advance to make sure all the requirements are *actually* met by the current status of the GE, which is far from obvious, since there is a great range of possibilities in that domain. We also have to make sure we have time to integrate the GE with the Demo Application in the time frame, depending on the complexity of the application. Regards, CD --- Cyril Dangerville, CISSP Thales Services ThereSIS Innovation lab, ICT Security Unit De : fiware-api-cross-bounces at lists.fi-ware.eu [mailto:fiware-api-cross-bounces at lists.fi-ware.eu] De la part de Ferm?n Gal?n M?rquez Envoy? : lundi 13 mai 2013 12:45 ? : fiware-api-cross at lists.fi-ware.eu Objet : Re: [Fiware-api-cross] Session about API Access Control on Monday May 13 afternoon Hi, I have an additional broad question related with API Access Control and Live Demo Application for all the involved partners (NSN/DT/UPM/Thales): Will the API Access Control functionality be ready to be included as part of the next iteration of Live Demo Application during next review (June 12-13)? That means of course that it has to be ready in advance to that date, considering the integration and testing times. In affirmative case, I need to know the contact point for this in order to define the utilization scenario in Live Demo Application. Thanks! Best regards, ------ Ferm?n El 06/05/2013 4:07, Juanjo Hierro escribi?: Dear colleagues, I would like to have a session on Monday May 13 afternoon (Part II of the weekly joint WPLs/WPAs follow-up confcalls, from 14:30 to 16:00) to push activities related to the API Access Control framework we agree to offer to FI-WARE application developers in Release 2 (attached, for your convenience, the slides we agreed upon with the final reference architecture represented in the last slide). Despite I may come later this week with more details, there are a number of points I would like to tackle during that session which I can anticipate at this point: * @NSN/DT: status regarding support of OAuth messages (steps 4, 6, 7, 11 and 12 in the last slide of the attached presentation illustrating the final reference architecture). Could you point me out where in the IdM GE Open Specifications can I find the specification of the REST API that comprises the operations supporting these steps ? If that REST API specification is a standard specification, it would be nice to see a link to it together with a statement about its support by the IdM GE. It may have passed unadvertised to me, but I couldn't find anything like that ... * @UPM: I would like to see an analysis of the APIs provided by the XACML PDP component (Access Control GE) to be provided by Thales: * APIs to be invoked by the Proxy component * APIs to be used by the FI-WARE OIL Portal, or application-specific portals, to configure access control policies to be enforced by the XACML PDP component (Access Control GE) by Thales * @UPM: status of the implementation of the Proxy component that may interact both with Keystone components from OpenStack and the XACML PDP component (Access Control GE) by Thales * @NSN/DT: status about implementation of APIs enabling creation/deletion/management of users and organization of users as well as the definition of attributes for both ... This would enable application providers or FI-WARE Instance Providers, among others, to define portals for management of application users ... (note that very much related to this, I raise a hot issue below) Please book the proposed slot in your agendas. If you can provide some input to the above questions in advance to the meeting, it would be rather nice. I take this opportunity to raise a number of hot issues I have detected while reviewing contents of the Security Chapter in the FI-WARE Architecture. It would be nice to see some clarifications on your side ASAP: * IdM GE API Open Specifications: Frankly speaking, I can't find any API specification associated to the FI-WARE IdM GE ... what you have there are the URLs of service endpoints linked to concrete instances of the IdM GE, provided by DT and NSN. This might be useful information to publish in the tab "instances" linked to entries in the FI-WARE Catalogue associated to the IdM GEis implemented by NSN and DT ... but why is this stuff published as part of the IdM GE Open Specifications ? I have found that a similar comment was raised by TID/UPM during the peer review but seems like it had been ignored ... If part of the IdM GE API Open Specifications matches a given standard then you should provide a link to the published specs together with comments regarding level of support of the referred spec (e.g., may be not all the operations in the standard API you make a link to are supported in your implementation). Besides, at one point you state: "Additional to the authentication and authorization interfaces the Identity Management GEs delivers a REST API for all functionalities regarding user and profile management" ... however I can't see that REST API specified anywhere ... Where is it ? Last but not least, I have read in one of the comments that some of the examples you provide were related to OAuth 1.0 rather than OAuth 2.0 ... could you confirm that you will support OAuth 2.0 ? * Access Control GE: I read the following as part of the Open Specs and it rather seems inadmissible to me: "The API operations and associated datatypes are fully described in the Access Control GE - Authorization Restful API (fiware.access_control_ge.authz.api.wadl.zip) package available in document folder Cross Topics > APIs access control, monitoring and accounting of project FI-WARE Private". Please, FI-WARE Open Specifications are public ! we cannot deliver something like this ! Best regards, -- Juanjo Hierro ------------- Product Development and Innovation (PDI) - Telefonica Digital website: www.tid.es email: jhierro at tid.es twitter: twitter.com/JuanjoHierro FI-WARE (European Future Internet Core Platform) Coordinator and Chief Architect 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 ________________________________ 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: From jhierro at tid.es Sun May 19 23:48:33 2013 From: jhierro at tid.es (Juanjo Hierro) Date: Sun, 19 May 2013 23:48:33 +0200 Subject: [Fiware-api-cross] Joint WPLs/WPAs confcalls tomorrow Message-ID: <519948B1.3030604@tid.es> Hi all, Tomorrow I have been invited to a lunch with several representatives of the Spanish Ministry of Industry and Economy as well as Peter Fatelning and other relevant public authorities that will attend a rather relevant event on the FI-PPP here in Spain. Therefore, I'm afraid that I have to cancell the second part (afternoon session) of our joint WPLs/WPAs confcall. The topic we planned to address (follow-up of our discussion on the OAuth2.0-based framework for Access Control to APIs) will be postponed for May 27th. The morning session remains and will be chaired by Miguel. I take advantage of this email to tell you that I plan to send a number of important messages along tomorrow. Please stay tunned because they will require that you take some actions. Cheers, -- Juanjo ------------- Product Development and Innovation (PDI) - Telefonica Digital website: www.tid.es email: jhierro at tid.es twitter: twitter.com/JuanjoHierro FI-WARE (European Future Internet Core Platform) Coordinator and Chief Architect 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 ________________________________ 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 From jhierro at tid.es Tue May 21 07:30:47 2013 From: jhierro at tid.es (Juanjo Hierro) Date: Tue, 21 May 2013 07:30:47 +0200 Subject: [Fiware-api-cross] URGENT Action points derived from architecture session on OAuth 2.0-based Access Control framework in FI-WARE Message-ID: <519B0687.60403@tid.es> Hi all, This mail is a reminder of the several APs identified during our architect session on Monday 13th about the OAuth 2.0-based Access Control framework in FI-WARE. The first point had to do with making the GCP IdM GEi API documentation available to all partners. You can now download the GCP IdM GEi API documentation from the following link at the FI-WARE project. Note that access to this link is private, so you will have to login in your FusionForge account (and be registered as member of the FI-WARE project): https://forge.fi-ware.eu/docman/view.php/7/2369/GCP+API+documentation_v0-2.pdf I have also attached to this email an updated version of the presentation that describes the architecture we are aiming to implement. As a follow-up of the technical session we had on Monday May 13th, I would like to remind the following action points: * @UPM to carry out a revision of the RESTful API specification provided in the referred GCP documentation in order to determine if it will allow them to finish developments under way regarding a FI-WARE OIL portal for management of user accounts and user attributes. I remind to UPM that they should also rely on the available APIs from the Access Control GE to deal with definition of roles and access policies from the same portal. * @UPM and @DT: UPM to provide detailed links to the places in the standard OAuth specs where they believe that the complete OAuth 2.0 RESTFul API to be supported by the IdM GE are specified. DT to respond to UPM so that the whole issue about existence of a complete standard RESTful API is clarified. Don't hesitate to carry out this discussion within the fiware-api-cross mailing list so that we can all follow-up the discussions * @Thales to also carry out a revision of the GCP same documentation and design a proposal to present in our next follow-up confcall about how to manage updates of some attributes of users which may imply rejection of some request tokens (check last slide in the attached presentation) * @UPM to confirm whether all the information is available for them to finalize development of the Proxy * @NSN to confirm whether they plan to support a RESTful API in compliance with the GCP RESTful specification. (note: NSN couldn't attend the confcall on May 13th but this issue was raised: there should be a single IdM GE RESTful API specification so either NSN is happy to implement the one provided by DT or both have to agree on one they will both support) You all are called to attend afternoon session during the next joint WPLs/WPAs follow-up confcall (14:30 to 16:00) on May 27th where we will have the opportunity to follow-up all the above APs (we will start the session addressing these points so that you don't need to stay the whole session if we finish earlier, but please book the whole slot in your agendas). Cheers, -- Juanjo ------------- Product Development and Innovation (PDI) - Telefonica Digital website: www.tid.es email: jhierro at tid.es twitter: twitter.com/JuanjoHierro FI-WARE (European Future Internet Core Platform) Coordinator and Chief Architect 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 ________________________________ 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: FI-WARE Security 13-05-14.pptx Type: application/vnd.openxmlformats-officedocument.presentationml.presentation Size: 187888 bytes Desc: not available URL: From atapiador at dit.upm.es Tue May 21 13:31:08 2013 From: atapiador at dit.upm.es (Antonio Tapiador del Dujo) Date: Tue, 21 May 2013 13:31:08 +0200 Subject: [Fiware-api-cross] OAuth 2.0 RESTful API Message-ID: <519B5AFC.7070302@dit.upm.es> Dear all, The main document where the OAuth 2.0 standard is described is RFC 6749: http://tools.ietf.org/html/rfc6749 The interactions are principally described in section 4.0. They include HTTP verbs, URLs and parameters. For instance, the authorization request can be found at http://tools.ietf.org/html/rfc6749#section-4.1.1 and it includes an example of RESTful request: GET /authorize?response_type=code&client_id=s6BhdRkqt3&state=xyz &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1 Host: server.example.com Kind regards. From jcervino at dit.upm.es Tue May 21 18:49:38 2013 From: jcervino at dit.upm.es (=?ISO-8859-1?Q?javier_cervi=F1o?=) Date: Tue, 21 May 2013 18:49:38 +0200 Subject: [Fiware-api-cross] Attributes and response needed by the Proxy Message-ID: Dear all, For the development of the proxy we need a set of attributes that have to be returned by the PDP in the request for token validation. These attributes should be stored by the IdM and be returned by the PDP, and they will be forwarded to the GEs. Here I send you an example of response from the Proxy to the GEs with these attributes: { "access":{ "token":{ "expires":"2012-02-05T00:00:00", "id":"887665443383838", "tenant":{ "id":"1", "name":"customer-x" } }, "user":{ "name":"joeuser", "tenantName":"customer-x", "id":"1", "roles":[ { "serviceId":"1", "id":"3", "name":"Member" } ], "tenantId":"1" } }} Of course, this information should be provided also by the PDP but in a format compatible with the PDP API. These attributes include information about the auth token (expiration date, id, and organization to which it is related), the user (name and id), the organization (tenant) in which the user is authenticated, and the roles the user plays within the organization. At UPM we believe that user, organization and roles can be attributes that may be previously stored in the IdM, and that they can be returned during the auth token request between the Proxy and the PDP. The question is whether you also believe these attributes can be defined at the IdM and be returned by the PDP and why. I would also like to see an example of PDP response where we could see these attributes. Thanks! Best regards, Javier Cervi?o. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhierro at tid.es Wed May 22 00:48:29 2013 From: jhierro at tid.es (Juanjo Hierro) Date: Wed, 22 May 2013 00:48:29 +0200 Subject: [Fiware-api-cross] OAuth 2.0 RESTful API In-Reply-To: <519B5AFC.7070302@dit.upm.es> References: <519B5AFC.7070302@dit.upm.es> Message-ID: <519BF9BD.9040207@tid.es> What is DT's position/comments to Antonio's input ? Thanks, -- Juanjo On 21/05/13 13:31, Antonio Tapiador del Dujo wrote: > Dear all, > > The main document where the OAuth 2.0 standard is described is RFC 6749: > > http://tools.ietf.org/html/rfc6749 > > The interactions are principally described in section 4.0. They > include HTTP verbs, URLs and parameters. For instance, the > authorization request can be found at > http://tools.ietf.org/html/rfc6749#section-4.1.1 and it includes an > example of RESTful request: > > GET /authorize?response_type=code&client_id=s6BhdRkqt3&state=xyz > &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1 > Host: server.example.com > > > Kind regards. > _______________________________________________ > Fiware-api-cross mailing list > Fiware-api-cross at lists.fi-ware.eu > https://lists.fi-ware.eu/listinfo/fiware-api-cross > ________________________________ 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 From cyril.dangerville at thalesgroup.com Wed May 22 16:03:07 2013 From: cyril.dangerville at thalesgroup.com (DANGERVILLE Cyril) Date: Wed, 22 May 2013 16:03:07 +0200 Subject: [Fiware-api-cross] Attributes and response needed by the Proxy In-Reply-To: References: Message-ID: <1474_1369231394_519CD022_1474_2644_1_DDCC8EDACD06614C9CE3DFEA2835890070C44D588A@THSONEA01CMS10P.one.grp> Hello, This seems OK to me from the PDP side. With the following clarifications for each attribute, and answer to your question: 1. *OAuth token expiration date*. Retrieved from the standard "exp" claim of the JSON Web token (JWT) that is used as the OAuth token, and that your proxy is required to send to the PDP: http://self-issued.info/docs/draft-ietf-oauth-json-web-token.html#expDef Please note that the date format for that "exp" (=IntDate= number of seconds from 1970-01-01T0:0:0Z UTC until the specified UTC date/time) is different from the date format in the Keystone "token" element you gave as an example. Therefore, *some conversion is required*. I would rather NOT do such custom conversion in the PDP, to keep the GE as generic as possible. 2. *OAuth token ID*. Retrieved from the standard "jti" claim of the OAuth token (JWT): http://self-issued.info/docs/draft-ietf-oauth-json-web-token.html#jtiDef. 3. *User id*: User's GCPID, as registered in the GCP (IdM GE), retrieved from the OAuth token (JWT) claim "http://gcp.telekom.de/axschema/gcpid". 4. *User name*: you can define this attribute in the GCP or you can use a default one defined for all GCP users, such as the email, it's up to you. Then it can be retrieved by the PDP from the Oauth token (JWT). 5. *User organization/tenant*: I see in your Keystone example that you have a *tenantName and tenantId. Do you need both actually?* In any case, you have to define a custom attribute in the IdM GE for each, and for the attribute value, you can reuse the ${MANDANT_ID} (resp. ${MANDANT_NAME}) natively defined in the GCP for tenantId (resp. tenantName). The PDP will get it from the Oauth token. I have not tried ${MANDANT_NAME} in my tests and I am unable to test at the moment (the GCP site is on maintenance :( ), so I cannot guarantee this work. You may ask the IdM GE owner (Wolfgang). The alternative is always to set the literal value yourself. 6. *User role*: you can define this attribute in the GCP. In this case, as I recall from a previous conf call, you expressed the possibility that this attribute may be changed (multiple times?) during the lifetime of the OAuth token. Therefore, getting it from the OAuth token is not enough. So, for that attribute, the PDP will request the GCP API to get the new value, for each of your proxy's XACML request where the matched policy requires that attribute. You can't fail to notice that for all attributes, except the user role, you can get them in your proxy from the Oauth token, instead of having the PDP return it, just a suggestion. In the PDP XACML response, attributes will be returned in s of s (see XACML 2.0 spec). Example : Permit Member somevalue Regards, CD De : fiware-api-cross-bounces at lists.fi-ware.eu [mailto:fiware-api-cross-bounces at lists.fi-ware.eu] De la part de javier cervi?o Envoy? : mardi 21 mai 2013 18:50 ? : Fiware-api-cross at lists.fi-ware.eu Objet : [Fiware-api-cross] Attributes and response needed by the Proxy Dear all, For the development of the proxy we need a set of attributes that have to be returned by the PDP in the request for token validation. These attributes should be stored by the IdM and be returned by the PDP, and they will be forwarded to the GEs. Here I send you an example of response from the Proxy to the GEs with these attributes: { "access":{ "token":{ "expires":"2012-02-05T00:00:00", "id":"887665443383838", "tenant":{ "id":"1", "name":"customer-x" } }, "user":{ "name":"joeuser", "tenantName":"customer-x", "id":"1", "roles":[ { "serviceId":"1", "id":"3", "name":"Member" } ], "tenantId":"1" } } } Of course, this information should be provided also by the PDP but in a format compatible with the PDP API. These attributes include information about the auth token (expiration date, id, and organization to which it is related), the user (name and id), the organization (tenant) in which the user is authenticated, and the roles the user plays within the organization. At UPM we believe that user, organization and roles can be attributes that may be previously stored in the IdM, and that they can be returned during the auth token request between the Proxy and the PDP. The question is whether you also believe these attributes can be defined at the IdM and be returned by the PDP and why. I would also like to see an example of PDP response where we could see these attributes. Thanks! Best regards, Javier Cervi?o. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Wolfgang.Steigerwald at telekom.de Thu May 23 14:26:30 2013 From: Wolfgang.Steigerwald at telekom.de (Wolfgang.Steigerwald at telekom.de) Date: Thu, 23 May 2013 14:26:30 +0200 Subject: [Fiware-api-cross] OAuth 2.0 RESTful API In-Reply-To: <519BF9BD.9040207@tid.es> References: <519B5AFC.7070302@dit.upm.es> <519BF9BD.9040207@tid.es> Message-ID: Hello Juanjo, the equivalent call in our API is GET /oauth?response_type=code&client_id=CLIENT_ID&scope=DIENST_ID& state=STATE&redirect_uri=REDIRECT_URI You see we just use additional an optional and a recommended attribute. The only difference is that in the example they write "/ authorize" we "/oauth" Best regards Wolfgang -----Urspr?ngliche Nachricht----- Von: fiware-api-cross-bounces at lists.fi-ware.eu [mailto:fiware-api-cross-bounces at lists.fi-ware.eu] Im Auftrag von Juanjo Hierro Gesendet: Mittwoch, 22. Mai 2013 00:48 An: fiware-api-cross at lists.fi-ware.eu Betreff: Re: [Fiware-api-cross] OAuth 2.0 RESTful API What is DT's position/comments to Antonio's input ? Thanks, -- Juanjo On 21/05/13 13:31, Antonio Tapiador del Dujo wrote: > Dear all, > > The main document where the OAuth 2.0 standard is described is RFC 6749: > > http://tools.ietf.org/html/rfc6749 > > The interactions are principally described in section 4.0. They > include HTTP verbs, URLs and parameters. For instance, the > authorization request can be found at > http://tools.ietf.org/html/rfc6749#section-4.1.1 and it includes an > example of RESTful request: > > GET /authorize?response_type=code&client_id=s6BhdRkqt3&state=xyz > &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1 > Host: server.example.com > > > Kind regards. > _______________________________________________ > Fiware-api-cross mailing list > Fiware-api-cross at lists.fi-ware.eu > https://lists.fi-ware.eu/listinfo/fiware-api-cross > ________________________________ 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 From jhierro at tid.es Mon May 27 13:35:40 2013 From: jhierro at tid.es (Juanjo Hierro) Date: Mon, 27 May 2013 13:35:40 +0200 Subject: [Fiware-api-cross] Cancelled: afternoon sesion of joint WPLs/WPAs follow-up confcall dealing with Access Control and OAuth framework and other stuff Message-ID: <51A3450C.3070809@tid.es> Hi, We agreed to cancel the afternoon sesion of joint WPLs/WPAs follow-up confcall dealing with Access Control and OAuth framework and other stuff ... but I just wanted to send this email so everyone is aware, even though not attending the morning session. I'm double-checking with the Cloud-UPM team whether they are available for tomorrow 14:30. Cheers, -- Juanjo ------------- Product Development and Innovation (PDI) - Telefonica Digital website: www.tid.es email: jhierro at tid.es twitter: twitter.com/JuanjoHierro FI-WARE (European Future Internet Core Platform) Coordinator and Chief Architect 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 ________________________________ 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 From atapiador at dit.upm.es Tue May 28 10:27:25 2013 From: atapiador at dit.upm.es (Antonio Tapiador del Dujo) Date: Tue, 28 May 2013 10:27:25 +0200 Subject: [Fiware-api-cross] OAuth 2.0 RESTful API In-Reply-To: References: <519B5AFC.7070302@dit.upm.es> <519BF9BD.9040207@tid.es> Message-ID: <51A46A6D.8030707@dit.upm.es> This is compliant with OAuth2 specification. It does describes the HTTP verbs and parameters but does not enforce the URL paths that must be used. El 23/05/13 14:26, Wolfgang.Steigerwald at telekom.de escribi?: > Hello Juanjo, > > the equivalent call in our API is > GET /oauth?response_type=code&client_id=CLIENT_ID&scope=DIENST_ID& > state=STATE&redirect_uri=REDIRECT_URI > You see we just use additional an optional and a recommended attribute. The only difference is that in the example they write "/ authorize" we "/oauth" > > Best regards > > Wolfgang > > -----Urspr?ngliche Nachricht----- > Von: fiware-api-cross-bounces at lists.fi-ware.eu [mailto:fiware-api-cross-bounces at lists.fi-ware.eu] Im Auftrag von Juanjo Hierro > Gesendet: Mittwoch, 22. Mai 2013 00:48 > An: fiware-api-cross at lists.fi-ware.eu > Betreff: Re: [Fiware-api-cross] OAuth 2.0 RESTful API > > > What is DT's position/comments to Antonio's input ? > > Thanks, > > -- Juanjo > > On 21/05/13 13:31, Antonio Tapiador del Dujo wrote: >> Dear all, >> >> The main document where the OAuth 2.0 standard is described is RFC 6749: >> >> http://tools.ietf.org/html/rfc6749 >> >> The interactions are principally described in section 4.0. They >> include HTTP verbs, URLs and parameters. For instance, the >> authorization request can be found at >> http://tools.ietf.org/html/rfc6749#section-4.1.1 and it includes an >> example of RESTful request: >> >> GET /authorize?response_type=code&client_id=s6BhdRkqt3&state=xyz >> &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1 >> Host: server.example.com >> >> >> Kind regards. >> _______________________________________________ >> Fiware-api-cross mailing list >> Fiware-api-cross at lists.fi-ware.eu >> https://lists.fi-ware.eu/listinfo/fiware-api-cross >> > > ________________________________ > > 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 > _______________________________________________ > Fiware-api-cross mailing list > Fiware-api-cross at lists.fi-ware.eu > https://lists.fi-ware.eu/listinfo/fiware-api-cross From atapiador at dit.upm.es Tue May 28 10:35:10 2013 From: atapiador at dit.upm.es (Antonio Tapiador del Dujo) Date: Tue, 28 May 2013 10:35:10 +0200 Subject: [Fiware-api-cross] GCP API review Message-ID: <51A46C3E.3020603@dit.upm.es> Dear all, I started the review of the GCP API. However, it is quite hard to follow the terms. Just in the second paragraph of "2. Interfaces to registration", three different terms appear without any prior description of them: customer, client and mandant. May we have a clear description of them? Removing duplicated terms would make things easier. Kind regards. From atapiador at dit.upm.es Tue May 28 10:47:49 2013 From: atapiador at dit.upm.es (Antonio Tapiador del Dujo) Date: Tue, 28 May 2013 10:47:49 +0200 Subject: [Fiware-api-cross] Thales Authorization Server API review Message-ID: <51A46F35.1020009@dit.upm.es> Dear all, I have reviewed the Thales Authorization Server API part that corresponds to the policy management. This is section "2. Policy Management Service API (PAP)" To the best of my knowledge, the API is suitable for policy manament in the OIL portal. The only thing I am missing is policy deletion. How can we delete policies in the Authorization Server? Kind regards. From jcervino at dit.upm.es Tue May 28 11:15:19 2013 From: jcervino at dit.upm.es (=?ISO-8859-1?Q?javier_cervi=F1o?=) Date: Tue, 28 May 2013 11:15:19 +0200 Subject: [Fiware-api-cross] Attributes and response needed by the Proxy In-Reply-To: <1474_1369231394_519CD022_1474_2644_1_DDCC8EDACD06614C9CE3DFEA2835890070C44D588A@THSONEA01CMS10P.one.grp> References: <1474_1369231394_519CD022_1474_2644_1_DDCC8EDACD06614C9CE3DFEA2835890070C44D588A@THSONEA01CMS10P.one.grp> Message-ID: Hi Cyril, I agree with you that some of these attributes can be included into the JSON Web Token. The main problem here is that in Keystone all tokens are related to only one tenant (organization). The user can be registered in more than one tenant (in the IdM), but he has to choose one tenant to work. And the token is related to that tenant. AFAIK, the best solution to this problem would be the use of OAuth scopes. These scopes are sent during OAuth authentication, but, basing on GCP API documentation (from DT) the scope has to be an AppID (page 97 of such document). Does anybody know if we can use that OAuth scope to provide the tenant id instead of the AppID? Doing so the solution seems fully compatible with Keystone and OpenStack. Cheers, Javier. On 22 May 2013 16:03, DANGERVILLE Cyril wrote: > Hello,**** > > This seems OK to me from the PDP side. With the following clarifications > for each attribute, and answer to your question:**** > > **1. ****OAuth token expiration date**. Retrieved from the standard > ?exp? claim of the JSON Web token (JWT) that is used as the OAuth token, > and that your proxy is required to send to the PDP: > http://self-issued.info/docs/draft-ietf-oauth-json-web-token.html#expDef * > *** > > Please note that the date format for that ?exp? (=IntDate= number of > seconds from 1970-01-01T0:0:0Z UTC until the specified UTC date/time) is > different from the date format in the Keystone ?token? element you gave as > an example. Therefore, **some conversion is required**. I would rather > NOT do such custom conversion in the PDP, to keep the GE as generic as > possible. **** > > **2. ****OAuth token ID**. Retrieved from the standard ?jti? claim > of the OAuth token (JWT): > http://self-issued.info/docs/draft-ietf-oauth-json-web-token.html#jtiDef.* > *** > > **3. ****User id**: User?s GCPID, as registered in the GCP (IdM > GE), retrieved from the OAuth token (JWT) claim ? > http://gcp.telekom.de/axschema/gcpid?.**** > > **4. ****User name**: you can define this attribute in the GCP or > you can use a default one defined for all GCP users, such as the email, > it?s up to you. Then it can be retrieved by the PDP from the Oauth token > (JWT). **** > > **5. ****User organization/tenant**: I see in your Keystone example > that you have a **tenantName and tenantId. Do you need both actually?** > In any case, you have to define a custom attribute in the IdM GE for each, > and for the attribute value, you can reuse the ${MANDANT_ID} (resp. > ${MANDANT_NAME}) natively defined in the GCP for tenantId (resp. > tenantName). The PDP will get it from the Oauth token. I have not tried > ${MANDANT_NAME} in my tests and I am unable to test at the moment (the GCP > site is on maintenance L ), so I cannot guarantee this work. You may ask > the IdM GE owner (Wolfgang). The alternative is always to set the literal > value yourself.**** > > **6. ****User role**: you can define this attribute in the GCP. In > this case, as I recall from a previous conf call, you expressed the > possibility that this attribute may be changed (multiple times?) during the > lifetime of the OAuth token. Therefore, getting it from the OAuth token is > not enough. So, for that attribute, the PDP will request the GCP API to get > the new value, for each of your proxy?s XACML request where the matched > policy requires that attribute.**** > > ** ** > > You can?t fail to notice that for all attributes, except the user role, > you can get them in your proxy from the Oauth token, instead of having the > PDP return it, just a suggestion.**** > > ** ** > > In the PDP XACML response, attributes will be returned in > s of s (see XACML 2.0 spec). **** > > Example :**** > > ** ** > > **** > > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" > xsi:schemaLocation="urn:oasis:names:tc:xacml:2.0:context:schema:os > access_control-xacml-2.0-context-schema-os.xsd">**** > > **** > > Permit**** > > **** > > ** > ** > > **** > > > **** > > ObligationId="urn:thalesgroup:xacml:obligation:forward" FulfillOn="Permit"> > **** > > > AttributeId="urn:oasis:names:tc:xacml:2.0:subject:role" > **** > > DataType="http://www.w3.org/2001/XMLSchema#string > ">Member**** > > * > > DataType="http://www.w3.org/2001/XMLSchema#string > ">somevalue**** > > **** > > **** > > **** > > **** > > ** ** > > ** ** > > Regards,**** > > CD**** > > ** ** > > *De :* fiware-api-cross-bounces at lists.fi-ware.eu [mailto: > fiware-api-cross-bounces at lists.fi-ware.eu] *De la part de* javier cervi?o > *Envoy? :* mardi 21 mai 2013 18:50 > *? :* Fiware-api-cross at lists.fi-ware.eu > *Objet :* [Fiware-api-cross] Attributes and response needed by the Proxy** > ** > > ** ** > > Dear all,**** > > ** ** > > For the development of the proxy we need a set of attributes that have to > be returned by the PDP in the request for token validation. These > attributes should be stored by the IdM and be returned by the PDP, and they > will be forwarded to the GEs. **** > > Here I send you an example of response from the Proxy to the GEs with > these attributes:**** > > ** ** > > {**** > > "access":{**** > > "token":{**** > > "expires":"2012-02-05T00:00:00",**** > > "id":"887665443383838",**** > > "tenant":{**** > > "id":"1",**** > > "name":"customer-x"**** > > }**** > > },**** > > "user":{**** > > "name":"joeuser",**** > > "tenantName":"customer-x",**** > > "id":"1",**** > > "roles":[**** > > {**** > > "serviceId":"1",**** > > "id":"3",**** > > "name":"Member"**** > > }**** > > ],**** > > "tenantId":"1"**** > > }**** > > }**** > > }**** > > ** ** > > Of course, this information should be provided also by the PDP but in a > format compatible with the PDP API. These attributes include information > about the auth token (expiration date, id, and organization to which it is > related), the user (name and id), the organization (tenant) in which the > user is authenticated, and the roles the user plays within the > organization. At UPM we believe that user, organization and roles can be > attributes that may be previously stored in the IdM, and that they can be > returned during the auth token request between the Proxy and the PDP.**** > > ** ** > > The question is whether you also believe these attributes can be defined > at the IdM and be returned by the PDP and why. I would also like to see an > example of PDP response where we could see these attributes.**** > > ** ** > > Thanks!**** > > ** ** > > Best regards,**** > > Javier Cervi?o.**** > > ** ** > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhierro at tid.es Tue May 28 13:15:52 2013 From: jhierro at tid.es (Juanjo Hierro) Date: Tue, 28 May 2013 13:15:52 +0200 Subject: [Fiware-api-cross] REMINDER: follow-up confcall on OAuth 2.0 and Access Control framework in FI-WARE Message-ID: <51A491E8.4070105@tid.es> Dear all, This is just a reminder of the confcall we are goint to have at 14:30, as already agreed yesterday during our regular joint WPLs/WPAs follow-up confcalls. We'll use powwownow. PIN: 050662. Local dial-in phone numbers at: http://pdf.powwownow.com/pdf/USA_en_pwn-dial-in-numbers.pdf Cheers, -- Juanjo ------------- Product Development and Innovation (PDI) - Telefonica Digital website: www.tid.es email: jhierro at tid.es twitter: twitter.com/JuanjoHierro FI-WARE (European Future Internet Core Platform) Coordinator and Chief Architect 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 ________________________________ 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 From cyril.dangerville at thalesgroup.com Wed May 29 18:29:58 2013 From: cyril.dangerville at thalesgroup.com (DANGERVILLE Cyril) Date: Wed, 29 May 2013 18:29:58 +0200 Subject: [Fiware-api-cross] Thales Authorization Server API review In-Reply-To: <51A46F35.1020009@dit.upm.es> References: <51A46F35.1020009@dit.upm.es> Message-ID: <8150_1369845000_51A62D07_8150_13900_1_DDCC8EDACD06614C9CE3DFEA2835890070C4580817@THSONEA01CMS10P.one.grp> Hello, The element you upload via the PUT method on the PAP API is your root XACML , which may include s or s again, like any . If you want to delete s in that root (or any other nested ), you upload a new version of the root without the s in question. I know my answer sounds a bit dumb, so maybe you meant something smarter? You can have 0 / in your root , an empty in other words, in which case the PDP will always return "NotApplicable" as XACML response (with the standard policy combining algorithms). Then it's up to the PEP to interpret that decision (permit/deny access?). FYI, there have been a few changes on the API since the publication of that Thales Authorization Server API document, especially the URLs. For more up-to-date info, please look at http://forge.fi-ware.eu/plugins/mediawiki/wiki/fiware/index.php/Access_Control_-_User_and_Programmers_Guide or http://forge.fi-ware.eu/plugins/mediawiki/wiki/fiware/index.php/Access_Control_GE.Authorization.Open_RESTful_API_Specification_%28PRELIMINARY%29 I hope I cleared things up a little bit. Feel free to ask if not. Regards, CD > -----Message d'origine----- > De?: fiware-api-cross-bounces at lists.fi-ware.eu [mailto:fiware-api- > cross-bounces at lists.fi-ware.eu] De la part de Antonio Tapiador del Dujo > Envoy??: mardi 28 mai 2013 10:48 > ??: fiware-api-cross at lists.fi-ware.eu > Objet?: [Fiware-api-cross] Thales Authorization Server API review > > Dear all, > > I have reviewed the Thales Authorization Server API part that > corresponds to the policy management. This is section "2. Policy > Management Service API (PAP)" > > To the best of my knowledge, the API is suitable for policy manament in > the OIL portal. The only thing I am missing is policy deletion. How can > we delete policies in the Authorization Server? > > Kind regards. > _______________________________________________ > Fiware-api-cross mailing list > Fiware-api-cross at lists.fi-ware.eu > https://lists.fi-ware.eu/listinfo/fiware-api-cross From atapiador at dit.upm.es Thu May 30 12:19:39 2013 From: atapiador at dit.upm.es (Antonio Tapiador del Dujo) Date: Thu, 30 May 2013 12:19:39 +0200 Subject: [Fiware-api-cross] Thales Authorization Server API review In-Reply-To: <8150_1369845000_51A62D07_8150_13900_1_DDCC8EDACD06614C9CE3DFEA2835890070C4580817@THSONEA01CMS10P.one.grp> References: <51A46F35.1020009@dit.upm.es> <8150_1369845000_51A62D07_8150_13900_1_DDCC8EDACD06614C9CE3DFEA2835890070C4580817@THSONEA01CMS10P.one.grp> Message-ID: <51A727BB.1020106@dit.upm.es> Thank you for your clarifications Cyril. It is clear now. I think the mechanism is ok, as long as PolicySets do not become too big. Regards. El 29/05/13 18:29, DANGERVILLE Cyril escribi?: > Hello, > The element you upload via the PUT method on the PAP API is your root XACML, which may includes ors again, like any. If you want to deletes in that root (or any other nested), you upload a new version of the root without thes in question. I know my answer sounds a bit dumb, so maybe you meant something smarter? > You can have 0/ in your root, an empty in other words, in which case the PDP will always return "NotApplicable" as XACML response (with the standard policy combining algorithms). Then it's up to the PEP to interpret that decision (permit/deny access?). > > FYI, there have been a few changes on the API since the publication of that Thales Authorization Server API document, especially the URLs. For more up-to-date info, please look at > http://forge.fi-ware.eu/plugins/mediawiki/wiki/fiware/index.php/Access_Control_-_User_and_Programmers_Guide > or > http://forge.fi-ware.eu/plugins/mediawiki/wiki/fiware/index.php/Access_Control_GE.Authorization.Open_RESTful_API_Specification_%28PRELIMINARY%29 > > I hope I cleared things up a little bit. Feel free to ask if not. > > Regards, > CD > >> -----Message d'origine----- >> De : fiware-api-cross-bounces at lists.fi-ware.eu [mailto:fiware-api- >> cross-bounces at lists.fi-ware.eu] De la part de Antonio Tapiador del Dujo >> Envoy? : mardi 28 mai 2013 10:48 >> ? : fiware-api-cross at lists.fi-ware.eu >> Objet : [Fiware-api-cross] Thales Authorization Server API review >> >> Dear all, >> >> I have reviewed the Thales Authorization Server API part that >> corresponds to the policy management. This is section "2. Policy >> Management Service API (PAP)" >> >> To the best of my knowledge, the API is suitable for policy manament in >> the OIL portal. The only thing I am missing is policy deletion. How can >> we delete policies in the Authorization Server? >> >> Kind regards. >> _______________________________________________ >> Fiware-api-cross mailing list >> Fiware-api-cross at lists.fi-ware.eu >> https://lists.fi-ware.eu/listinfo/fiware-api-cross