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