Hi All, Improving this incrementally makes sense!
Re: naming, I'm not sure if people mean "AuthorizationContext" to be a class name, but if so, I'd prefer to avoid the term "context" in class names. Contexts come and go and a single request can be thought of in terms of multiple contexts. However, the meaning of data does not change when the context changes. I'd like to use concrete class names that relate to the data they hold, rather than the context in which they are used. More specifically, the data about actors and subjects to be used during AuthZ will have to be provided by AuthN code. That's already an example where the same data crosses context boundaries (Auth N/Z). I proposed some specific names in earlier emails. PolarisPrincipal can probably remain "as is" initially (to avoid introducing too many changes too quickly). Cheers, Dmitri. On Wed, Apr 15, 2026 at 1:15 AM Jean-Baptiste Onofré <[email protected]> wrote: > Hi folks, > > I agree with the incremental direction proposed. > > At a high level, I am strongly in favor of having a separate > AuthorizationContext. PolarisPrincipal represents "who is acting" and > should remain focused on that. Other details like subject and provenance > should not be included in PolarisPrincipal, as that is not its purpose. > > Regarding RFC 8693, that is a good point. As I recall, the RFC allows the > actor to be nested and chained. By introducing an AuthorizationContext to > handle extended metadata, we can keep PolarisPrincipal minimal. > > Regards, > JB > > On Wed, Apr 15, 2026 at 2:44 AM Yufei Gu <[email protected]> wrote: > > > Hi Sung, Alex and Dmitri, > > > > +1 to the incremental direction. One nuance for me is that I do not see > the > > actor and subject as separate from authenticatedMetadata. Rather, I see > > authenticatedMetadata as the full set of verified authenticator-produced > > data, with actor and subject being well-known structured parts of it that > > Polaris may choose to model explicitly. So I’d lean toward: > > > > - Keep authenticatedMetadata as the broad container for auth-derived > > inputs, ideally it aligns with the concepts in OAuth 2.0 Token > Exchange > > (RFC 8693) > > - Standardize actor and subject as first class fields or accessors > > within that model, since they seem stable and broadly useful > > > > That keeps the design flexible without losing clear semantics for the > most > > important concepts. Thanks for driving this discussion. > > > > Yufei > > > > > > On Wed, Apr 1, 2026 at 7:16 PM Dmitri Bourlatchkov <[email protected]> > > wrote: > > > > > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
