Hi, Thanks to all of you who reviewed PR 1! Here is PR 2, introducing support for external IDPs:
https://github.com/apache/polaris/pull/1397 I included detailed explanations and examples in the PR. Thanks, Alex On Thu, Apr 17, 2025 at 12:42 AM Michael Collado <collado.m...@gmail.com> wrote: > 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 > > >> > > > >> > > > > > >
