Feature Request: DataPlane specific custom token generation services tokens

[ivokulms]

Feature Request

For DataPlane authentication currently a hardcoded TokenGenerationService is implemented (TokenGenerationServiceImpl).

For scenarios where several DataPlane components are hosted on different systems, there would be the need for custom and different TokenGenerationServices for each DataPlane.

So the feature request is to be able to provide custom TokenGenerationService instances for individual DataPlanes.

Which Areas Would Be Affected?

This mainly affects the transfer-data-plane extension (Depending on the implementation approach. See below.)

Why Is the Feature Desired?

• Allow to use custom TokenGenerationServices instead of the built-in implementation
• Allow individual TokenGenerationServices for DataPlanes

Solution Proposal

Allow to inject TokenGenerationServices via Extansion and support using the DataPlane proxy URL for selection of the matching TokenGenerationServices for the corresponding DataPlane.

Implementation Proposals

Implementation 1 - Provide specialized DataPlane TokenGenerationService via Extention

• Create a DataPlaneTokenGenerationService interface with the following method, that passes the DataPlane url

  Result<TokenRepresentation> generate(@NotNull String dataPlaneUrl, @NotNull JwtDecorator... decorators);

• Wrap the current TokenGenerationServiceImpl in an instance of DataPlaneTokenGenerationService.

• Expose the wrapped TokenGenerationServiceImpl as default provider for DataPlaneTokenGenerationService

• Inject the DataPlaneTokenGenerationService instance into TransferDataPlaneCoreExtension

• Pass the instance along to ConsumerPullTransferEndpointDataReferenceServiceImpl and use it in :createProxyReference

Custom TokenGenerationServices can be provided via extension and can be selected to match the given "dataPlaneUrl".

Implementation 2 - Enhance existing TokenGenerationService

This implementation is similar to the previous one, but does not add a new "DataPlaneTokenGenerationService" class, but alters the existing TokenGenerationService with a "generate" method that allows to select a specific TokenGenerationService.

Result<TokenRepresentation> generate(@NotNull String selector, @NotNull JwtDecorator... decorators);

Implementation 3 - Central Named Intances Registry

A more generic approach would be to enhance the current core service registry mechanism.

The current extension mechanism uses only one Instance per class. For the case of the TokenGenerationService, where we need multiple instances, we could add a central registry, where globally shared instances are not only selected by class, but also have a "name" under which they are registred.

So the new methods would look like:

public <T> void registerService(Class<T> type, String instanceName, T service)

public <T> T getService(Class<T> type, String instanceName)    

These instances could also be addressed by the injection mechanism, by altering the "Inject" annotation with an instance name

@Inject (name = "XYZToken")

Implementation 4 - Named TokenGenerationService Instances Registry via Extension

Similar to implementation 3, but not implemented as a core service, but as a TokenGenerationService registry implemented in the transfer-data-plane extension. Allows multiple extensions to add individual named TokenGenerationServices.

Implementation Comparison

Implementation	Pros	Cons
Implementation 1	Changes only in transfer-data-plane	Overspecialized DataPlaneTokenGenerationService with no real functionality
Implementation 2	Generic TokenGenerationService Extension	Affects code outside transfer-data-plane
Implementation 3	Reuses existing core infrastructure	Changes in core needed
Implementation 4	Changes only in transfer-data-plane	TokenGenerationService would be dependent on transfer-data-plane extension

[jimmarino]

Thanks for the write-up but why can't you just substitute the default jwt-core module for a custom one that you provide? You can then implement the TokenGenerationService to match your requirements.

[ivokulms]

Hi Jim,

thanks for the fast reply on my request.

Providing an own jwt-core would solve the requirement for providing a custom token generation service.
But we are using multiple DataPlanes and each DataPlane does need an own TokenGenerationService instance.

So the requirement is to provide a custom TokenGenerationService for each DataPlane.

If a method containing the proxyURL of the dataplane, for identifying the dataPlane, would be added to the interface
Result<TokenRepresentation> generate(@NotNull String dataPlaneUrl, @NotNull JwtDecorator... decorators);
then replacing jwt-core would work.

Best Regards, ivo

[jimmarino]

Hi Ivo,

I think two approaches can solve this problem that don't require the significant changes you outlined:

1. Implement your own ConsumerPullTransferDataFlowController that produces the EDR however is appropriate. I recommend this approach as it appears your requirements call for custom logic to determine the data plane.

