Reevaluate the security status of the Management API

[lgblaumeiser]

As discussed two weeks ago in person, we still want to motivate a reevaluation of the status of the Management API concerning the security impact.

Major argument here is, that even when the Management API is not standardized, it is the de-facto standard for accessing the EDC from the owners side. And in this respect it is the most open interface of the EDC as the interaction partner of the interface can be any kind of app, be it Open-Source, COTS or a proprietary implementation of a certain data space participant.

It is a de-facto standard, because currently existing Use Case implementations make use of the Management API as provided by the Tractus-X EDC. On this path, business models like EDC aaS are already evolving and there are currently three Enablement Service Provider on the market. There are requests for providing an EDC from all kinds of customers and some use cases require the EDC to be operated in another network segment then the services that use the Management API for interaction with the EDC.

From my point of view, it does not make sense to stick to the assumption, that the Management API is not accessible from the internet, the requirement is already there. That does not change the fact, that the amount of potential users of the API of a single EDC is a rather limited number of systems. What this means is, that

Requirement 1:
considerations concerning incoming vulnerabilities should be done on the basis, that the api is attackable from the internet.

A second point here involves the usage of an API key. I have to admit, that I do not have the full story, but what came up in our discussion is, that with managing its own api-key the EDC gets relevant in ISO 27001 certifications as an Identity Provider. There are questions in audits like how is ensured that tokens are revocable or how do you trace down compromised tokens? An optimal operation strategy reduces the amount of Identity Providers which means that ideally, the EDC should make use of a authentication mechanism that relies on an external Identity Provider to authenticate and authroize a request.

I know, that you recommended in the past to just build that into the EDC used locally, but that again creates the issue mentioned above. As an EDC aaS provider, we have no control on the application that make use of the EDC. If that is a standard app that relies on a Catena-X and Tractus-X release, it simply makes use of API-Key mechanism as this is the de-facto standard. That is, why such a change should be done in the official release of the Tractus-X EDC in a managed fashion, so that it is clear to all participants of the Catena-X ecosystem that this is the prefered way of communicating with the EDC.

Requirement 2:
The Eclipse Tractus-X EDC Management API should have an authentication mechanism, that makes use of an external Identity Provider to validate access to the api.

In our discussion, we came up with two potential solutions for this issue:

1. The standard request as, e.g., stated in discussion [Extended Sync] Oauth2 as authentication method for Management API #1071, basically use an Oauth2 workflow for authentication.
2. A second solution, we came up with, would not change the current mechanism from outside, still an api-key is used for authentication. But the validation is then done using an external IdP, e.g., Keycloak. This way, revocation is centralized without a change of the actual api. Only the setup of a new EDC would be affected.

I would really like to get into the discussion here, as these points are real issues for us. Basically we are in the situation, that following your current recommendation we would have to reject valid business models, or, if not, take the fact, that we operate a service with a suboptimal vulnerability management in place. Both are not desirable solutions.

[lgblaumeiser]

Handled by eclipse-tractusx/sig-release#616