Dynamic auth for http callback endpoints

[lholthof]

Hi community,

I was happy to see that the callback url has become dynamic by transfer-pull-http-dynamic-receiver. Using this feature I realized that it is really only about the endpoint url, but not the authentication parameters. So how would I specify authKey, authCode or secretName for such a dynamic callback endpoint? Expectation was this should work similar to the HttpDataAddress of assets.

Regards, Lukas

[jimmarino]

Please see the Decision Record as there is a note about how authentication can be handled with dynamic callbacks.

[lholthof]

You refer to "Dynamic endpoints do not have explicit API keys. Security can be provided at the network layer or through a URI with an randomly-generated single-use path part."?

That means bottom line there is no real support within the dynamic endpoints for authentication. Are there any plans for improvement on this or is there a reason not to improve it? How about the idea to reuse the HttpDataAddress in this place?

[jimmarino]

A randomly generated URL that is used for a period of time serves pretty much the same purpose as a time-limited API key but we could look into a mechanism to add a simple API key in the future with a few caveats:

1. HttpDataAddress should not be used as it models an address where data can be resolved, not a callback endpoint
2. The lifecycle of the key should not be managed by the EDC. An external system should ensure the key is present in the vault and removed when it is no longer needed. The dynamic configuration can specify the vault path where the key is stored. This allows the key to be reused for multiple processes or one.

I am curious, dynamic endpoints are generally associated with very specific use cases. Why won't a static one work for you?

[wolf4ood]

Hi @lholthof as @jimmarino mentioned the Decision Record points the new callbacks mechanism. Once it's finished it will support both static and dynamic with auth support via Vault for secrets. From an implementation point of view we are only missing this to complete the feature. I will probably work on this soon and it will be available then on snapshot and the next release.

[lholthof]

I am curious, dynamic endpoints are generally associated with very specific use cases. Why won't a static one work for you?

A single connector will be called by various clients which initiate transferprocesses. Those clients are independent and do not share a common callback endpoint, but rather will offer their own callback endpoints individually.

Technically I agree the generated URL can offer the same purpose as a API key. But in contrast to an API key, the generated URL will not be supported by most clients out of the box. If we can rely on adopted auth mechanisms (e.g. oauth2) this would make the consumption much easier for the clients.

Hi @lholthof as @jimmarino mentioned the Decision Record points the new callbacks mechanism. Once it's finished it will support both static and dynamic with auth support via Vault for secrets. From an implementation point of view we are only missing this to complete the feature. I will probably work on this soon and it will be available then on snapshot and the next release.

I cannot identify the usage of vault for dynamic endpoints from the DR nor the issue. But if that would be enabled, it resolves my request :-) In the DR it is stated that auth-code-id would contain the reference key for the vault entry. Similarly the HttpDataAddress does it with the value secretName. Isn't an alignment between both domains reasonable as it does the same but in different contexts? A client on consumer side might also be a data provider, so the persona might work in both contexts, but has to adopt different terminology for it.

[wolf4ood]

@lholthof once we support the static endpoints, since they will share the same core code we can support the usage of the vault on dynamic callbacks