Forwarding Headers (e.g. for Authentification)

[BeFranke]

WHAT
Allow the EDC to forward headers from the clients request to the backend application.

Ideally, also implement some sort of name-mangling to enable headers like "X-Api-Key" to be sent to the backend application, despite the EDC using its own X-Api-Key (e.g. the Client-defined Header "Backend_X-Api-Key" gets rewritten to "X-Api-Key" before being passed to the backend application or similar).

From my current tests, it seems like headers are generally not forwarded, at least when using the Adapter Extension.

WHY
This can be used e.g. for authentification against a backend application in cases where BPN validation is not enough (maybe not all users of a company may access a certain resource), or an already authentification-based application shall be deployed behind an EDC without major modifications (this is my current use case).

SOLUTION PROPOSAL

• Forward any header sent by the client to the backend application if it is not used by the EDC
• Ideally also provide name mangling idea so headers like "X-Api-Key", that clash with EDC headers, can be set for the backend application

FURTHER NOTES
Discussion created as advised by @stephanbcbauer

I searched for documentation on this feature but could not find any, and my tests point me to the assumption that this feature does not yet exist. If I am wrong and it is possible to forward headers already, please let me know :)

[paullatzelsperger]

On the protocol side of things, i.e. DSP, there is no user identification beyond the connector identifier (here: BPN), that means, the connector cannot identify individual users. Or in other words: there is only one user, and that is the BPN.

If you want to implement fine-grained access control on the Management API side, you could extend the AuthenticationService using the protocol of your choice. Be advised though, that the auth-information from the Management API (e.g. "X-Api-Key") should never be forwarded anywhere beyond that service.

In your use case the provider's data plane needs to handle authentication against the backend. You could attach user information to EndpointDataReference#properties.

[BeFranke]

Thank you for the response.

On the protocol side of things, i.e. DSP, there is no user identification beyond the connector identifier (here: BPN), that means, the connector cannot identify individual users. Or in other words: there is only one user, and that is the BPN.

Does this necessarily imply that it would be impossible to simply forward headers via the data plane? As far as I understand it, the EDC would not need to distinguish between users for this. In the ControlPlaneAdapterExtension Workflow:

1. the client requests an EndpointDataReference via the control plane
2. with this reference, the client then requests the asset via the data plane

If in step (2), both the consumer and the provider data plane simply forward any header (that they do not use themselves) attached by the client to the request, wouldn't this enable e.g. BasicAuth between the client and the backend application, as BasicAuth is nothing more than a field in the header of the request?

The EDC can already forward Http Body and Query Params, would Headers be different?

[paullatzelsperger]

We don't want to blindly tunnel through HTTP headers for various reasons, security being one, and we certainly don't want to rewrite and un-rewrite headers. Typically, having body, path and query params should be sufficient to formulate the request, as headers only add request metadata. So for us to even consider this, there would have to be a very strong use case.

In Catena-X a decision was made that the BPN is the root identifier, and all authentication and authorization must be derived from it. So I'm wondering, what your exact use case is? Why do you need to tunnel through headers from api-client -> consumer-DP -> provider-DP -> provider-backend?

[BeFranke]

In the mentioned use case we would want to make a application that employs User-based Authentification (more fine grained than the BPN) available behind an EDC. But if this is clearly against your design goals, we willneed to find a workaround, maybe with the help of a proxy that rewrites a POST request or something like that.
Thanks anyway!