Hi JB, I've been thinking about authZ orchestration and I realized that in order for chains to be usable the outcome of Authorizer calls will probably have to change to a three state value (Allowed, Denied, Pass). Currently the Authorizer either passes the check quietly or throws an exception.
Re: the impl. I'd be more comfortable with a new authorizer type that is explicitly selected by the user and configured to chain other authorizers. For example, a user may select "default" or "opa", or "chained" (with 1: "opa" (not required), 2: "default" (required)). I think this approach should be flexible enough and allow admin users to retain good control over authorization decisions. The key point is that the admin user configures the chain rather than relying on runtime / classpath to implicitly form the chain. What do you think? Cheers, Dmitri. On Wed, Oct 15, 2025 at 2:44 PM Jean-Baptiste Onofré <[email protected]> wrote: > Hi Dmitri > > That’s a good point. > > My proposal is coming more with OPA and fallback to other mechanism. For me > the realm in Polaris is an “authorizer container” (like realm in jaas with > login modules). Today in a realm, if is authorized don’t pass, we can’t > fallback to another one. > Another possible approach is to use an Authorizer delegating to others. > > Just wondering. > > Regards > JB > > Le mer. 15 oct. 2025 à 19:02, Dmitri Bourlatchkov <[email protected]> a > écrit : > > > Hi JB, > > > > I am not against having Authorizer chains in Polaris in principle, but I > do > > not see that as a necessary feature ATM. > > > > Chaining LoginModules in JAAS is necessary to allow pluggable login > > behaviour, however, in Polaris Authentication is already selectable / > > configurable per realm. I think having a similar model for Authorizers > > would be more intuitive for users. > > > > I guess one authorizer per realm is sufficient. Different realms can have > > different authorizers. In each realm the Authorizer can be configured to > > work with the corresponding Authenticator. > > > > Cheers, > > Dmitri. > > > > On Wed, Oct 15, 2025 at 3:05 AM Jean-Baptiste Onofré <[email protected]> > > wrote: > > > > > Hi folks, > > > > > > I would like to propose a new way to deal with PolarisAuthorizers. > > > > > > Today, the PolairsAuthorizerImpl is using one PolarisAuthorizer > > > (injected with CDI using the corresponding qualifier). > > > It works great for our current use cases. However, we see new > > > Authorizers joining the party (a new one for OPA, etc). > > > It means that we will have the need to "combine" several authorizers > > > (for instance going to OPA, and falling back to the "default" > > > Authorizer). > > > To deal with that, I propose to adopt a paradigm similar to the > > > LoginModules in JAAS, with the notion of required or optional. > > > > > > PolarisAuthorizers can contain a set of Authorizers (order matters), > > > each Authorizer (by configuration) will have "required" or "optional" > > > keywords. > > > Required means that the isAuthorized() HAS to pass or it fails (and > > > the following Authorizers are not used in the chain). > > > Optional means that if isAuthorized() passes then it's good enough and > > > the chain stops here, if it fails, the next Authorizer in the chain is > > > used, etc. > > > > > > If the community thinks it's interesting, I can draft a proposal > > > document, create an issue and a draft PR. > > > > > > Thoughts ? > > > > > > Thanks, > > > Regards > > > JB > > > > > >
