Hi Sung, Good point about aligning with IETF/OAuth. I agree that it is preferable to the old Java Subject/Principal concepts in Polaris.
Re: backward compatibility for PolarisPrincipal, I believe this concern is relevant only to the Authorizer SPI, which we're changing anyway. Custom Authenticator implementations should be easy to adapt to any new classes since they produce them rather than consume them (as long as we have a way to represent all common authenticator outputs in the new classes). How about this set of classes (produced by AuthN code)... subject to discussion and renaming, of course: * AuthenticatedActor (NOT mapped to internal Principal Entities for now) * AuthenticatedSubject (mapped to the internal Pricipal Entity for Polaris native RBAC) * PolarisSecurityIdentity - a thin container for AuthN code outputs (incl. AuthenticatedActor, AuthenticatedSubject). This is just to allow single authN methods to return full authenticated data. I'm still not sure whether we'd want to use PolarisSecurityIdentity in the Authorizer SPI or individual actor/subject classes. WDYT? Cheers, Dmitri. On Mon, Mar 23, 2026 at 8:22 AM Sung Yun <[email protected]> wrote: > 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 > > > > > >
