Thank you both for the feedback. This gives me a lot to think about. Dmitri - that is a good point on the naming. I agree that "context" is not especially descriptive here, and we should choose a name that says more clearly what kind of data Polaris is carrying.
I also agree there is value in aligning with terms from related ecosystems where they fit. That said, I am not yet convinced that the Java Security Framework's Subject/Principal model is the right one to adopt directly here. My current thinking is that Polaris's authenticated identity model should align more closely with the actor/subject distinction that shows up in IETF and OAuth-related discussions around delegated requests. In that framing, actor and subject can each be principals, but the structure relating them is broader than a single principal. Because of that, putting multiple principals into an AuthenticatedSubject and making that the main identity container for Polaris requests feels a bit confusing to me. Alex - the more I think about it, the more I like the incremental direction of introducing actor/subject semantics without taking on a larger redesign immediately. I do think Polaris's canonical authenticated identity model would benefit from being able to represent both actor and subject. My main hesitation is whether PolarisPrincipal is the right name for that broader container. If backward compatibility is the main concern, I think we could probably live with that misnomer for now as a conscious tradeoff. I am also unsure about the word "claims" because claims sounds very token-specific, whereas what I have in mind is broader than a direct projection of token claims. The Authenticator could derive and populate a Map<String, Object> from whatever authentication inputs it has available, and the PolarisAuthorizer could consume that data without Polaris imposing a more specific structure on it. That feels like a reasonable direction to me, especially since provenance-style information does not yet seem settled enough for Polaris to standardize prematurely. So at this point I am leaning toward a model where Polaris can represent actor and subject more explicitly, while keeping any additional authenticator-produced data flexible and avoiding prematurely standardizing its shape. On the topic of PolarisPrincipal vs a new PolarisAuthenticatedIdentity - I'm looking forward to hearing more opinions so that we can settle on the right approach forward. Maybe tomorrow Auth Sync would be a good time to discuss those trade-offs :) Cheers, Sung On 2026/03/20 00:06:18 Dmitri Bourlatchkov wrote: > 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 > > >
