Hi Prithvi, I've read the updated design doc; thanks for incorporating my suggestions. I think it’s now a solid proposal.
I think we can move forward with its implementation, although I would suggest merging the outstanding AttributeMap PR first [5140]. To your questions: I think the prefix "polaris." Is fine. It’s already the prefix we use for catalog properties. I will review [5032] shortly. Thanks, Alex [5032]: https://github.com/apache/polaris/pull/5032 [5140]: https://github.com/apache/polaris/pull/5140 Le mer. 26 août 2026 à 21:25, Prithvi S <[email protected]> a écrit : > Hi Alex, > > Thank you for the design doc comments. I agree with the alternative > proposed. I updated the doc: > > > https://docs.google.com/document/d/1Zztz-owFDzZxAFgNHusd-X_7XLJx0fu8NpCOedrKm7w/edit > > On threat model: authorizers are trusted components. Namespaces cannot > hide attributes from a malicious authorizer, because AuthorizationRequest > already carries PolarisPrincipal, and PolarisPrincipal may carry > PRINCIPAL_ENTITY. The useful outcome is a clear, provenance-preserving > projection for well-behaved authorizers, not a sandbox. > > That is why I dropped PrincipalAttributeResolver. A second read path > next to PolarisPrincipal.getAttributes() would split the contract. The > single source of truth remains PolarisPrincipal. > > The contract in the doc is now: > > 1. DefaultAuthenticator (and other authenticators) continue to set > primary attributes only: PRINCIPAL_ENTITY when a persisted principal > exists, PRINCIPAL_ROLE:ALL, JWT when present. They do not invent > authorizer-facing keys. > > 2. A SecurityIdentityAugmentor runs after AuthenticatingAugmentor > (lower Quarkus priority) and derives namespaced attributes onto the > same PolarisPrincipal: > > polaris.system.* from selected PrincipalEntity internal properties > (not a dump of every internal property) > polaris.user.* from PrincipalEntity user-defined properties > polaris.auth.* only when an authenticator/IdP mapper has already > asserted them; this PR will not dump raw JWT > claims or SecurityIdentity attributes > > If PRINCIPAL_ENTITY is absent (federated / detached principals), the > augmentor derives nothing from it and leaves other attributes alone. > > 3. OPA and Ranger consume the derived string attributes. They do not > walk PrincipalEntity to build actor/user attributes, and they do not > put PrincipalEntity into the external PDP payload. PRINCIPAL_ENTITY > stays available for internal consumers such as Resolver and > AuthorizationPreConditions. > > This keeps PolarisPrincipal as the lingua franca from #5085, keeps the > entity optional, and gives authorizers a projected claim set in the > style Yufei described, without making the persistence type the > authorization SPI. > > On the remaining questions: > > 1. Namespace prefix > polaris.<category>.* . I am fine switching to > org.apache.polaris.{system,user,auth}.* if that is preferred. > > 2. What is derived vs dumped > polaris.system.* is an explicit projection of known internal facts > (for example client_id and credential-rotation-required). > polaris.user.* is the namespaced form of PrincipalEntity.properties > (the original ABAC use case, e.g. department=finance). > polaris.auth.* stays opt-in per authenticator. > > 3. Forwarding to external PDPs > OPA/Ranger forward the derived namespaced string attributes, not the > PrincipalEntity object. An optional polaris.user.* allowlist can be a > follow-up; it should not block this PR. Carrying attributes internally > and sending them to an external PDP are separate decisions, as Robert > distinguished. > > 4. PRINCIPAL_WRITE_PROPERTIES > Yes: when polaris.user.* attributes are used in ABAC, this privilege > can change authorization outcomes. I will document that in the > access-control docs. polaris.auth.* remains read-only through Polaris > APIs. > > 5. Collision > Namespaces make cross-source collisions impossible. Within > polaris.system.*, only the augmentor writes, from selected internal > properties. A user property named client_id becomes > polaris.user.client_id and cannot overwrite polaris.system.client_id. > > I will rework #5032 to this contract. I will also rebase; #5140 > (AttributeMap) may change the map > type, but the logical keys stay the same. > > Thanks, > Prithvi > > On Tue, Aug 25, 2026 at 10:00 PM Alexandre Dutra <[email protected]> > wrote: > > > Hi Prithvi, > > > > Thank you for the design doc. I left a few comments. Let me summarize > > my thoughts here: > > > > As stated in the doc, the threat model is still the same: authorizers > > remain trusted components. I think this is an important observation, > > because the proposal is not capable of hiding attributes from a > > malicious authorizer; it merely helps well-behaved authorizers. > > > > With that scope in mind, I think that the attribute renamings make > > sense as they clarify provenance and intent. > > > > But keeping in mind that PolarisPrincipal is ubiquitous and easily > > retrievable via CDI injection, I think that the > > PrincipalAttributeResolver idea may actually create some confusion: > > should an attribute be read directly from PolarisPrincipal, or from > > the shim created by PrincipalAttributeResolver? > > > > I would therefore like to offer a slightly different approach: we > > could have a SecurityAugmentor that would kick in after > > DefaultAuthenticator. It would enrich the principal attributes by > > deriving authorizer-specific keys from the "primary" ones set by the > > authenticator. > > > > For example, it would derive the > > "polaris.system.credential-rotation-required" attribute from the > > primary principal entity attribute, by calling > > > > > PrincipalEntity.getInternalPropertiesAsMap().get("CREDENTIAL_ROTATION_REQUIRED"). > > > > Then it's up to the authorizer to consume either the primary attribute > > (e.g. the entire principal entity), or a derived one (e.g. the > > credential rotation status). > > > > What do you all think of this approach? > > > > Thanks, > > Alex > > > > On Tue, Aug 18, 2026 at 1:05 AM Prithvi S <[email protected]> > > wrote: > > > > > > Hi Yufei, > > > > > > Per your suggestion, I put together a short design doc. > > > > > > https://docs.google > > > > > > .com/document/d/1Zztz-owFDzZxAFgNHusd-X_7XLJx0fu8NpCOedrKm7w/edit?usp=sharing > > > > > > Please share your thoughts. > > > > > > Thanks, > > > Prithvi S > > > > > > On Tue, Jul 28, 2026 at 12:12 AM Yufei Gu <[email protected]> > wrote: > > > > > > > Hi Prithvi, > > > > > > > > Thanks for continuing to work on this. These are all good questions. > > > > > > > > ABAC is a relatively large topic. Could we have a short design doc > > before > > > > jumping into the implementation? The design doc could cover the > > motivation, > > > > scope and questions like how an attribute is trusted across systems, > so > > > > reviewers can understand the overall direction without having to dive > > into > > > > the implementation details. > > > > > > > > Yufei > > > > > > > > On Fri, Jul 24, 2026 at 1:53 PM Prithvi S < > [email protected] > > > > > > > wrote: > > > > > > > > > Hi all, > > > > > > > > > > from my understanding of the consensus so far: > > > > > 1. PRINCIPAL_ENTITY_ATTRIBUTE_KEY should remain available for > > internal > > > > > consumers like the Resolver, but authorizers should not treat the > raw > > > > > PrincipalEntity properties as an implicit authorization contract. > > > > > 2. principal attributes that flow into ABAC decisions need explicit > > > > > provenance because an IdP assertion, a system/admin managed value, > > and > > > > free > > > > > form user metadata have different trust and mutation semantics. > > > > > 3. not all properties should automatically be forwarded to external > > > > > authorizers; we should limit which attributes can influence > > authorization > > > > > decisions. > > > > > > > > > > I shall update PR #5032 to keep PolarisPrincipal unchanged as the > > bridge, > > > > > but change how OPA/Ranger authorizers consume principal attributes: > > > > > - introduce provenance aware namespaces for attributes exposed to > > > > > authorizers, for example: > > > > > polaris.system.* - system derived or security administrator > managed > > > > > attributes > > > > > polaris.user.* - free form user defined metadata from > > PrincipalEntity > > > > > properties > > > > > polaris.auth.* - attributes asserted by the authenticator/IdP > > > > > - Authorizers receive only the namespaced attributes, not the raw > > > > > PrincipalEntity. Internal/system attributes have precedence within > > their > > > > > own namespace on collision. > > > > > - Only attributes under an explicit allowlist (or perhaps the > > > > > polaris.system.* and polaris.auth.* namespaces by default) are > > forwarded > > > > to > > > > > external authorizers. polaris.user.* attributes are included only > if > > > > > explicitly configured, so arbitrary user metadata does not leak to > or > > > > > influence external PDPs by default. > > > > > - PRINCIPAL_PROPERTIES is documented as governing user-managed > > metadata. > > > > If > > > > > the project agrees that writing user properties can affect ABAC > > > > decisions, > > > > > I will update the privilege documentation to state that it confers > > the > > > > > ability to modify user-supplied authorization attributes > > > > (polaris.user.*). > > > > > > > > > > questions I would like consensus on before implementing: > > > > > 1. are the namespace prefixes above acceptable, or do we prefer a > > > > different > > > > > convention (e.g., system., user., idp. without a polaris. prefix)? > > > > > 2. authorizer forwarding be controlled by namespace (e.g., always > > forward > > > > > polaris.system.* and polaris.auth.*, optionally forward > > polaris.user.*), > > > > or > > > > > by a flat allowlist of keys? > > > > > 3. is it intentional that PRINCAL_WRITE_PROPERTIES can modify > > attributes > > > > > used in ABAC decisions? If so, I will document it explicitly; if > > not, we > > > > > need to separate user metadata from authorization relevant > > attributes. > > > > > 4. should authenticator/IdP assertions (polaris.auth.*) be mutable > > at all > > > > > through Polaris APIs, or should they be read-only for authorizers? > > > > > > > > > > once we agree on these points, I will update the implementation and > > add > > > > > tests covering namespace handling, collision behavior, and > allowlist > > > > > configuration. > > > > > > > > > > Thanks, > > > > > Prithvi > > > > > > > > > > On Fri, Jul 24, 2026 at 9:37 PM Robert Stupp <[email protected]> > wrote: > > > > > > > > > > > Hi Alex, > > > > > > > > > > > > I agree that the Resolver may legitimately need the > > PrincipalEntity. > > > > > > > > > > > > My concern is that PRINCIPAL_ENTITY_ATTRIBUTE_KEY is declared on > > the > > > > > > public-facing PolarisPrincipal type. > > > > > > That makes the persistence entity look like part of the principal > > SPI > > > > > that > > > > > > integrations may rely on, although the stated consumer is > internal. > > > > > > > > > > > > The new AttributeMap is useful for type safety, but an > > > > > authorization-facing > > > > > > attribute set also needs provenance. > > > > > > An IdP assertion, an administrator-managed value, a > system-derived > > > > value, > > > > > > and free-form user metadata have different trust and mutation > > > > semantics. > > > > > > > > > > > > Could we keep the PrincipalEntity bridge internal and expose only > > > > > > provenance-aware attributes through the public PolarisPrincipal > > > > contract? > > > > > > > > > > > > Cheers, > > > > > > Robert > > > > > > > > > > > > On Fri, Jul 24, 2026 at 2:45 PM Alexandre Dutra < > [email protected] > > > > > > > > wrote: > > > > > > > > > > > > > Hi all, > > > > > > > > > > > > > > > I am concerned about exposing the complete PrincipalEntity > > through > > > > > > > PRINCIPAL_ENTITY_ATTRIBUTE_KEY. Even if its presence is > optional, > > > > > > > authorizer implementations can start to rely on it. > > > > > > > > > > > > > > We cannot remove that key, as some consumers legitimately need > to > > > > read > > > > > > > this attribute (the Resolver). > > > > > > > > > > > > > > Also, as Dmitri said, an authorizer should be considered a > > trusted > > > > > > > component. If we want to protect *any* authorizer from reading > > > > > > > attributes that it shouldn't, then I'm afraid we'd need a > bigger > > > > > > > refactoring: in this case, the authorizer should not be given a > > > > > > > PolarisPrincipal instance in the first place, but rather, a > > sanitized > > > > > > > view of it. > > > > > > > > > > > > > > Thanks, > > > > > > > Alex > > > > > > > > > > > > > > On Thu, Jul 23, 2026 at 5:21 PM Robert Stupp <[email protected]> > > wrote: > > > > > > > > > > > > > > > > Hi all, > > > > > > > > > > > > > > > > I agree that provenance is the central question here, and I > > think > > > > it > > > > > is > > > > > > > > important to settle the security semantics before we make > these > > > > > > > attributes > > > > > > > > available to authorizers. > > > > > > > > > > > > > > > > I am concerned about exposing the complete PrincipalEntity > > through > > > > > > > > PRINCIPAL_ENTITY_ATTRIBUTE_KEY. > > > > > > > > Even if its presence is optional, authorizer implementations > > can > > > > > start > > > > > > to > > > > > > > > rely on it. > > > > > > > > That would make the persistence entity an implicit > > authorization > > > > > > contract > > > > > > > > and would behave differently for persisted, federated, and > > > > otherwise > > > > > > > > detached principals. > > > > > > > > > > > > > > > > I think it would be safer to treat PolarisPrincipal as the > > bridge. > > > > > > > > It may be backed by a PrincipalEntity, an IdP identity, or > > > > something > > > > > > > else, > > > > > > > > but that backing should remain an implementation detail. > > > > > > > > Consumers should see only the principal attributes that were > > > > > > > intentionally > > > > > > > > made available to them. > > > > > > > > > > > > > > > > For those attributes, a name alone is not sufficient. > > > > > > > > For example, an OAuth claim named `foo` must not become > > > > > > indistinguishable > > > > > > > > from a user-defined PrincipalEntity property also named > `foo`. > > > > > > > > Resolving such a collision by precedence does not answer > > whether > > > > > either > > > > > > > > value is trusted for an authorization decision. > > > > > > > > > > > > > > > > At least the following origins have materially different > > security > > > > > > > semantics: > > > > > > > > > > > > > > > > * attributes asserted by an authenticator or IdP, > > > > > > > > * system-derived or security-administrator-managed attributes > > and > > > > > > > > * free-form user-supplied metadata. > > > > > > > > > > > > > > > > Namespaces may help distinguish these categories, but a > prefix > > by > > > > > > itself > > > > > > > > does not prove who produced a value or who was authorized to > > change > > > > > it. > > > > > > > > Whatever contract we choose should preserve enough provenance > > for > > > > > that > > > > > > > > distinction not to be lost. > > > > > > > > > > > > > > > > Mutation authority is the other side of the same issue. > > > > > > > > If a property can influence an ABAC decision, the ability to > > change > > > > > > that > > > > > > > > property is effectively authorization-administration > authority. > > > > > > > > If PRINCIPAL_WRITE_PROPERTIES grants that authority, it > should > > be > > > > an > > > > > > > > intentional, documented, and auditable part of the privilege > > rather > > > > > > than > > > > > > > an > > > > > > > > incidental consequence of forwarding principal properties. > > > > > > > > > > > > > > > > I also do not think all available properties should > > automatically > > > > > > become > > > > > > > > authorization inputs or be sent to an external authorizer. > > > > > > > > An allowlist, or an equivalent explicit declaration of > > > > > > > > authorization-relevant attributes, is useful regardless of > > whether > > > > > the > > > > > > > > values originate in an IdP or a persisted principal. > > > > > > > > It limits both which values may affect authorization and > which > > > > > > unrelated > > > > > > > > metadata is disclosed to an external PDP. > > > > > > > > > > > > > > > > This separates two independent decisions: > > > > > > > > > > > > > > > > 1. how Polaris carries optional principal information > > internally > > > > and > > > > > > > > 2. which subject attributes are allowed to affect an > > authorization > > > > > > > decision. > > > > > > > > > > > > > > > > The generic attributes from #5085 can help with the first. > > > > > > > > For the second, I think we should agree on the trust > > categories, > > > > > > mutation > > > > > > > > authority, and allowlisting semantics before #5032 > establishes > > the > > > > > > > behavior. > > > > > > > > > > > > > > > > Cheers, > > > > > > > > Robert > > > > > > > > > > > > > > > > > > > > > > > > On Thu, Jul 23, 2026 at 3:54 AM Yufei Gu < > [email protected] > > > > > > > > wrote: > > > > > > > > > > > > > > > > > Hi Prithvi, > > > > > > > > > > > > > > > > > > Thanks for working on PR #5032. Could you clarify a few > > > > questions? > > > > > > > > > > > > > > > > > > 1. Should user defined and system managed attributes use > > separate > > > > > > > > > namespaces to preserve their provenance? For example, > system > > > > > > attributes > > > > > > > > > could use names such as system.attribute1, while user > defined > > > > > > > attributes > > > > > > > > > could use names such as user.attribute1. > > > > > > > > > > > > > > > > > > 2. Is PRINCIPAL_WRITE_PROPERTIES intentionally meant to > grant > > > > > > authority > > > > > > > > > that can affect ABAC decisions? For example, if a policy > > grants > > > > > > access > > > > > > > > > based on department=finance, someone with this privilege > > could > > > > > modify > > > > > > > that > > > > > > > > > property and thereby change the principal's effective > > access. If > > > > > this > > > > > > > is > > > > > > > > > intentional, should it be documented as ABAC attribute > > management > > > > > > > > > authority? > > > > > > > > > > > > > > > > > > 3. Should all properties be passed to external authorizers, > > or > > > > only > > > > > > an > > > > > > > > > allowlist of authorization relevant attributes? Separate > > > > namespaces > > > > > > may > > > > > > > > > help address this concern. For example, we could define an > > > > > allowlist > > > > > > of > > > > > > > > > trusted system attributes under system.*, while allowing > > > > attributes > > > > > > > under > > > > > > > > > user.* to remain free form so downstream users can define > > their > > > > own > > > > > > > > > attributes. > > > > > > > > > > > > > > > > > > More generally, attribute trust is critical for ABAC > systems > > [1]. > > > > > It > > > > > > > seems > > > > > > > > > useful to distinguish trusted attributes from user-supplied > > > > > > attributes, > > > > > > > > > both for policy evaluation and for external authorizers. > > > > > > > > > > > > > > > > > > Thoughts? > > > > > > > > > > > > > > > > > > [1] > > https://nvlpubs.nist.gov/nistpubs/ir/2018/NIST.IR.8112.pdf > > > > > > > > > > > > > > > > > > Yufei > > > > > > > > > > > > > > > > > > Yufei > > > > > > > > > > > > > > > > > > > > > > > > > > > On Mon, Jul 20, 2026 at 9:28 AM Alexandre Dutra < > > > > [email protected] > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > And I forgot to add something: the scope of principal > > > > attributes > > > > > > > > > > extends beyond serving authorizers, allowing future > > components > > > > to > > > > > > > > > > potentially leverage this new entity attribute as well. > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > Alex > > > > > > > > > > > > > > > > > > > > On Mon, Jul 20, 2026 at 6:25 PM Alexandre Dutra < > > > > > [email protected] > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > Hi Yufei, > > > > > > > > > > > > > > > > > > > > > > Thank you for the PR review! I've added some comments > > > > directly > > > > > on > > > > > > > the > > > > > > > > > > > PR, but I wanted to follow up here regarding your > concern > > > > about > > > > > > > > > > > exposing the entire PrincipalEntity as an attribute. > > > > > > > > > > > > > > > > > > > > > > In my view, this approach does not introduce a > dependency > > > > > between > > > > > > > the > > > > > > > > > > > authorizers and the underlying persistence model. > First, > > we > > > > are > > > > > > > only > > > > > > > > > > > exposing an individual entity, not the entire model and > > > > schema. > > > > > > > > > > > Second, this attribute is strictly internal to the > > > > authorizers. > > > > > > > They > > > > > > > > > > > are not required to forward the entire entity to the > > remote > > > > > PDP; > > > > > > > > > > > instead, the intention is for authorizers to inspect > the > > > > > entity, > > > > > > > > > > > extract only the specific data they need, and bundle > that > > > > into > > > > > > the > > > > > > > > > > > authorization request. This design is best described > as a > > > > loose > > > > > > > > > > > coupling. > > > > > > > > > > > > > > > > > > > > > > The alternative - pre-computing specific "claims" and > > > > limiting > > > > > > > > > > > exposure to just those - means we would be deciding > what > > is > > > > > > > relevant > > > > > > > > > > > on behalf of the authorizers. Ultimately, that decision > > > > should > > > > > > > belong > > > > > > > > > > > to the authorizers themselves. > > > > > > > > > > > > > > > > > > > > > > WDYT? > > > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > Alex > > > > > > > > > > > > > > > > > > > > > > On Sat, Jul 18, 2026 at 2:21 AM Yufei Gu < > > > > [email protected] > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > Hi Alex, > > > > > > > > > > > > > > > > > > > > > > > > Thanks for putting this together. I like the > direction > > of > > > > > > keeping > > > > > > > > > > > > PolarisPrincipal as the common identity abstraction. > > > > > > > > > > > > > > > > > > > > > > > > One thing I'm concerning about is exposing the entire > > > > > > > PrincipalEntity > > > > > > > > > > as an > > > > > > > > > > > > attribute. Do we really want authorizers to depend on > > our > > > > > > > internal > > > > > > > > > > > > persistence model? The tighter coupling between the > > > > > > authorization > > > > > > > > > > logic and > > > > > > > > > > > > the metastore schema is concerning. It also makes it > > easier > > > > > for > > > > > > > > > > authorizers > > > > > > > > > > > > to rely on fields that weren't intended to be part of > > the > > > > > > > > > authorization > > > > > > > > > > > > contract. > > > > > > > > > > > > > > > > > > > > > > > > It might be cleaner to project the information we > want > > to > > > > > > expose > > > > > > > into > > > > > > > > > > > > attributes instead. We could do something similar to > > how > > > > most > > > > > > > IdPs > > > > > > > > > > expose > > > > > > > > > > > > claims rather than their internal user objects. For > > > > example, > > > > > > > Keycloak > > > > > > > > > > uses > > > > > > > > > > > > protocol mappers to select user attributes and map > them > > > > into > > > > > > > token > > > > > > > > > > claims > > > > > > > > > > > > [1]. > > > > > > > > > > > > > > > > > > > > > > > > 1. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://www.keycloak.org/admin-api/protocol-mappers?utm_source=chatgpt.com > > > > > > > > > > > > > > > > > > > > > > > > Yufei > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Fri, Jul 17, 2026 at 11:53 AM Dmitri Bourlatchkov > < > > > > > > > > > [email protected] > > > > > > > > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > Hi Alex, > > > > > > > > > > > > > > > > > > > > > > > > > > +1 to this design. I think it allows future > > extensions to > > > > > be > > > > > > > > > > introduced > > > > > > > > > > > > > without disrupting existing code. > > > > > > > > > > > > > > > > > > > > > > > > > > I also approved it in GH. > > > > > > > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > > > > Dmitri. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Fri, Jul 17, 2026 at 9:35 AM Alexandre Dutra < > > > > > > > [email protected] > > > > > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi again, > > > > > > > > > > > > > > > > > > > > > > > > > > > > In order to validate my own suggestion I went > > ahead and > > > > > > > created > > > > > > > > > the > > > > > > > > > > > > > > following PR: > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://github.com/apache/polaris/pull/5085 > > > > > > > > > > > > > > > > > > > > > > > > > > > > Compared to what I had in mind initially, the > main > > > > > > > difference is > > > > > > > > > > that > > > > > > > > > > > > > > PolarisPrincipal must stay the "lingua franca" > for > > > > > > everything > > > > > > > > > > related > > > > > > > > > > > > > > to authn and authz, since it's the only component > > > > > declared > > > > > > in > > > > > > > > > > > > > > polaris-core. So in the final design, > > PolarisPrincipal > > > > > > simply > > > > > > > > > > exposes > > > > > > > > > > > > > > a generic attribute map, which may contain the > > > > > > > PrincipalEntity as > > > > > > > > > > an > > > > > > > > > > > > > > attribute. The SecurityIdentity exposes the same > > > > > attributes > > > > > > > for > > > > > > > > > > > > > > completeness. > > > > > > > > > > > > > > > > > > > > > > > > > > > > Let me know your thoughts on this design. > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > > > Alex > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Fri, Jul 17, 2026 at 11:13 AM Alexandre Dutra > < > > > > > > > > > > [email protected]> > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Prithvi, Dmitri, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I was OOO last week and I'm catching up with > this > > > > > > > discussion, > > > > > > > > > so > > > > > > > > > > my > > > > > > > > > > > > > > > apologies for the delay. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > @ Prithvi : your description of the approach is > > spot > > > > on > > > > > > and > > > > > > > > > > > > > > > corresponds to what I had in mind. To your > > questions: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 1. Is the attribute key naming convention > above > > > > > > > acceptable? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Yes. Quarkus tends to use simple attribute keys > > like > > > > > > > > > > "tenant-id", but > > > > > > > > > > > > > > > I think Polaris should use namespaced > attributes. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 2. For `DefaultAuthenticator` [...] should it > > also > > > > > add > > > > > > > the > > > > > > > > > > > > > > `PrincipalEntity` to `SecurityIdentity` > attributes > > at > > > > > that > > > > > > > point > > > > > > > > > > [...] ? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Yes it should, and that's indeed the annoying > > part. > > > > The > > > > > > > current > > > > > > > > > > > > > > > authenticate method signature is: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > PolarisPrincipal > authenticate(PolarisCredential > > > > > > > credentials) > > > > > > > > > > throws > > > > > > > > > > > > > > > NotAuthorizedException, > ServiceFailureException; > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > This signature is too rigid and does not easily > > allow > > > > > > > > > attaching a > > > > > > > > > > > > > > > PrincipalEntity. We'd need to change it to > > something > > > > > > like: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > SecurityIdentity > authenticate(SecurityIdentity > > > > > > > credentials) > > > > > > > > > > throws > > > > > > > > > > > > > > > AuthenticationFailedException; > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > This would allow the authenticator impl to: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > - read all the credentials presented by the > > client > > > > (and > > > > > > not > > > > > > > > > only > > > > > > > > > > > > > > > PolarisCredential) > > > > > > > > > > > > > > > - attach the PrincipalEntity to the > > SecurityIdentity, > > > > > if > > > > > > it > > > > > > > > > > exists > > > > > > > > > > > > > > > - allow easy authentication of federated > > principals, > > > > > as a > > > > > > > > > future > > > > > > > > > > > > > > possibility > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 3. For the OPA test suite [...] should I > update > > > > those > > > > > > > tests > > > > > > > > > to > > > > > > > > > > > > > instead > > > > > > > > > > > > > > set the `PrincipalEntity` attribute on > > > > `SecurityIdentity` > > > > > > > [...] ? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Yes, that would be the right thing to do. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 4. Should I add a helper method somewhere > > [...] to > > > > > > > > > encapsulate > > > > > > > > > > the > > > > > > > > > > > > > > attribute lookup [...] ? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I like that idea, +1. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > My problem with [5032] is that I'm not sure > it's > > > > going > > > > > in > > > > > > > the > > > > > > > > > > right > > > > > > > > > > > > > > > direction, given the above. There are two > methods > > > > today > > > > > > in > > > > > > > > > > > > > > > PolarisPrincipal that I think should be > removed: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Map<String, String> getProperties(); > > > > > > > > > > > > > > > Optional<String> getToken(); > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > As they could easily be replaced by injecting > > > > > > > SecurityIdentity > > > > > > > > > > (also, > > > > > > > > > > > > > > > getToken is currently unused). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > What do you think of this plan? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > > > > Alex > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > [5032]: > > https://github.com/apache/polaris/pull/5032 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Fri, Jul 17, 2026 at 12:44 AM Prithvi S < > > > > > > > > > > > > > [email protected]> > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi JB, Dmitri, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Got it, sure. Thanks for trying to reopen > > #4405. I > > > > > > > updated it > > > > > > > > > > in > > > > > > > > > > > > > > > > https://github.com/apache/polaris/pull/5032. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > > > Prithvi > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Thu, Jul 16, 2026 at 4:42 PM Jean-Baptiste > > > > Onofré > > > > > < > > > > > > > > > > > > > [email protected]> > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Yup, I suggest to re-open with a fresh PR. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > > > > > > > > > JB > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Thu, Jul 16, 2026 at 5:10 AM Dmitri > > > > > Bourlatchkov < > > > > > > > > > > > > > > [email protected]> > > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Prithvi, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Sorry, but GH refuses to reopen PR 4405 > > because > > > > > its > > > > > > > > > branch > > > > > > > > > > has > > > > > > > > > > > > > been > > > > > > > > > > > > > > > > > > force-pushed or something like that. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > In the interest of making progress, let's > > not > > > > > worry > > > > > > > about > > > > > > > > > > it. > > > > > > > > > > > > > > Please open > > > > > > > > > > > > > > > > > > fresh PRs for all changes that got stuck > in > > > > > > > erroneously > > > > > > > > > > closed > > > > > > > > > > > > > PRs > > > > > > > > > > > > > > and > > > > > > > > > > > > > > > > > > cross-reference them. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > > > > > > > > > Dmitri. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Fri, Jul 10, 2026 at 7:25 PM Prithvi > S < > > > > > > > > > > > > > > [email protected]> > > > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Dmitri, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Ah, okay, got it. I closed > > > > > > > > > > > > > > https://github.com/apache/polaris/pull/5032 > > > > > > > > > > > > > > > > > . > > > > > > > > > > > > > > > > > > > Can > > > > > > > > > > > > > > > > > > > you try to reopen > > > > > > > > > > https://github.com/apache/polaris/pull/4405 > > > > > > > > > > > > > > now? > > > > > > > > > > > > > > > > > Thanks! > > > > > > > > > > > > > > > > > > > Also this access privilege is > confusing. > > This > > > > > > must > > > > > > > be a > > > > > > > > > > project > > > > > > > > > > > > > > > > > setting? > > > > > > > > > > > > > > > > > > > Can we have access to reopen it if it > > closes > > > > > due > > > > > > to > > > > > > > > > stale > > > > > > > > > > > > > > activity? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > > > > > > Prithvi S > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Sat, Jul 11, 2026 at 4:30 AM Dmitri > > > > > > > Bourlatchkov < > > > > > > > > > > > > > > [email protected]> > > > > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Prithvi, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I cannot reopen [4405] either as you > > > > > apparently > > > > > > > have > > > > > > > > > > another > > > > > > > > > > > > > PR > > > > > > > > > > > > > > > > > using the > > > > > > > > > > > > > > > > > > > > same branch, i.e. [5032] :) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Since [5032] is fresh, I suggest > > closing it > > > > > and > > > > > > > > > > restoring the > > > > > > > > > > > > > > branch > > > > > > > > > > > > > > > > > to > > > > > > > > > > > > > > > > > > > the > > > > > > > > > > > > > > > > > > > > PolarisPrincipal commits. Then the PR > > > > should > > > > > be > > > > > > > > > > possible to > > > > > > > > > > > > > > re-open, > > > > > > > > > > > > > > > > > I > > > > > > > > > > > > > > > > > > > > hope. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > [4405] > > > > > > > https://github.com/apache/polaris/pull/4405 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > [5032] > > > > > > > https://github.com/apache/polaris/pull/5032 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > > > > > > > > > > > Dmitri. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Fri, Jul 10, 2026 at 6:54 PM > > Prithvi S < > > > > > > > > > > > > > > > > > [email protected]> > > > > > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Dmitri, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks for checking this. That > makes > > > > > sense, I > > > > > > > will > > > > > > > > > > change > > > > > > > > > > > > > it > > > > > > > > > > > > > > to > > > > > > > > > > > > > > > > > make > > > > > > > > > > > > > > > > > > > > > the auth layer forward to > > > > PolarisPrincipal > > > > > > > > > > properties. > > > > > > > > > > > > > > > > > > > > > Can you help reopen the PR? I don't > > seem > > > > to > > > > > > > have > > > > > > > > > > access to > > > > > > > > > > > > > > reopen. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > > > > > > > > > > Prithvi S > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Fri, Jul 10, 2026 at 6:25 PM > > Dmitri > > > > > > > > > Bourlatchkov < > > > > > > > > > > > > > > > > > [email protected]> > > > > > > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Prithvi, Alex, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Re: SecurityIdentity, it is a > > Quarkus > > > > > class > > > > > > > and > > > > > > > > > it > > > > > > > > > > is > > > > > > > > > > > > > > certainly > > > > > > > > > > > > > > > > > fine > > > > > > > > > > > > > > > > > > > to > > > > > > > > > > > > > > > > > > > > > use > > > > > > > > > > > > > > > > > > > > > > it in infrastructure code that > > deals > > > > with > > > > > > > > > technical > > > > > > > > > > > > > > > > > authentication > > > > > > > > > > > > > > > > > > > > > aspects > > > > > > > > > > > > > > > > > > > > > > (e.g. in > > SecurityIdentityAugmentor). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > However, I'd like to avoid > > depending on > > > > > > > > > > SecurityIdentity > > > > > > > > > > > > > in > > > > > > > > > > > > > > > > > proper > > > > > > > > > > > > > > > > > > > > > Polaris > > > > > > > > > > > > > > > > > > > > > > code like the OPA Authorizer. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I tend to think that the > > authentication > > > > > > layer > > > > > > > > > > should > > > > > > > > > > > > > > forward > > > > > > > > > > > > > > > > > whatever > > > > > > > > > > > > > > > > > > > > > user > > > > > > > > > > > > > > > > > > > > > > information is necessary to > > > > > > PolarisPrincipal > > > > > > > as > > > > > > > > > > optional > > > > > > > > > > > > > > > > > attributes. > > > > > > > > > > > > > > > > > > > > OPA > > > > > > > > > > > > > > > > > > > > > > and other authorizers will then > > have > > > > the > > > > > > > > > > opportunity to > > > > > > > > > > > > > > consider > > > > > > > > > > > > > > > > > > > those > > > > > > > > > > > > > > > > > > > > > > attributes. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > This will decouple Polaris > > authorizers > > > > > both > > > > > > > from > > > > > > > > > > > > > > Quarkus-specific > > > > > > > > > > > > > > > > > > > code > > > > > > > > > > > > > > > > > > > > > and > > > > > > > > > > > > > > > > > > > > > > from PrincipalEntity. So the > > > > authorizers > > > > > > > should > > > > > > > > > be > > > > > > > > > > usable > > > > > > > > > > > > > > with > > > > > > > > > > > > > > > > > any > > > > > > > > > > > > > > > > > > > IdP > > > > > > > > > > > > > > > > > > > > > > (internal or external) and not be > > > > > affected > > > > > > by > > > > > > > > > > Quarkus > > > > > > > > > > > > > > upgrades. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > WDYT? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > > > > > > > > > > > Dmitri. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Tue, Jul 7, 2026 at 5:15 AM > > Prithvi > > > > S > > > > > < > > > > > > > > > > > > > > > > > > > [email protected]> > > > > > > > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Alex, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thank you, I understand now > that > > the > > > > > > > decoupling > > > > > > > > > > in PR > > > > > > > > > > > > > > #2307 was > > > > > > > > > > > > > > > > > > > > > > intentional > > > > > > > > > > > > > > > > > > > > > > > and that `PolarisPrincipal` > > should > > > > not > > > > > > > assume a > > > > > > > > > > backing > > > > > > > > > > > > > > > > > > > > > `PrincipalEntity` > > > > > > > > > > > > > > > > > > > > > > > exists. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I'll **close PR #4405** and > work > > on > > > > the > > > > > > > > > > > > > > `SecurityIdentity` > > > > > > > > > > > > > > > > > > > attribute > > > > > > > > > > > > > > > > > > > > > > > approach instead. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > My understanding of the > approach: > > > > > > > > > > > > > > > > > > > > > > > 1. In > `AuthenticatingAugmentor`, > > > > when a > > > > > > > > > > > > > > `PrincipalEntity` is > > > > > > > > > > > > > > > > > > > > available, > > > > > > > > > > > > > > > > > > > > > > add > > > > > > > > > > > > > > > > > > > > > > > it as an optional attribute to > > > > > > > > > > > > > `QuarkusSecurityIdentity` > > > > > > > > > > > > > > (e.g., > > > > > > > > > > > > > > > > > > > > under a > > > > > > > > > > > > > > > > > > > > > > key > > > > > > > > > > > > > > > > > > > > > > > like > > > > > > > `"org.apache.polaris.principal_entity"`) > > > > > > > > > > > > > > > > > > > > > > > 2. Update > `OpaPolarisAuthorizer` > > and > > > > > > > > > > > > > > > > > > > `RangerUtils.getUserAttributes` > > > > > > > > > > > > > > > > > > > > to > > > > > > > > > > > > > > > > > > > > > > > check for this attribute in the > > > > > > > > > > `SecurityIdentity` and > > > > > > > > > > > > > > extract > > > > > > > > > > > > > > > > > > > > > > user-defined > > > > > > > > > > > > > > > > > > > > > > > properties from the > > `PrincipalEntity` > > > > > > when > > > > > > > > > > present > > > > > > > > > > > > > > > > > > > > > > > 3. `PolarisPrincipal` remains > > > > > unchanged, > > > > > > no > > > > > > > > > > property > > > > > > > > > > > > > > merging > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Also can you help with below: > > > > > > > > > > > > > > > > > > > > > > > 1. Is the attribute key naming > > > > > convention > > > > > > > above > > > > > > > > > > > > > > acceptable, or > > > > > > > > > > > > > > > > > is > > > > > > > > > > > > > > > > > > > > there > > > > > > > > > > > > > > > > > > > > > > an > > > > > > > > > > > > > > > > > > > > > > > existing pattern I should > follow > > for > > > > > > > > > > `SecurityIdentity` > > > > > > > > > > > > > > > > > attribute > > > > > > > > > > > > > > > > > > > > keys > > > > > > > > > > > > > > > > > > > > > in > > > > > > > > > > > > > > > > > > > > > > > Polaris? > > > > > > > > > > > > > > > > > > > > > > > 2. For `DefaultAuthenticator` > > when it > > > > > > > > > constructs > > > > > > > > > > > > > > > > > `PolarisPrincipal` > > > > > > > > > > > > > > > > > > > > > from > > > > > > > > > > > > > > > > > > > > > > > `PrincipalEntity`, should it > > also add > > > > > the > > > > > > > > > > > > > > `PrincipalEntity` to > > > > > > > > > > > > > > > > > > > > > > > `SecurityIdentity` attributes > at > > that > > > > > > > point, or > > > > > > > > > > should > > > > > > > > > > > > > > this > > > > > > > > > > > > > > > > > only > > > > > > > > > > > > > > > > > > > > happen > > > > > > > > > > > > > > > > > > > > > > in > > > > > > > > > > > > > > > > > > > > > > > `AuthenticatingAugmentor`? > > > > > > > > > > > > > > > > > > > > > > > 3. For the OPA test suite that > > > > > currently > > > > > > > builds > > > > > > > > > > > > > > principals with > > > > > > > > > > > > > > > > > > > > > > > user-defined properties should > I > > > > update > > > > > > > those > > > > > > > > > > tests to > > > > > > > > > > > > > > instead > > > > > > > > > > > > > > > > > set > > > > > > > > > > > > > > > > > > > > the > > > > > > > > > > > > > > > > > > > > > > > `PrincipalEntity` attribute on > > > > > > > > > > `SecurityIdentity` and > > > > > > > > > > > > > > verify > > > > > > > > > > > > > > > > > that > > > > > > > > > > > > > > > > > > > > > > > `OpaPolarisAuthorizer` picks up > > the > > > > > > > properties > > > > > > > > > > from > > > > > > > > > > > > > > there? > > > > > > > > > > > > > > > > > > > > > > > 4. Should I add a helper method > > > > > somewhere > > > > > > > > > (e.g., > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > `PolarisPrincipal.getPrincipalEntityFromIdentity(SecurityIdentity)`) > > > > > > > > > > > > > > > > > > > > to > > > > > > > > > > > > > > > > > > > > > > > encapsulate the attribute > > lookup, or > > > > is > > > > > > it > > > > > > > > > > better to > > > > > > > > > > > > > > keep the > > > > > > > > > > > > > > > > > > > lookup > > > > > > > > > > > > > > > > > > > > > > inline > > > > > > > > > > > > > > > > > > > > > > > in each consumer? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Let me know if I'm on the right > > track > > > > > and > > > > > > > I'll > > > > > > > > > > proceed > > > > > > > > > > > > > > with > > > > > > > > > > > > > > > > > the new > > > > > > > > > > > > > > > > > > > > PR. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > > > > > > > > > > > > Prithvi > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Mon, Jun 15, 2026 at 8:52 PM > > > > > Alexandre > > > > > > > > > Dutra < > > > > > > > > > > > > > > > > > [email protected] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Prithvi, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks for starting this > > thread! > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > My stance on this matter > > remains > > > > > > > unchanged: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > - PolarisPrincipal and > > > > > PrincipalEntity > > > > > > > should > > > > > > > > > > be > > > > > > > > > > > > > > decoupled. > > > > > > > > > > > > > > > > > We > > > > > > > > > > > > > > > > > > > must > > > > > > > > > > > > > > > > > > > > > > > > avoid the assumption that a > > > > > > > PrincipalEntity > > > > > > > > > > exists > > > > > > > > > > > > > for > > > > > > > > > > > > > > every > > > > > > > > > > > > > > > > > > > > > > > > principal, especially in > cases > > > > > > involving > > > > > > > > > > federated or > > > > > > > > > > > > > > > > > detached > > > > > > > > > > > > > > > > > > > > > > > > principals. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > - In my view, the most > > effective > > > > > method > > > > > > > for > > > > > > > > > > > > > > propagating the > > > > > > > > > > > > > > > > > > > > > > > > PrincipalEntity is to treat > it > > as > > > > an > > > > > > > > > *optional* > > > > > > > > > > > > > > attribute > > > > > > > > > > > > > > > > > within > > > > > > > > > > > > > > > > > > > > the > > > > > > > > > > > > > > > > > > > > > > > > SecurityIdentity. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > how should we ensure > > user-defined > > > > > > > > > properties > > > > > > > > > > are > > > > > > > > > > > > > > reliably > > > > > > > > > > > > > > > > > > > > forwarded > > > > > > > > > > > > > > > > > > > > > > > > across all authenticator > > > > > > > implementations, not > > > > > > > > > > just > > > > > > > > > > > > > > > > > > > > > > > `DefaultAuthenticator`? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Such a guarantee is likely > > > > > > unattainable. > > > > > > > > > > Because > > > > > > > > > > > > > > > > > authenticators > > > > > > > > > > > > > > > > > > > are > > > > > > > > > > > > > > > > > > > > > > > > designed to be pluggable, > > custom > > > > > > > > > > implementations may > > > > > > > > > > > > > be > > > > > > > > > > > > > > > > > > > completely > > > > > > > > > > > > > > > > > > > > > > > > unaware of PrincipalEntity. > > > > > > > Consequently, any > > > > > > > > > > logic > > > > > > > > > > > > > > that > > > > > > > > > > > > > > > > > requires > > > > > > > > > > > > > > > > > > > > the > > > > > > > > > > > > > > > > > > > > > > > > presence of a PrincipalEntity > > > > within > > > > > > the > > > > > > > > > > > > > > SecurityIdentity is > > > > > > > > > > > > > > > > > > > > > > > > fundamentally flawed and > > should be > > > > > > > refactored > > > > > > > > > > to > > > > > > > > > > > > > > remove that > > > > > > > > > > > > > > > > > > > > > > > > requirement. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > What is your use case for > > > > retrieving > > > > > > the > > > > > > > > > > > > > > PrincipalEntity's > > > > > > > > > > > > > > > > > > > > attributes > > > > > > > > > > > > > > > > > > > > > > > > at runtime? Is it for > auditing > > > > > purposes > > > > > > > or > > > > > > > > > are > > > > > > > > > > you > > > > > > > > > > > > > > building > > > > > > > > > > > > > > > > > some > > > > > > > > > > > > > > > > > > > > > > > > business logic on top of it? > > If the > > > > > > > former, > > > > > > > > > it > > > > > > > > > > should > > > > > > > > > > > > > > be > > > > > > > > > > > > > > > > > fine to > > > > > > > > > > > > > > > > > > > > just > > > > > > > > > > > > > > > > > > > > > > > > log "null" if the entity is > not > > > > > present > > > > > > > (and > > > > > > > > > > you can > > > > > > > > > > > > > > control > > > > > > > > > > > > > > > > > the > > > > > > > > > > > > > > > > > > > > > > > > authenticator in use to make > > sure > > > > it > > > > > > > will be > > > > > > > > > > > > > present); > > > > > > > > > > > > > > if the > > > > > > > > > > > > > > > > > > > > latter, > > > > > > > > > > > > > > > > > > > > > > > > that would mean that your > > logic is > > > > > now > > > > > > > > > > dependent on a > > > > > > > > > > > > > > > > > specific > > > > > > > > > > > > > > > > > > > > > > > > authenticator's ability to > > produce > > > > a > > > > > > > > > > PrincipalEntity, > > > > > > > > > > > > > > which > > > > > > > > > > > > > > > > > isn't > > > > > > > > > > > > > > > > > > > > > > > > great. In that case it may be > > safer > > > > > to > > > > > > > fetch > > > > > > > > > > the > > > > > > > > > > > > > > > > > PrincipalEntity > > > > > > > > > > > > > > > > > > > > from > > > > > > > > > > > > > > > > > > > > > > > > the metastore explicitly. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > > > > > > > > > > > > > Alex > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Sun, Jun 14, 2026 at > 8:56 PM > > > > > Prithvi > > > > > > > S < > > > > > > > > > > > > > > > > > > > > > [email protected] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi all, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I'm opening this thread as > > > > > suggested > > > > > > by > > > > > > > > > > @dimas-b in > > > > > > > > > > > > > > the > > > > > > > > > > > > > > > > > review > > > > > > > > > > > > > > > > > > > of > > > > > > > > > > > > > > > > > > > > > PR > > > > > > > > > > > > > > > > > > > > > > > > #4405 ( > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://github.com/apache/polaris/pull/4405 > > > > > > > > > > ), > > > > > > > > > > > > > which > > > > > > > > > > > > > > > > > touches > > > > > > > > > > > > > > > > > > > > > > > > authentication > > > > > > > > > > > > > > > > > > > > > > > > > and authorization behavior. > > > > > @flyrain > > > > > > > also > > > > > > > > > > flagged a > > > > > > > > > > > > > > prior > > > > > > > > > > > > > > > > > > > > dev-list > > > > > > > > > > > > > > > > > > > > > > > thread > > > > > > > > > > > > > > > > > > > > > > > > > from April 2026 on the same > > > > topic, > > > > > > so I > > > > > > > > > want > > > > > > > > > > to > > > > > > > > > > > > > make > > > > > > > > > > > > > > sure > > > > > > > > > > > > > > > > > that > > > > > > > > > > > > > > > > > > > > > > > discussion > > > > > > > > > > > > > > > > > > > > > > > > > is continued here. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Background > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > `PolarisPrincipal.of(PrincipalEntity, > > > > > > > …)` > > > > > > > > > > currently > > > > > > > > > > > > > > > > > forwards > > > > > > > > > > > > > > > > > > > only > > > > > > > > > > > > > > > > > > > > > the > > > > > > > > > > > > > > > > > > > > > > > > > entity's *internal* > > properties > > > > > (e.g. > > > > > > > > > > `client_id`) > > > > > > > > > > > > > and > > > > > > > > > > > > > > > > > silently > > > > > > > > > > > > > > > > > > > > > drops > > > > > > > > > > > > > > > > > > > > > > > any > > > > > > > > > > > > > > > > > > > > > > > > > *user-defined* properties > > set at > > > > > > > principal > > > > > > > > > > creation > > > > > > > > > > > > > > time > > > > > > > > > > > > > > > > > (e.g. > > > > > > > > > > > > > > > > > > > > > > > > > `region=northamerica`, > > > > > > > > > `department=finance`). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > As a result, downstream > > consumers > > > > > of > > > > > > > > > > > > > > > > > > > > > > > `PolarisPrincipal.getProperties()` > > > > > > > > > > > > > > > > > > > > > > > > > never see user attributes, > > and > > > > ABAC > > > > > > > > > policies > > > > > > > > > > > > > written > > > > > > > > > > > > > > > > > against > > > > > > > > > > > > > > > > > > > them > > > > > > > > > > > > > > > > > > > > > > never > > > > > > > > > > > > > > > > > > > > > > > > > match. This affects: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > - `DefaultAuthenticator` : > > > > > constructs > > > > > > > > > > > > > > `PolarisPrincipal` > > > > > > > > > > > > > > > > > during > > > > > > > > > > > > > > > > > > > > > > > > > authentication > > > > > > > > > > > > > > > > > > > > > > > > > - > `AuthenticatingAugmentor` : > > > > > copies > > > > > > > > > > principal > > > > > > > > > > > > > > properties > > > > > > > > > > > > > > > > > into > > > > > > > > > > > > > > > > > > > > > > > > > `QuarkusSecurityIdentity` > > > > > attributes > > > > > > > > > > > > > > > > > > > > > > > > > - External authorizers : > > > > > > > > > > `OpaPolarisAuthorizer` and > > > > > > > > > > > > > > > > > > > > > > > > > > > `RangerUtils.getUserAttributes` > > > > > > consume > > > > > > > > > > these as > > > > > > > > > > > > > user > > > > > > > > > > > > > > > > > > > attributes > > > > > > > > > > > > > > > > > > > > > for > > > > > > > > > > > > > > > > > > > > > > > > policy > > > > > > > > > > > > > > > > > > > > > > > > > evaluation > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The existing OPA test suite > > > > already > > > > > > > builds > > > > > > > > > > > > > > principals with > > > > > > > > > > > > > > > > > > > > > > user-defined > > > > > > > > > > > > > > > > > > > > > > > > > properties (e.g. > > > > > > `department=finance`), > > > > > > > > > > > > > > demonstrating the > > > > > > > > > > > > > > > > > > > > intended > > > > > > > > > > > > > > > > > > > > > > > > > contract, which the > > production > > > > code > > > > > > > path > > > > > > > > > > cannot > > > > > > > > > > > > > > currently > > > > > > > > > > > > > > > > > > > honor. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > What PR #4405 does > > > > > > > > > > > > > > > > > > > > > > > > > The fix adds a > > > > > > > `mergeEntityProperties()` > > > > > > > > > > helper > > > > > > > > > > > > > that > > > > > > > > > > > > > > > > > combines > > > > > > > > > > > > > > > > > > > the > > > > > > > > > > > > > > > > > > > > > > > > > `PrincipalEntity`'s > > user-defined > > > > > and > > > > > > > > > internal > > > > > > > > > > > > > > properties, > > > > > > > > > > > > > > > > > and > > > > > > > > > > > > > > > > > > > > uses > > > > > > > > > > > > > > > > > > > > > > the > > > > > > > > > > > > > > > > > > > > > > > > > merged map when > constructing > > > > > > > > > > `PolarisPrincipal` via > > > > > > > > > > > > > > the > > > > > > > > > > > > > > > > > > > > > > > > > `of(PrincipalEntity, …)` > > > > overload. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The design question raised: > > > > > > > > > > > > > > > > > > > > > > > > > @flyrain pointed out that > in > > > > April > > > > > > > 2026, > > > > > > > > > > @adutra > > > > > > > > > > > > > > raised a > > > > > > > > > > > > > > > > > > > concern > > > > > > > > > > > > > > > > > > > > > > that > > > > > > > > > > > > > > > > > > > > > > > > > `PolarisPrincipal` was > > > > > > *intentionally* > > > > > > > > > > decoupled > > > > > > > > > > > > > from > > > > > > > > > > > > > > > > > > > > > > `PrincipalEntity` > > > > > > > > > > > > > > > > > > > > > > > > > (see PR #2307), and > > suggested an > > > > > > > > > alternative > > > > > > > > > > > > > > approach: > > > > > > > > > > > > > > > > > expose > > > > > > > > > > > > > > > > > > > the > > > > > > > > > > > > > > > > > > > > > > > > persisted > > > > > > > > > > > > > > > > > > > > > > > > > `PrincipalEntity` as a > > > > > > > `SecurityIdentity` > > > > > > > > > > attribute > > > > > > > > > > > > > > rather > > > > > > > > > > > > > > > > > than > > > > > > > > > > > > > > > > > > > > > > > widening > > > > > > > > > > > > > > > > > > > > > > > > > `getProperties()`. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > PR #4405 takes the opposite > > > > > direction > > > > > > > by > > > > > > > > > > merging > > > > > > > > > > > > > > properties > > > > > > > > > > > > > > > > > > > > > directly > > > > > > > > > > > > > > > > > > > > > > > into > > > > > > > > > > > > > > > > > > > > > > > > > `PolarisPrincipal`. I want > to > > > > > > > understand > > > > > > > > > > whether > > > > > > > > > > > > > > this is > > > > > > > > > > > > > > > > > > > > acceptable > > > > > > > > > > > > > > > > > > > > > > or > > > > > > > > > > > > > > > > > > > > > > > > > whether the community > > prefers the > > > > > > > > > > > > > `SecurityIdentity` > > > > > > > > > > > > > > > > > attribute > > > > > > > > > > > > > > > > > > > > > > approach > > > > > > > > > > > > > > > > > > > > > > > > > instead. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > questions I have, > > > > > > > > > > > > > > > > > > > > > > > > > 1. Was the decoupling of > > > > > > > `PolarisPrincipal` > > > > > > > > > > from > > > > > > > > > > > > > > > > > > > > `PrincipalEntity` > > > > > > > > > > > > > > > > > > > > > > (PR > > > > > > > > > > > > > > > > > > > > > > > > > #2307) intended to prevent > > > > exactly > > > > > > this > > > > > > > > > kind > > > > > > > > > > of > > > > > > > > > > > > > > property > > > > > > > > > > > > > > > > > merge? > > > > > > > > > > > > > > > > > > > > If > > > > > > > > > > > > > > > > > > > > > > so, > > > > > > > > > > > > > > > > > > > > > > > > what > > > > > > > > > > > > > > > > > > > > > > > > > is the preferred mechanism > > for > > > > > > exposing > > > > > > > > > > > > > user-defined > > > > > > > > > > > > > > > > > principal > > > > > > > > > > > > > > > > > > > > > > > attributes > > > > > > > > > > > > > > > > > > > > > > > > > to downstream auth > consumers? > > > > > > > > > > > > > > > > > > > > > > > > > 2. Is the > `SecurityIdentity` > > > > > > attribute > > > > > > > > > > approach > > > > > > > > > > > > > > (exposing > > > > > > > > > > > > > > > > > > > > > > > > `PrincipalEntity` > > > > > > > > > > > > > > > > > > > > > > > > > directly) the right path, > or > > are > > > > > > there > > > > > > > > > other > > > > > > > > > > > > > > concerns with > > > > > > > > > > > > > > > > > > > that? > > > > > > > > > > > > > > > > > > > > > > > > > 3. Since authenticators are > > > > > > pluggable, > > > > > > > how > > > > > > > > > > should > > > > > > > > > > > > > we > > > > > > > > > > > > > > ensure > > > > > > > > > > > > > > > > > > > > > > > user-defined > > > > > > > > > > > > > > > > > > > > > > > > > properties are reliably > > forwarded > > > > > > > across > > > > > > > > > all > > > > > > > > > > > > > > authenticator > > > > > > > > > > > > > > > > > > > > > > > > implementations, > > > > > > > > > > > > > > > > > > > > > > > > > not just > > `DefaultAuthenticator`? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Happy to revise the > approach > > > > based > > > > > on > > > > > > > > > > community > > > > > > > > > > > > > > feedback. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > > > > > > > > > > > > Prithvi S > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
