varpa89 commented on PR #12655: URL: https://github.com/apache/iceberg/pull/12655#issuecomment-2765646665
> It's not a custom vs built-in problem, it's a shared vs non-shared problem. > > Consider this hypothetical example: let's suppose we have a custom manager that authenticates using OAuth, Okta and the Authorization Code flow. This means that the user will be redirected to their browser for login before being able to use the catalog. If this is happening in a Spark or Trino session, chances are that Spark/Trino will need a token, and the catalog will also need a token. Without the ability to share the same auth manager, the user would be asked to login twice: once for Spark/Trino, once for the RESTCatalog. @adutra you're absolutely correct I can explain a real example. Trino already [has](https://trino.io/docs/current/security/oauth2.html#) OAuth functionality. We can configure it to ask users to authenticate via browser and create a session. We also have an Iceberg Rest Catalog configured in Trino. The Rest Catalog requires authentication because we want to authorize users for different actions with this catalog. And it would be nice to reuse a session created by Trino (not by RestSessionCatalog itself) and send that token to the Rest Catalog and avoid token exchange operations. Looks like in such situations it would be beneficial to have an ability to manage a session from outside of the iceberg library -- 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: issues-unsubscr...@iceberg.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: issues-unsubscr...@iceberg.apache.org For additional commands, e-mail: issues-h...@iceberg.apache.org
