Replies: 3 comments
-
|
What are the security checks that need to be done on backend data side? The connector is already taking care of enforcing the policy and ensure that the consumer participant has the rights to get the data. In any case you can provide more custom headers by extending either the provisioner in the control-plane (as done in the provision-additional-headers extension) or the |
Beta Was this translation helpful? Give feedback.
-
|
An example is the existence of use-case-specific roles. The existence of a Traceability-credential may be translated to a technical user with scope view_traceability_data. I'm unsure if this translation should be done in the EDC or in an arbitrary rule engine in the backend. Either way, the backend will need information from the use-case credentials - either in the native Catena format or in a form the backend can directly interpret. I doubt that adding specific new headers is going to solve this problem long-term. Now, it would be easy to say "you can just create a data assets with different credentials for each scope and check the use-case-credential via an EDC access-policy". That may work but would bloat the catalog, map the roles implicitly via the credentials via configuration in two places. |
Beta Was this translation helpful? Give feedback.
-
|
Closing for now as requirement remains unclear |
Beta Was this translation helpful? Give feedback.
-
When a Provider Data Plane delegates an incoming request, Backend Data Systems will do their own security checks. Currently, there are two pieces of context the Backend Data Systems get:
In order to interpret the HTTP-Headers, there's Catena-X-custom logic required. It can't be assumed that backend data systems will know what a BPN is. And even if they did, implementing access control based on headers is sketchy. We should think about how as much as possible of the negotiation context can be provided to Backend Data Services in a way they understand.
Beta Was this translation helpful? Give feedback.
All reactions