Hi Sung, I like the idea of by-passing polaris-core and only handling the new auth data where required.
I hope we can achieve that with CDI and a new request-scoped bean. The only thing is that I personally do not like the word "context" in the class names :) I tend to think that contexts are a meta-layer. Quarkus as a CDI implementation deals with contexts directly. However, Polaris code delegates that to CDI, so the data Polaris handles should be more concrete. How about AuthenticatedSubject? By analogy with the Java Security framework a Subject can be associated with multiple Principals and contain other relevant data, like authentication tokens. In its current form PolarisPrincipal has some characteristics of a Subject, but if we introduce a new class, we can move that data to achieve clearer separation of concerns, I hope. Authenticators only need to produce the AuthenticatedSubject. PolarisPrincipal can be produced from it where and when required. WDYT? Thanks, Dmitri. On Wed, Mar 18, 2026 at 10:46 PM Sung Yun <[email protected]> wrote: > Hi folks, > > I’d like to get feedback on how Polaris should carry richer > authentication-derived inputs into authorization. Today, Polaris passes a > single PolarisPrincipal into authorization, and I think PolarisPrincipal > should remain the canonical resolved identity Polaris authorizes as. At the > same time, an authorizer may need additional inputs derived during > authentication, such as subject information distinct from the acting > client, or provenance/delegation information. This feels increasingly > relevant as the Iceberg community discusses features such as > ReadRestrictions [1], where the acting client and the end user may be > distinct and policies may evolve to inspect both. > > One option is to enhance PolarisPrincipal with additional well-known fields > for concepts like subject or provenance. The alternative I am considering > is to keep PolarisPrincipal focused on canonical identity and introduce a > separate AuthorizationContext that an Authenticator can optionally produce > and a PolarisAuthorizer can optionally consume. In that model, polaris-core > would be a passthrough but would not interpret or normalize the contents, > and specific authorizer implementations such as OpaPolarisAuthorizer could > project them as needed to its policy decision point. The idea is that the > Authenticator could inspect a PolarisCredential attribute via getToken() > [2] and populate the AuthorizationContext. > > Before I push further on implementation, I’d like community feedback on > which direction seems more appropriate. Should Polaris standardize these > concepts in PolarisPrincipal, or should it stay generic and use a separate > AuthorizationContext instead? And if the separate-context direction is > preferred, would evolving the Authenticator SPI to return PolarisPrincipal > plus optional context be a reasonable next step? > > Cheers, and looking forward to your feedback on this idea. > Sung > > [1] https://lists.apache.org/thread/hvsyrmpvok4wdp6prdkyp78l98v6o95c > [2] > > https://github.com/apache/polaris/blob/f39a9a38c6b6d08b26f2f90713e54808f4062218/runtime/service/src/main/java/org/apache/polaris/service/auth/PolarisCredential.java#L64 >
