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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
