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?
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