Thanks for starting this discussion, Pooja! The general idea of explicitly supporting unauthenticated connections sounds good to me.
Adding a new auth type enum value to the Management REST API spec also sounds good to me. I believe it is a backward-compatible API change (still it was correct to start a dev list discussion since it is a REST API change). However, we need to be careful with naming the new enum value as the name will propagate through many future releases. Eric proposed "NONE" in the PR, and I'd prefer this name too. Regarding specific changes in the PR, as I commented in GH, the presence of the NULL_TYPE enum value in java code looks odd to me, as it does not map to any REST API parameters. I hope we can clarify that as part of this effort (perhaps as a separate PR). WDYT? Cheers, Dmitri. On Tue, Jun 24, 2025 at 1:18 PM Pooja Nilangekar <nilangekar.po...@gmail.com> wrote: > Hi all, > > As suggested in the PR 1925 <https://github.com/apache/polaris/pull/1925>, > I wanted to initiate a discussion for the NO_AUTH support. My apologies for > not starting this discussion sooner. > > > The primary goal is to enable Polaris to federate with catalogs that permit > authentication-less access, such as the Hadoop Catalog and Hive Metastore. > This is currently a significant gap. For instance, while we've merged > support for Hadoop federation (1466) > <https://github.com/apache/polaris/pull/1466>, it's not practically usable > because Hadoop requires either auth-less or Kerberos access—neither of > which Polaris currently supports. > > I propose we tackle this in two phases: > > 1. *Phase 1: Initial Support:* Implement the core functionality to allow > auth-less connections to external catalogs. > 2. *Phase 2: Connection Type Validation (Future Enhancement):* Introduce > a mapping between connection types and their allowed authentication > methods. This would allow Polaris to validate and reject unsupported > combinations upfront, providing a cleaner user experience. > > I believe it's safe to defer Phase 2 because any incorrect connection > attempt will still be rejected by the federated catalog's server. > > Please let me know your thoughts on this approach or if you can think of > any alternative ways to support auth-less connections. > > Thanks, > Pooja >
