Hi All, I guess my comment in GH regarding Polaris-owned tokens was not precise enough. Apologies for the confusion and I'll try to clarify below.
As far as I understand, in RJ's use case, Polaris is actually expected to pass the user's auth token from Polaris API to STS. Arguably, it is a very specific use case and may be applicable only to some very specific on-prem environments (please correct me if I misinterpret that), but I believe it is fine to support. In that use case Polaris acts as a Resource server from the OAuth2 perspective and no extra auth tokens are necessary. Outside of RJ's use case (and PR), I do not really object to supporting OAuth2 token exchange in Polaris. It could be a valuable feature, but from my POV it is a totally separate feature (not related to [3170]) [3170] https://github.com/apache/polaris/pull/3170 Cheers, Dmitri. On Thu, Dec 4, 2025 at 2:22 PM Arsenault, Reginald P. via dev < [email protected]> wrote: > UNCLASSIFIED / NON CLASSIFIÉ > > Hi Laurent, Thanks for your questions! > > > 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. > > We are too, which is why can’t go with the standard > access-key-id/access-key-secret setup that a regular AWS S3 system uses. By > passing along the short lived JWT token of the user to the STS, we can get > a new, short-lived, access-key-id/access-key-secret for our on-prem S3 > buckets with every request. Having one generic service account doing all > the operations on the S3 for all our users is a security risk for us. > > > > 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? > > For our on-prem S3/STS setup we have no issue with users accessing STS > System directly. It is normal for users to be able to access the buckets. > The STS checks the permissions users have on the buckets they’re > requesting, so there is no way for a user to gain more privileges to > potentially read/write a bucket they don’t get access to through polaris, > by going directly to the STS. If anything if a user going directly to the > STS they’d get MORE permissions, which is totally fine and completely > reasonable. > > > > 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? > > We heavily audit what the users are doing. Polaris will log “this user is > requesting credentials for this table”, the STS logs “this user is > requesting credentials for this bucket” and our on-prem S3 logs “this user > did <thing> to this bucket.” There is no concern from us over someone > potentially skirting privileges. > > > > 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? > > From what I gather, Polaris has no intentions on being in the business of > issuing JWT tokens [1]. Again, for our on-prem S3 system, we have no issue > with users going around Polaris to access the STS and S3, this is by > design. There is no guarantee that this feature will work for AWS/Minio > [2], it will enable Polaris to support on-prem S3 use cases like [3], > making it more widely available for everyone. > > [1] https://github.com/apache/polaris/pull/3170#issuecomment-3606973902 > [2] https://github.com/apache/polaris/pull/3170#issuecomment-3608346092 > [3] https://github.com/apache/polaris/issues/3038 > > Thank you for your feedback and please let me know if there’s any more > questions! > > Thanks, > R.J. >
