Hi Laurent, Great questions - I've raised the same concerns in the PR yesterday, using the implementation to interpolate the answers to the questions you've posed: https://github.com/apache/polaris/pull/3170#pullrequestreview-3532561629.
I will continue responding on the PR - but would prefer we answer these high-level questions on the ML here. Best, Adnan Hemani On Wed, Dec 3, 2025 at 11:24 AM Laurent Goujon <[email protected]> wrote: > 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 > > >
