[Fiware-security] Session about API Access Control on Monday May 13 afternoon

Juanjo Hierro jhierro at tid.es
Fri May 10 11:28:00 CEST 2013


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<http://www.tid.es>
email: jhierro at tid.es<mailto:jhierro at tid.es>
twitter: twitter.com/JuanjoHierro

FI-WARE (European Future Internet Core Platform) Coordinator
and Chief Architect

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<http://www.tid.es>
email: jhierro at tid.es<mailto:jhierro at tid.es>
twitter: twitter.com/JuanjoHierro

FI-WARE (European Future Internet Core Platform) Coordinator
and Chief Architect

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: <https://lists.fiware.org/private/old-fiware-security/attachments/20130510/86a5f926/attachment.html>


More information about the Old-Fiware-security mailing list

You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy   Cookies policy