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