S3 data plane fails on non-temporary credentials in the vault

[ronjaquensel]

Bug Report

Describe the Bug

According to the S3 data plane's README, both AwsSecretToken and AwsTemporarySecretToken can be read from the vault and used for authentication. My tests have revealed that this is only possible for AwsTemporarySecretToken and will run into an error for AwsSecretToken. The combination of only accessKeyId and secretAccessKey (without session token) currently only works when putting the credentials directly into the data address.

Expected Behavior

I can put either an AwsSecretToken or an AwsTemporarySecretToken into the vault and authentication with AWS works correctly during a transfer.

Observed Behavior

If I put an AwsSecretToken into the vault and reference this in a data address, the authentication with AWS fails with message "sessionToken must not be null".

Steps to Reproduce

Steps to reproduce the behavior:

1. Put a secret with AWS credentials into the vault with the following format: {"edctype": "dataspaceconnector:secrettoken", "accessKeyId": "<aws-access-key-id>", "secretAccessKey": "<aws-secret-access-key>"}
2. Reference this secret in an asset's data address of type AmazonS3 using the keyName property
3. Create other entities & do a negotiation
4. Initiate a transfer for that asset
5. See the following in the provider's error logs:

SEVERE 2024-09-25T15:13:09.185936016 StateMachineManager [DataPlaneManagerImpl] error caught java.lang.NullPointerException: sessionToken must not be null.

Context Information

• Used version EDC 0.9.0
• OS: Linux/Ubuntu

Possible Implementation

The issue lies in the createS3ClientRequest method of the S3DataSourceFactory. Here, the secret is read from the vault and deserialized directly to an AwsTemporarySecretToken. If the deserialization was successful, the AwsTemporarySecretToken instance will be used, and if the deserialization failed, accessKeyId and secretAccessKey are instead read from the data address directly. Since also AwsSecretToken can be deserialized to an AwsTemporarySecretToken (with sessionToken=null), the invalid AwsTemporarySecretToken is used, which causes the above mentioned error.

Instead of always deserializing the secret to an AwsTemporarySecretToken, it should instead be deserialized to either an AwsSecretToken or an AwsTemporarySecretToken depending on its content.

The same applies for the S3DataSinkFactory.

[github-actions]

Thanks for your contribution 🔥 We will take a look asap 🚀

[github-actions]

This issue is stale because it has been open for 14 days with no activity.