5

I want to provide access control at the Orion Context Broker NGSI API level to ensure real data isolation. I want to make sure that a tenant can only query/update their contexts and NOT those of another tenant.

To do so, I started putting an instance of Wilma PEP Proxy in front of Orion Context Broker. Then I configured my own Identity Manager keyrock GE instance based on official IdM Keyrock docker image and my own Authorization PDP GE based on official AuthzForce docker image.

After a few days of configurations and many tries, finally I could have these three security Generic Enablers working fine, authenticating and authorizing requests for the Orion Context Broker NGSI API using PEP Proxy level 2.

However, level 2 of authorization is not enough to ensure what I want, because service (tenant) and sub service (application path) information are in the headers of the request. Particularly in Fiware-Service and Fiware-ServicePath headers. In order to build header-based authorization policies you need to use level 3: XACML authorization.

The problem is that I made some digging in official documentation of Fiware and I could not find any example of an XACML policy. Besides official documentation of Wilma PEP Proxy (see here) says that you may have to modify PEP Proxy source code in order to get this level of authorization.

As this case is thought to check advanced parameters of the request such us the body or custom headers, it depends on the specific use case. So the programmer should modify the PEP Proxy source code in order to include the specific requirements.

It it's that possible?

Do I really have to modify the PEP Proxy source code to achieve something as simple as a tenant can only access his data?

cdan
  • 3,470
  • 13
  • 27
Emiliano Viotti
  • 1,619
  • 2
  • 16
  • 30

1 Answers1

1

very good question. There are alternative GEis that support perfectly the use cases you are referring to. Please check this presentation

https://es.slideshare.net/FI-WARE/building-your-own-iot-platform-using-fiware-geis

thanks, best

Jose Manuel Cantera
  • 853
  • 4
  • 4
  • Jajajaj. Your response is indeed very good but in my case I do not think I will be of much help. I already used Telefonica implementations, Steelskin PEP Proxy, Keystone-spassword and Keypass and from my point of view they are very clear and much more complete than reference implementations. However it does not provide OAuth2 support and that is crucial if you want to integrate with other GEs like Wirecloud. – Emiliano Viotti Jun 30 '17 at 19:18
  • Adding to my previous comment, I think it would be great if Telefonica I+D implementations could be integrated with the entire ecosystem of existing GEs in Fiware, using OAuth2. In addition, Telefonica's implementation does not provide a management portal such us IdM Keyrock, based on a Horizon Openstack fork. I am afraid that if I want both, OAuth2 integration and finer access controls I will have to extend one of the two solutions by getting into the source code. – Emiliano Viotti Jun 30 '17 at 19:32