Very slick. Thanks for the extra flexibility. Looking forward to the PR Mike
On Wed, Apr 16, 2025 at 12:54 PM Alex Dutra <alex.du...@dremio.com.invalid> wrote: > Hi again, > > As a follow-up, I was able today to make it possible for each realm to be > dynamically authenticated by either the internal token endpoint, or any of > the configured OIDC tenants. > > So, I take back my previous statement about the impossibility to mix > internal and external authentication for the same realm. > > The following kind of realm configurations should therefore be possible: > > - Realm A: internal auth only, with RSA key pair > - Realm B: internal or external auth; internal with shared secret, > external with IDP X > - Realm C: external auth only, with IDP X or Y > > I hope that this extra flexibility will make it easier for you to adapt to > Quarkus OIDC. > > Thanks, > > Alex > Alex > > On Wed, Apr 16, 2025 at 3:26 PM Alex Dutra <alex.du...@dremio.com> wrote: > > > Hi Mike, > > > > My current work makes it possible to define if the authentication is > > *internal* (using the internal token endpoint + custom auth mechanism) or > > *external* (using an external IDP + Quarkus OIDC extension). > > > > Furthermore, the authentication can be defined on a global level, *then > > overridden on a per-realm basis*. Combined with the fact that Quarkus > > OIDC also supports multi-tenancy, my work should make it possible to > > handle, for example, the following configuration: > > > > - Realm A: internal auth, RSA key pair M > > - Realm B: internal auth, RSA key pair N > > - Realm C: internal auth, Symmetric key, secret S > > - Realm D: external auth, IDP X > > - Realm E: external auth, IDP X or Y > > > > However: > > > > I want to make sure that it would still be > >> possible to use different authn mechanisms for different requests in the > >> same realm. > > > > > > *It won't be possible to mix internal and external authentication for the > > same realm.* I think this would complicate things a lot and I don't see a > > good reason to do this. > > > > That said, for realms that would opt for external auth, it will be > > possible to use more than one IDP per realm, since Quarkus OIDC is > > multi-tenant and has the ability to select tenants based on various > > criteria, such as the token issuer URL. This is what Realm E illustrates > in > > my example above. > > > > Is that OK for you? > > > > Thanks, > > > > Alex > > > > > > On Tue, Apr 15, 2025 at 10:32 PM Michael Collado <collado.m...@gmail.com > > > > wrote: > > > >> Hi Alex > >> > >> I'm going through the PR now and I think the Quarkus security approach > >> seems fine. I was actually thinking of working on this previously > myself. > >> > >> > This shall be done by implementing a new HttpAuthenticationMechanism > >> that will pick the right authentication mechanism (internal token broker > >> vs > >> external IdP) based on the runtime configuration. > >> > >> Regarding this statement, I want to make sure that it would still be > >> possible to use different authn mechanisms for different requests in the > >> same realm. I also recently started picking up some of the work from the > >> federated auth proposal and something we need to ensure is that we can > >> support both external identity providers as well as the internal token > >> broker. > >> > >> Mike > >> > >> > >> On Tue, Apr 15, 2025 at 6:52 AM Jean-Baptiste Onofré <j...@nanthrax.net> > >> wrote: > >> > >> > Hi Alex, > >> > > >> > It sounds like a good plan :) > >> > > >> > Thanks ! > >> > Regards > >> > JB > >> > > >> > On Mon, Apr 14, 2025 at 10:50 PM Alex Dutra > >> > <alex.du...@dremio.com.invalid> wrote: > >> > > > >> > > Hi all, > >> > > > >> > > A recently-reported bug [1] uncovered some serious issues with the > >> JAX-RS > >> > > authentication filters. Fixing this bug requires replacing the > >> > incriminated > >> > > filters with proper Quarkus Security mechanisms. > >> > > > >> > > In parallel to that, support for external identity providers has > been > >> > > requested many times, see [2], [3] and [4]. We know however that > this > >> > > feature can only be delivered by implementing similar mechanisms. > >> > > > >> > > There might be an opportunity here to kill two birds with one > stone. I > >> > > would like therefore to make the following proposal: > >> > > > >> > > 1. In a first PR, *replace the current authentication filters* by > >> > > Quarkus Security. This PR should be transparent to users and > should > >> > not > >> > > change the current behavior of Polaris, nor its configuration > >> options. > >> > > 2. In a second PR, *implement support for external identity > >> > providers*. > >> > > This shall be done by implementing a new > >> HttpAuthenticationMechanism > >> > > that will pick the right authentication mechanism (internal token > >> > broker vs > >> > > external IdP) based on the runtime configuration. > >> > > > >> > > If you agree with this proposal, I'm happy to start working on the > >> first > >> > > PR. > >> > > > >> > > Thanks, > >> > > > >> > > Alex > >> > > > >> > > [1]: https://github.com/apache/polaris/issues/1345 > >> > > [2]: https://github.com/apache/polaris/issues/336 > >> > > [3]: https://github.com/apache/polaris/issues/976 > >> > > [4]: https://github.com/apache/polaris/issues/1327 > >> > > >> > > >
