I want to delegate the validation of the authentication information for the management api to an external identity provider
The current practice of managing an api-key within the EDC has the disadvantage, especially for a EDC aaS provider, that many different EDC services manage their own key, which makes them in principle an identity provider. This contradicts the general strategy to reduce the number of identity providers ideally to one. The reason for that is, that processes like key rotation are simplified to one service. In addition, security audits typically involve to a large degree the identity providers and check the configuration of those. With many EDC services running, this increases the efforts for such audits.
In summary, an additional mechanism will be provided, that allows authentication by standard JWT bearer token. It is an alternative way to authenticate and does not replace the existing api-key mechanism. The token is checked using an standard identity provider like Keycloak following standard OAuth protocols.
The feature does not include any changes towards authorization, a request with a valid token is executed without further limitations.
Impact
The concept allows to run EDCs as used without any change. The authentication delegation is added as additional feature. An EDC operator has to choose whether he wants to make use of the common authentication means or make use of the new concept. This requires of course, that all calling clients of the EDC are aware of the change and use the standard REST Authorization header with the bearer token method. For compatibility reasons, the api will allow to make use of the x-api-key header instead, i.e., a client can make use of a long living token that is used like an api-key from the client, but validated from the EDC like a standard token.
Description
As an EDC operator,
I want to delegate the validation of the authentication information for the management api to an external identity provider
The current practice of managing an api-key within the EDC has the disadvantage, especially for a EDC aaS provider, that many different EDC services manage their own key, which makes them in principle an identity provider. This contradicts the general strategy to reduce the number of identity providers ideally to one. The reason for that is, that processes like key rotation are simplified to one service. In addition, security audits typically involve to a large degree the identity providers and check the configuration of those. With many EDC services running, this increases the efforts for such audits.
An implementation concept exists and is described in the upstream item: https://github.com/eclipse-edc/Connector/issues/4261
In summary, an additional mechanism will be provided, that allows authentication by standard JWT bearer token. It is an alternative way to authenticate and does not replace the existing api-key mechanism. The token is checked using an standard identity provider like Keycloak following standard OAuth protocols.
The feature does not include any changes towards authorization, a request with a valid token is executed without further limitations.
Impact
The concept allows to run EDCs as used without any change. The authentication delegation is added as additional feature. An EDC operator has to choose whether he wants to make use of the common authentication means or make use of the new concept. This requires of course, that all calling clients of the EDC are aware of the change and use the standard REST Authorization header with the bearer token method. For compatibility reasons, the api will allow to make use of the x-api-key header instead, i.e., a client can make use of a long living token that is used like an api-key from the client, but validated from the EDC like a standard token.
Additional information