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
