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