bharos opened a new issue, #17600:
URL: https://github.com/apache/iceberg/issues/17600

   ### Apache Iceberg version
   
   1.10.1 (also reproduces on `main`)
   
   ### Query engine
   
   Trino
   
   ### Please describe the bug 🐞
   
   When `token-exchange-enabled` is set to `false`, a session that was created 
by token exchange refreshes itself using the parent's client credential. The 
refreshed token identifies the catalog client rather than the exchanged 
subject, so the session changes identity with no error reported.
   
   Configuration that reproduces it:
   
   * a catalog configured with `credential` and `token-exchange-enabled=false`
   * a `SessionContext` supplying a typed subject token such as 
`urn:ietf:params:oauth:token-type:jwt`, which is what Trino sends when 
`iceberg.rest-catalog.session=USER`
   
   With those credentials, `OAuth2Manager.maybeCreateChildSession` skips the 
`token` and `credential` branches and reaches `newSessionFromTokenExchange`, so 
the contextual session is minted by exchanging the user's subject token.
   
   `AuthSession.fromTokenExchange` builds that child through 
`fromTokenResponse`, which copies the parent configuration with 
`AuthConfig.builder().from(parent.config())`. That inherits both `credential` 
and `exchangeEnabled` from the catalog session.
   
   On refresh, `OAuth2Util.refreshToken` branches only on `exchangeEnabled`. 
Since the child inherited `false`, it takes the `client_credentials` path using 
the inherited credential, and the catalog client's token replaces the user's 
token in the session. Requests continue to succeed, so there is nothing to 
observe apart from the change in effective principal.
   
   For a one hour token this happens roughly 55 minutes into the session. 
`AuthSessionCache` uses `expireAfterAccess`, so the sessions that live long 
enough to refresh are exactly the ones belonging to active users.
   
   The inherited value also reaches table sessions, because 
`RESTSessionCatalog` passes the contextual session as the parent when it calls 
`AuthManager.tableSession`.
   
   There is currently no test coverage for this combination. The two tests in 
`TestRESTCatalog` that set `token-exchange-enabled=false` never create a 
session through `fromTokenExchange`: one passes empty context credentials, and 
the other passes `token`, which takes the `fromAccessToken` path instead.
   
   Suggested fix: a session created by exchanging a subject token should be 
renewed the same way, independent of the catalog level flag. #13809 added the 
flag to control how credential derived sessions refresh, and applying it to 
exchange derived sessions changes which principal the session represents.
   
   Related, and not covered by the above: `AuthSession.fromAccessToken` 
inherits the parent credential in the same way, so the bearer token path 
carries the same hazard.
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to