2. Implement a custom TokenGenerationService that can select which token to create. The TokenGenerationService implementation could be a multiplexer that delegates to specific generators. There is no need to introduce this type of behavior into the SPI (e.g., through a registry). It may be the case that an overloaded method on TokenGenerationService that takes a discriminator is required:

    default Result<TokenRepresentation> generate(String tokenContext, @NotNull JwtDecorator... decorators) {
        return generate(decorators);
    }

ConsumerPullTransferEndpointDataReferenceServiceImpl can then pass the proxy endpoint as the context:

        var tokenGenerationResult = tokenGenerationService.generate(request.getProxyEndpoint(), decorator);

However, this seems a bit brittle, and it is not ideal that the dataplane type is discernable from its address.

[ivokulms]

Approach 1

Providing an own ConsumerPullTransferDataFlowController could be achieved by
a. providing a complete own copy of transfer-data-plane, but then we have to maintain all future changes in this package
b. to register our ConsumerPullTransferDataFlowController in the dataFlowManager registry after this has happened in TransferDataPlaneCoreExtension:initialize. How would we make sure that our extension will then be initialized AFTER TransferDataPlaneCoreExtension, so that we override the default instance?

But maybe there is an extension point, that I have overlooked, that allows this replacement in a more elegant fashion.

Approach 2

Your second approach is similar to the "Implementation 2" I proposed in my request.
For that solution we would need to add the method with the "tokenContext" as a selector for multiple services in the interface and to allow to replace the TokenGenerationService from jwt-core via extension mechanism. I agree, passing the proxyUrl is not very elegant, but it is practical.

Getting rid of the of the "tokenContext" could be achieved by passing all data plane properties from the config
edc.dataplane.selector.1.properties={"publicApiUrl": "xyz", "myCustomSetting: 123"}
up to the ConsumerPullTransferEndpointDataReferenceService instance, so that all properties are available here and can be passed to the TokenGenerationService. This would allow to provide custom settings for each data plane and a custom TokenGenerationService implementation, without defining which settings have to be provided. The overspecialized "tokenContext" would be in that case a list of custom data plane properties, which is a more flexible concept. This approach could replace the ConsumerPullTransferProxyResolver.

[jimmarino]

Solution 2 in my opinion is not a good solution because of the proxy URL issue. It also couples the token generation service with knowledge of the data plane and ripples throughout the codebase.

The issue is your use case requires specialized data transfer metadata. DataFlowController is the extension point we have architected in the EDC for this purpose. You need to replace the transfer-data-plane extension with your own, and TransferDataPlaneCoreExtension will no longer be on the classpath.

[ivokulms]

So far I understood that the current "transfer data plane" implementation is the user ready version for http based data planes, that also is designed to support data planes that may have one dedicated DPF per geographical region (from "Technical concept DPF Selector" documentation).
That would require very likely custom authentication services to be configured and therefore some data plane related configuration data. This is why I am trying to find a clean way to alter the current code instead of creating my custom implementation of the whole transfer data plane and also would like to add this as contribution.

If "transfer data plane" is not meant to be a ready to use and extend implementation, but always has to be replaced by a custom version, then I do not understand why, for example, ConsumerPullTransferProxyResolver is implemented as an extension point if only used in this specific implementation.

If "transfer data plane" is meant to be the default implementation, another approach for data plane specific configuration could be to generalize the current ConsumerPullTransferProxyResolver not only to return the proxyUrl, but replace it with a resolver that does return all custom data plane properties. These properties could then be passed as a second parameter to ConsumerPullTransferEndpointDataReferenceService:createProxyReference. That would allow custom implementations of ConsumerPullTransferEndpointDataReferenceService to handle internally the specific requirements by having access to all properties oof the selected data plane instance. But then somehow we have to disable TransferDataPlaneCoreExtension to register its DataFlowController instances, so that we can provide our own ones.

[jimmarino]

The clean way to do this is Scenario 1 as I mentioned above. This avoids rippling changes throughout the codebase and implicitly coupling core token services with the specific token generation requirements of a data plane implementation. Scenario 1 is extremely simple to implement and will be easier to manage in your case as well. This approach can also work with the existing DPF.

Everything is implemented in EDC as an extension, even core services that are not necessarily intended to be "replaced." Turtles all the way down.

[ivokulms]

OK Jim, thanks for your patience with me. We can close this request.

[jimmarino]

OK thanks. Keep us up-to-date about your progress.