In our workflow, we need to pass an identityToken (This is different from the x-amz-security-token) to the downstream CredentialsProvider service to resolve the identity
Option 1
Currently, we have emulatedAccessKey, session fields in the CredentialsProvider. Would it make sense to add another field - identityToken to this method ?
Changes required:
Pass identityToekn as a query parameter -
|
credentialsKey.session().ifPresent(sessionToken -> uriBuilder.queryParam("sessionToken", sessionToken)); |
Pass Optional.empty() in
|
return credentialsProvider.credentials(request.requestAuthorization().accessKey(), request.requestAuthorization().securityToken()) |
A custom SigningController can pass in the required IdentityToken
Option 2
Add a new default method (with IdentityToken) to the interface that calls credentials(String emulatedAccessKey, Optional<String> session). The implementing class can choose to have their own logic for the identityToken
Option 3
As discussed with @Randgalt, passing the Request object to the credentials provider seems to be a reasonable and scalable approach. This might change code at a lot of places, but should still be doable
Any other approaches also appreciated!
In our workflow, we need to pass an identityToken (This is different from the x-amz-security-token) to the downstream CredentialsProvider service to resolve the identity
Option 1
Currently, we have emulatedAccessKey, session fields in the CredentialsProvider. Would it make sense to add another field - identityToken to this method ?
Changes required:
Pass identityToekn as a query parameter -
aws-proxy/trino-aws-proxy/src/main/java/io/trino/aws/proxy/server/credentials/http/HttpCredentialsProvider.java
Line 97 in 2ab4bb4
Pass Optional.empty() in
aws-proxy/trino-aws-proxy/src/main/java/io/trino/aws/proxy/server/signing/InternalSigningController.java
Line 114 in 2ab4bb4
A custom SigningController can pass in the required IdentityToken
Option 2
Add a new default method (with IdentityToken) to the interface that calls
credentials(String emulatedAccessKey, Optional<String> session). The implementing class can choose to have their own logic for the identityTokenOption 3
As discussed with @Randgalt, passing the
Requestobject to the credentials provider seems to be a reasonable and scalable approach. This might change code at a lot of places, but should still be doableAny other approaches also appreciated!