> I believe we need to consider both the server-side impact and user-side impact > NONE [...] feels like the federated catalog will not perform any authentication.
I see multiple users here. There's an admin configuring the Polaris service, there's a person creating the EXTERNAL catalog, and there's an end user querying the catalog. >From the end user's perspective, the authentication type doesn't matter at all because the end user just authenticates with Polaris. To them, the name of the auth type really shouldn't matter. >From the admin's perspective, the authentication type refers to how Polaris will authenticate itself to the external catalog -- the admin is concerned with which auth types are "enabled" for a given realm in Polaris, as we see in PR#1931. The admin needs to recognize which auth types are inherently unsafe or what impact the different auth types might have on the service. Finally, and most importantly, there is the user creating the EXTERNAL catalog [connection]. This user is creating a connection to a catalog and is specifying an authentication type at that point in time. This is where NONE / UNMANAGED is most clear -- it hopefully tells this user that Polaris will not do anything to authenticate itself to the catalog being connected to. For all of these users, I'm not sure there is a shared definition of what a PROVIDER means. To me, it sounds like Polaris will use some external PROVIDER of authentication, which in many cases really may not exist. --EM On Wed, Jul 2, 2025 at 11:26 AM Dmitri Bourlatchkov <di...@apache.org> wrote: > 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 > > > > > > > > > > > > > > >
