Hey all, Sorry for the radio silence and thank you for the clarification!
As far as I can tell, token exchange looks the most promising solution. @Alexandre Dutra if you need a hand with this, I would be happy to help. Kind regards Sander Op vr 27 feb 2026 om 19:09 schreef Daniel Weeks <[email protected]>: > I can provide some context about how this behavior evolved. > > First, it's worth acknowledging that the early approaches to solving > identity propagation used some OAuth features that weren't well supported > or relied on rather bespoke implementation decisions. What we currently > have isn't ideal and we want to figure out the right path forward as we > improve the Auth support in Iceberg and how to integrate that into OSS > engines. > > Trino was one of the earliest (maybe only) systems that was typically > deployed as multi-tenet with support for the REST Catalog as it was > evolving. The challenge was figuring out how to propagate user identity > from the engine to the catalog in a secure way that could be trusted. > Given the sessionized design of Trino's catalog interfaces, the identity > exchange approach appeared to fit the sessionization and had mechanisms in > OAuth to support impersonation from the engine/catalog client. The > implementation was intended to use a service account that could communicate > as a trusted relationship with the REST Catalog and then perform identity > impersonations through token exchange to act as a user for subsequent user > initiated calls. > > I don't know if there is a singular standard for achieving this currently > and security concerns make some approaches questionable. For example, you > could imagine that an engine could simply forward the token used for > access, but handing off a token between separately governed systems is > generally frowned upon. I've seen many different proposals for how > different systems echange, mint, propogate tokens where multiple services > are involved, but it's unclear to me if a singular standard exists that > addresses all configurations and security concerns. > > If token exchange remains viable and we just need to improve the > mechanisms to make it more standards compliant (e.g. fix how the subject > JWT is constructed), I think everyone would be supportive of that. > > At this point, I believe Trino is the only engine supporting this, so it > would be great to find a solution that would carry forward to other > engines. I would also be open to rethinking this if the right solution is > to remove complexity from the core library and push session management to > the implementing engine. That would possibly simplify much of the session > handling we do in core today. > > All that said, we're very open to improving this in any way that moves us > toward a more standard approach. > > -Dan > > > > > > On Mon, Feb 23, 2026 at 5:50 AM Alexandre Dutra <[email protected]> wrote: > >> Hi Sander, >> >> On the use of the service account for initial communications: this is >> actually by design and is Iceberg's standard behavior. When a REST >> catalog client is created and initialized, it uses the catalog's >> credentials (the service account in your scenario). The user context >> is only relevant after initialization. I believe this is done because >> a catalog client can be shared across multiple user contexts and >> therefore must be initialized with system credentials. Dan may have >> additional context on this design choice. >> >> Regarding your point about Trino constructing its own JWT: I agree. >> That was exactly my earlier concern about the entire interaction being >> hard-coded, which explains why users find its configuration difficult. >> The token exchange example you found is the Iceberg side of the same >> coin; it's currently undocumented, and only leveraged by Trino. >> >> All of this to say: I'm afraid that what you are trying to achieve >> (multitenancy with token exchange) is simply not possible today. >> People generally work around this issue by doing the token exchange >> off-band, then feeding the resulting token to the catalog config. >> >> But I have good news: this will be re-worked in the v2 version of the >> manager that I am currently preparing. Token exchange is becoming a >> first-class feature, which means you'll soon be able to use it easily >> with providers like Keycloak. If you're interested, the design >> document for v2 is available here: >> >> >> https://docs.google.com/document/d/1Hxw-t8Maa7wZFmrlSujm7LRawKsFP3Q31tET_3aRnQU/edit?tab=t.0#heading=h.49o3didcns1c >> >> Hope that helps. >> >> Thanks, >> Alex >> >> On Thu, Feb 19, 2026 at 3:44 PM Sander Bylemans <[email protected]> >> wrote: >> > >> > So I've done a setup of Trino with a Rest Catalog underneath (Apache >> Polaris). >> > >> > I tried using the USER session property, but for the first few >> communications between Trino and the rest catalog, the service account for >> the configured client is used. After that I just get errors and the reason >> for that is Trino constructing it's own JWT in this piece of code: >> https://github.com/trinodb/trino/blob/1b3a3e39a657642b0c4f76a5439dae859f93b4b1/plugin/trino-iceberg/src/main/java/io/trino/plugin/iceberg/catalog/rest/TrinoRestCatalog.java#L830. >> They set the issuer as the version of trino being used :mind_blown: A >> possible solution could be to correctly construct this JWT, but then the >> first few communications (for retrieving metadata) are still in name of the >> service account. Don't know if that is desirable? >> > >> > I also experimented with the exchange-token flow against a keycloak >> container, and was able to get this to work. This has been implemented by >> keycloak for about a year now. I would be up for fixing the USER session >> code in Trino, if you guys have any feedback? Particularly about the first >> few calls of communication being done by the service account? Should that >> be documented better in Trino then? >> > >> > I know the token-exchange flow is also implemented by the OAuth2Manager >> here: >> https://github.com/apache/iceberg/blob/de3125afe64fc2b171a52b6e884c72f901e3cba1/core/src/main/java/org/apache/iceberg/rest/auth/OAuth2Manager.java#L220. >> How would one use this in the Trino implementation? Because there the >> session is just converted, no new catalog seems to be created for the user. >> > >> > Thanks for your responses! >> > Sander >> > >> > >> > Op di 17 feb 2026 om 23:49 schreef Daniel Weeks <[email protected]>: >> >> >> >> Hey Sandor, >> >> >> >> I agree with Alex that you should try using the 'USER' session >> property, but this relies on token exchange (RFC 8693), which is a less >> used, if not obscure, OAuth2 extension. We've seen some inconsistencies >> across IDPs. >> >> >> >> I would emphasize that this is a really important feature for proper >> identity attribution/propagation. We're hoping to improve this type of >> support across the board, so please follow up if there are alternatives >> already in Trino or we should consider a different approach. >> >> >> >> -Dan >> >> >> >> On Tue, Feb 17, 2026 at 7:52 AM Alexandre Dutra <[email protected]> >> wrote: >> >>> >> >>> Hi Sander, >> >>> >> >>> In Apache Iceberg, the OAuth2 layer indeed only supports static tokens >> >>> or a client ID/secret pair. The only supported grant type is >> >>> client_credentials; the token exchange grant is reserved strictly for >> >>> token refreshes, not for initial authentication. >> >>> >> >>> I suspect that the Trino behavior you mentioned might be related to >> >>> Trino's "iceberg.rest-catalog.session" property, specifically when it >> >>> is set to "USER" [1]. >> >>> >> >>> In this configuration, Trino generates a JWT at catalog >> >>> initialization, and uses the token exchange grant to exchange that JWT >> >>> against another token [2]. >> >>> >> >>> However, this feature is poorly documented and has recently been >> >>> reported by users as being complicated to set up correctly [3]. The >> >>> exchange looks like a home-grown client assertion, but it's not >> >>> configurable, and I suspect it doesn't work well with some IDPs. >> >>> >> >>> For more information on the Trino specifics, your best bet might be to >> >>> reach out directly to the Trino mailing list or Slack channel. >> >>> >> >>> Hope that helps. Thanks, >> >>> Alex >> >>> >> >>> [1]: >> https://trino.io/docs/current/object-storage/metastores.html#iceberg-specific-metastores >> >>> [2]: >> https://github.com/trinodb/trino/blob/38406672349c33d4902bca7a5ebd380b6b382802/plugin/trino-iceberg/src/main/java/io/trino/plugin/iceberg/catalog/rest/TrinoRestCatalog.java#L484-L510 >> >>> [3]: https://github.com/trinodb/trino/issues/26320 >> >>> >> >>> On Mon, Feb 16, 2026 at 5:03 PM Sander Bylemans <[email protected]> >> wrote: >> >>> > >> >>> > Hey all, >> >>> > >> >>> > Currently looking into integrating Iceberg into our dataplatform >> setup. However, I'm experiencing some issues with oauth2 integration, >> specifically with Trino. I would like Trino to pass a JWT to the Iceberg >> catalog I'm using, or use the exchange-token flow, to enable true multi >> tenancy. However when I'm looking at the apache implementation of this, it >> expects a static token or a credential. The exchange flow is implemented >> but it is unclear to me how one would configure a RestSessionCatalog that >> would use that flow... >> >>> > >> >>> > Is that something that is broken? I have found several discussion / >> PR's regarding this topic: >> >>> > - https://github.com/apache/iceberg/issues/12196 >> >>> > - https://github.com/apache/iceberg/pull/12362 >> >>> > - https://lists.apache.org/thread/j49320100wtpp15dv197fdjqw2hwl91j >> >>> > >> >>> > Thanks for the info! >> >>> > >> >>> > Kind regards >> >
