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