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