Hi Sung, I was thinking that PolarisSecurityIdentity would be the principal inside Quarkus SecurityIdentity (or link to it in some other way). Current PolarisPrincipal will probably become obsolete.
However, your plan sounds good to me too. I guess there's no material difference, only that the data will be represented by either strongly typed classes or weakly typed "metadata". I do not have a strong preference for any of those approaches as long as we can represent all our use cases. Cheers, Dmitri. On Mon, Mar 30, 2026 at 8:26 PM Sung Yun <[email protected]> wrote: > Hi Dmitri, > > Thanks, this is helpful. I think your breakdown into AuthenticatedActor, > AuthenticatedSubject, and a thin PolarisSecurityIdentity container makes a > lot of sense, and aligns exactly with how I am conceptually thinking about > the identities. > > One thing I am trying to reason through is how cleanly that maps onto the > current Quarkus integration. Today, AuthenticatingAugmentor rebuilds a > single SecurityIdentity with one PolarisPrincipal as its principal, and > Polaris later assumes SecurityIdentity.getPrincipal() is already that > PolarisPrincipal. So even if we introduce a composite authenticated > identity, we will still need to decide what the single Quarkus principal > is, and how the broader identity is carried alongside it. > > That question is what pulls me back toward the more incremental shape Alex > suggested, to keep a single PolarisPrincipal, and to add verified, parsed > authenticator produced metadata. That seems to map more directly onto the > current constraint implied by Quarkus SecurityIdentity, while still giving > PolarisAuthorizer richer inputs. > > For the name of that additional parsed metadata, I am currently leaning > toward "authenticatedMetadata", since it seems broad enough to cover > verified authenticated data without implying token claims specifically. The > metadata could be passed from the AuthenticationRequest into the Quarkus > SecurityIdentity through its "attributes". PolarisCredentials could be > extended to support additional attributes, which will allow the > Authenticator to access the raw data and structured into the > "authenticatedMetadata" field of PolarisPrincipal, which should be > converted into authorization-ready state. > > Let me know what you think about this suggestion. > > Cheers, > Sung > > On 2026/03/23 13:59:27 Dmitri Bourlatchkov wrote: > > 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 > > > > > > > > > > > > > > >
