Hi Sung, This is a very useful request. I'm generally fine with the proposed idea.
When retrieving information during authorization, it would be beneficial to know if all the required data can be sourced solely from the token, or if we'll need to rely on other information sources as well. This will help us choose the best implementation approach. I want to point out that PolarisPrincipal too already exposes an opaque token. On the other hand, as you noted, the AuthorizationContext approach complicates things because it necessitates a change to the Authenticator API (which currently only returns PolarisPrincipal). Given this, I suggest we explore a simpler starting point: making the token in PolarisPrincipal (or PolarisCredential) more readily usable. This could involve adding methods like: Optional<String> subject() Map<String, Object> claims() WDYT? Thanks, Alex On Thu, Mar 19, 2026 at 3:46 AM 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
