Hi all, Thank you Yufei and Alex for the design-doc review.
Yufei : regarding shared forwarding contract, the forwarding rules live in one helper, PolarisPrincipalAttributeNamespaces.derivedStringAttributes(), in polaris-core. OpaPolarisAuthorizer and RangerUtils both call that helper and only map the result into their request formats (OPA actor.attributes, RangerUserInfo). They do not walk PrincipalEntity and they do not put PrincipalEntity into the external PDP payload. Default if the polaris.user.* allowlist is deferred The helper forwards every string attribute already present on PolarisPrincipal under these prefixes, and nothing else: - polaris.system.* : an explicit projection of two internal facts (polaris.system.client_id and polaris.system.credential-rotation-required). Other internal properties are not derived and are not forwarded. - polaris.auth.* : only keys an authenticator has already written. This PR does not copy raw JWT claims or SecurityIdentity attributes. - polaris.user.* : every non-null PrincipalEntity user property, including empty strings. A missing key means the property was not set; it does not mean it was stored as "". A user property named client_id becomes polaris.user.client_id and cannot overwrite polaris.system.client_id. That default is intentional for this PR: it is the original local-principal ABAC case (for example department=finance). Namespace membership is the allowlist for now. A configurable polaris.user.* short-name allowlist remains a follow-up disclosure control; it should not block the augmentor or the namespaced keys. regarding ranger, Apache Ranger 2.9.0's embedded plugin builds RangerAccessRequestImpl from user name, groups, and roles only, and does not copy RangerUserInfo.attributes onto the request that policy evaluation uses. #5032 still populates the DTO from the shared helper so the authz-api contract is ready, but it does not claim that polaris.user.* can change a Ranger decision until Ranger copies those attributes through. The access-control docs and CHANGELOG state that limit. PR status: https://github.com/apache/polaris/pull/5032 now matches the SecurityIdentityAugmentor contract from the design doc. https://github.com/apache/polaris/pull/5140 has not landed; the logical keys in https://github.com/apache/polaris/pull/5032 do not depend on AttributeMap, so I rebased onto main and will adapt if https://github.com/apache/polaris/pull/5140 merges first. I would appreciate another look at https://github.com/apache/polaris/pull/5032. Thanks, Prithvi S On Sat, Sep 5, 2026 at 11:58 AM Yufei Gu <[email protected]> wrote: > Thanks for the design doc, and sorry for the delayed response. I think > the three categories make sense in general. > > polaris.<category>.* vs org.apache.polaris.{system,user,auth}.* > > The former looks good to me. The polaris. prefix is clear enough for > this contract between Polaris and its authorizer integrations. > > > What is derived vs dumped > > I’ll need to review the PR in more detail. In general, we should > explicitly define which attributes are intended for external policy > evaluation. Giving a property a namespace does not, by itself, mean it > should be forwarded. In particular, I’d like to understand what gets > forwarded by default if the polaris.user.* allowlist is deferred. > > > OPA/Ranger forward the derived namespaced string attributes, not the > PrincipalEntity object > > The proposed augmentor sounds consistent with preparing the attributes > on PolarisPrincipal before calling the authorizer. My remaining > concern is where we define which attributes may be forwarded. I think > those rules should be shared across authorizer integrations, with the > OPA/Ranger adapters handling the mapping into their respective request > formats. That would give us a consistent contract across authorizers. > > Yufei > > On Fri, Aug 28, 2026 at 4:48 AM Alexandre Dutra <[email protected]> wrote: > > > > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
