Thanks for resuming this discussion, Pooja! I believe we need to consider both the server-side impact and the user-side impact. I tend to think that user-side clarity is preferred in this context since the user is the actor creating/updating catalog authentication parameters in runtime.
In that regard, here's my take: * NONE - this feels like the federated catalog will not perform any authentication. However, it is not the intended mode of operation on the server-side. * ENVIRONMENT - This is too fuzzy / unclear to me (too) * PROVIDER - This signals to the user that the Provider (Polaris service owner) will perform some provider-specific authentication flow and the user is expected to know what this flow will involve (through prior interactions with the service provider). I believe this matches the proposed use case. For more clarity we could add comments to the API YAML / javadoc / doc pages. Alternative names: SERVICE_OWNER, SERVICE_PROVIDER, IMPLICIT. * UNMANAGED - this signals to the user that authentication is not managed at all and runtime behaviour is unclear. Cheers, Dmitri. On Mon, Jun 30, 2025 at 7:53 PM Pooja Nilangekar <po...@apache.org> wrote: > Hi all, > > I wanted to send out an update based on the PR discussion and get > suggestions/opinions about the same. > > The primary goal of this new authentication type which tells Polaris not > to expect any authentication tokens while federating to this external > catalog; instead use whatever information you find in the > environment/configuration files. It conveys the following: > 1. Polaris does not store or manage the authentication parameters. > 2. Polaris does not apply any authentication flow explicitly. > > Based on the discussion on the thread, here are a few names that could be > considered along with the reasoning: > 1. NONE - Explicit about the fact that no authentication > token/parameter is provided for this federated catalog. > 2. ENVIRONMENT - Expects Polaris to find the authentication mechanism > in the environment/configuration file and plumb it through while making > connections. > 3. PROVIDER - The use and the polaris server may not share an > environment, hence the authentication mechanism is based on the Polaris > server (provider). > 4. UNMANAGED - There may or may not be an authentication mechanism in > place. Even if there were one, it is not manager by Polaris. If the > environment or configuration file contains relevant authentication > information, then Polaris passes it on to the connection library. > > Please let me know if you have any suggestions/preferences about the same. > > Thanks, > Pooja > > > On 2025/06/25 21:32:39 Pooja Nilangekar wrote: > > Hi Dmitri, > > > > I agree with the "NONE" suggestion, I will send out the new version once > PR 1931 <https://github.com/apache/polaris/pull/1931> is merged because > as discussed on GH, we plan to use changes from 1931. > > > > Regarding the NULL_TYPE enum: In my experiences, it is always good to > think about backward compatibility and "forward" compatibility. The > NULL_TYPE provides a catch-all for any unrecognized value that Polaris > finds in its persistence layer that it can't interpret. Let me know what > you think. > > > > Thanks, > > Pooja > > > > On 2025/06/24 17:35:22 Dmitri Bourlatchkov wrote: > > > 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 > > > > > > > > > >
