Hello Reginald, I have some questions not related to the PRs or code change but regarding the general approach, and I hope you don't mind.
I'm a big fan of those token exchange scenarios which avoid to create long lived secrets to interact between systems, and rely instead of setting trust mechanisms between them. (This is also why I'm looking forward for better oauth support in iceberg as well). My main question is that if the authorization token sent to polaris is passed as-is to the STS server, what happens if the client directly sends the token to the STS system directly? Wouldn't it be bypassing Polaris authorization system and grant the client full access to the storage location (to the extend of the IAM policy). You probably have thought of that scenario already so you may have some contingency system in place or maybe it's not a actual issue in your deployment situation? It woud be great if you could elaborate a bit as it is always nice when people exchange their best security practices. One idea I had to prevent user to bypass Polaris authorization system would be for Polaris itself to issue its own JWT tokens, and when accessing storage, Polaris would do an internal exchange where claims from the inbound token (received by Polaris) would be copied over to the outbound token (sent to STS), after proper validation of course. Is it a scenario you have considered by any chance? Hope to hear more, Cheers, Laurent On Thu, Nov 20, 2025 at 11:32 AM Arsenault, Reginald P. via dev < [email protected]> wrote: > UNCLASSIFIED / NON CLASSIFI? > > Hi! As per our findings in [2], we are looking to enable connectivity with > our on-prem S3 storage appliance, which requires changes to how Polaris > connects to S3. Currently, the way Polaris connects to S3 does not work for > our on-prem S3 instance because of the way it expects to connect to the STS > server (i.e. without any specific authentication). > We propose enhancing the AwsCredentialsStorageIntegration to support a > more flexible authorization mechanism: > > * Goal: We want the ability to pass the requesting user's identity > (likely a token) to the STS. This would allow the STS to make fine-grained > decisions on what the user can and cannot do based on their specific > identity. > * Proposed Implementation: We believe this functionality can be > achieved by adding an option within AwsCredentialsStorageIntegration [1] to > connect using the AssumeRoleWithWebIdentity flow. > We would greatly appreciate some guidance on the following changes before > we begin development: > > 1. What is the recommended or existing mechanism within Polaris for > capturing and passing along an authenticated user's identity token to the > AwsCredentialsStorageIntegration component, so we can pass it to the STS? I > could be wrong, but I believe the token that gets passed to STS doesn't > need to be scoped for the STS, so it could just be whatever token is given > to Polaris by the user. > 2. How should we best modify the AwsCredentialsStorageIntegration class > and configuration to be able to handle both the existing AssumeRole use > case and the new AssumeRoleWithWebIdentity use case? > Any pointers or suggestions on the best place to inject the user token and > manage the configuration switch would be helpful. > > [1] > https://github.com/apache/polaris/blob/main/polaris-core/src/main/java/org/apache/polaris/core/storage/aws/AwsCredentialsStorageIntegration.java#L107 > [2] https://github.com/apache/polaris/issues/3038 >
