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
> > >
> >
>
