Include user-defined attributes when building PolarisPrincipal from PrincipalEntity

[iprithv]

Description

Fixes #4291

PolarisPrincipal.of(PrincipalEntity, …) forwards only the entity's internal properties (e.g. client_id) and silently drops the user-defined properties supplied at principal creation. As a result, downstream consumers that read PolarisPrincipal.getProperties() never see user attributes like region=northamerica or department=finance, and policies written against them never match.

Affected paths:

• DefaultAuthenticator - constructs the PolarisPrincipal during authentication.
• AuthenticatingAugmentor - copies the principal's properties into QuarkusSecurityIdentity attributes.
• External authorizers - OPA (OpaPolarisAuthorizer) and Ranger (RangerUtils.getUserAttributes) consume these as user attributes for ABAC policy evaluation. The existing OPA test suite already builds principals like PolarisPrincipal.of("eve", Map.of("department","finance"), Set.of("auditor")), demonstrating the intended contract that the production path can't honor today.

Reproduction confirmed both ways:

On main (fix reverted):

PolarisPrincipalTest > ofPrincipalEntityExposesUserDefinedProperties()                          FAILED
PolarisPrincipalTest > ofPrincipalEntityWithTokenExposesUserDefinedProperties()                 FAILED
DefaultAuthenticatorTest > testUserDefinedPropertiesArePreservedOnAuthenticatedPrincipal()      FAILED

On this branch:

./gradlew :polaris-core:check                                                BUILD SUCCESSFUL
./gradlew :polaris-runtime-service:test --tests "...service.auth.*"          BUILD SUCCESSFUL
./gradlew :polaris-runtime-service:spotlessCheck :checkstyleMain :checkstyleTest   BUILD SUCCESSFUL

Checklist

• 🛡️ Don't disclose security issues! (contact security@apache.org)
• 🔗 Clearly explained why the changes are needed, or linked related issues: Fixes PolarisPrincipal missing user-defined attributes supplied during principal creation #4291
• 🧪 Added/updated tests with good coverage, or manually tested (and explained how)
• 💡 Added comments for complex logic
• 🧾 Updated CHANGELOG.md (if needed)
• 📚 Updated documentation in site/content/in-dev/unreleased (if needed) — N/A, internal behavior fix; no user-facing config or doc surface affected.

[dimas-b]

Thanks for your contribution, @iprithv !

Please start a discussion for this change on the dev ML. Since it affect authentication and authorization, a wide community review and consensus is advisable.

[dimas-b]

Changes LGTM 👍 pending a discussion on dev.

[dimas-b]

nit: the merger is the actor who merges or the process of merging, but it's not the result, right? 🤔

[dimas-b]

This change looks fine in isolation. However, from #4291 I guess that the real intent is to ensure the Authenticator implementations forward user-settable principal properties to PolarisPrincipal

Note: Authenticators are pluggable, so whether that happens in all environments is not 100% certain.

This is not a blocker, just a notice for awareness.

[flyrain]

cc @adutra @sneethiraj

[flyrain]

heads up: 2026-04-26 dev-list thread on PolarisPrincipal's user attributes, @adutra raised that PolarisPrincipal was intentionally decoupled from PrincipalEntity (PR #2307) and suggested exposing the persisted entity via a SecurityIdentity attribute rather than widening getProperties(). This PR goes the opposite direction.