Re: Discussion: Adding NO_AUTH Support for Catalog Federation

+1 to documenting "IMPLICIT" both in YAML comments (briefly, in PR 1925) and in Polaris docs (from the end user's perspective). Thanks, Dmitri. On Fri, Jul 4, 2025 at 6:37 AM Robert Stupp wrote: > AFAIU `IMPLICIT` means that Polaris does not explicitly configure any > auth related settings, but

Re: Discussion: Adding NO_AUTH Support for Catalog Federation

AFAIU `IMPLICIT` means that Polaris does not explicitly configure any auth related settings, but implementations still leverage external sources (system-properties and environment and files and container-configuration endpoints and what not). That's generally fine for me. I'd just like to hig

Re: Discussion: Adding NO_AUTH Support for Catalog Federation

+1 to IMPLICIT. Note, I would consider the Hadoop/HDFS one to actually also correctly be following the conventions we described for IMPLICIT, because the Polaris service/system environment can indeed be configured to make the Hadoop FileSystem use whatever auth it wants, even Kerberos-based access

Re: Discussion: Adding NO_AUTH Support for Catalog Federation

Thanks Dimtri and Eric, for now I will update the PR with IMPLICIT. If others send out suggestions later, I could change it. If not, we can proceed with IMPLICIT. Thanks, Pooja On 2025/07/02 22:21:50 Eric Maynard wrote: > Yeah I think IMPLICIT seems reasonable -- we could start with that and

Re: Discussion: Adding NO_AUTH Support for Catalog Federation

Yeah I think IMPLICIT seems reasonable -- we could start with that and then expand to NONE if the need arises. On Wed, Jul 2, 2025 at 2:34 PM Dmitri Bourlatchkov wrote: > I'd be fine with supporting both NONE and IMPLICIT. > > I'd expect NONE to be executed as strictly no authentication in reque

Re: Discussion: Adding NO_AUTH Support for Catalog Federation

Yeah, maybe NONE is misleading and so UNMANAGED or IMPLICIT could be better. In some cases it's conceivable that there really is no "auth" as such -- like with HADOOP -- and so I wonder if IMPLICIT over-promises a bit? --EM On Wed, Jul 2, 2025 at 1:10 PM Dmitri Bourlatchkov wrote: > How about u

Re: Discussion: Adding NO_AUTH Support for Catalog Federation

I'd be fine with supporting both NONE and IMPLICIT. I'd expect NONE to be executed as strictly no authentication in requests to external catalogs, though, even if the connector (inside Polaris) allows defaulting to environment or files, etc. If IMPLICIT is specified and the Polaris Server cannot

Re: Discussion: Adding NO_AUTH Support for Catalog Federation

How about using the enum name IMPLICIT in this case? YAML comments will briefly mention runtime env. implications. Documentation will (later) explain how it works in detail. >From my POV, "NONE" means strictly no auth. Cheers, Dmitri. On Wed, Jul 2, 2025 at 4:04 PM Eric Maynard wrote: > > W

Re: Discussion: Adding NO_AUTH Support for Catalog Federation

> When the new NONE (or any proposed alternative name) is used as the authentication type in an External Catalog, what kind of auth flow will actually happen in runtime? This question really gets to the core of what we are discussing. From my perspective in implementing HADOOP, we can interpret NO

Re: Discussion: Adding NO_AUTH Support for Catalog Federation

Hi Eric, I agree with your points. However, I am not sure now that I understand the proposed use case. When the new NONE (or any proposed alternative name) is used as the authentication type in an External Catalog, what kind of auth flow will actually happen in runtime? * Will Polaris not perfo

Re: Discussion: Adding NO_AUTH Support for Catalog Federation

> 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

Re: Discussion: Adding NO_AUTH Support for Catalog Federation

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 r

Re: Discussion: Adding NO_AUTH Support for Catalog Federation

1 & 4 both sound good to me! From the perspective of the EXTERNAL catalog connection, we're talking about a situation where the connection itself does not manage or describe any authentication mechanism. ENVIRONMENT seems simultaneously both too vague (what environment? The client's? The metastore

Re: Discussion: Adding NO_AUTH Support for Catalog Federation

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 informati

Re: Discussion: Adding NO_AUTH Support for Catalog Federation

Hi Dmitri, I agree with the "NONE" suggestion, I will send out the new version once PR 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 b

Re: Discussion: Adding NO_AUTH Support for Catalog Federation

Hi Dmitri, I agree with the "NONE" suggestion, I will send out the new version once PR 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 b

Re: Discussion: Adding NO_AUTH Support for Catalog Federation

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

Discussion: Adding NO_AUTH Support for Catalog Federation

Hi all, As suggested in the PR 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 acce