Hi Dmitri That makes sense to me. Also, I think a dedicated authorizer (e.g. ChainedAuthorizer) that can leverage existing authorizers and define the allowed/denied/pass policy is probably a better option.
Thanks ! Regards JB On Fri, Oct 17, 2025 at 4:07 PM Dmitri Bourlatchkov <[email protected]> wrote: > > 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 > > > > > > > > >
