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