PolarisPrincipal missing user-defined attributes supplied during principal creation

[sneethiraj]

Describe the bug

When an API request is authenticated using a user principal, the internally constructed PolarisPrincipal object contains only internal attributes (such as client_id) and does not include the user-defined attributes that were supplied during principal creation.

To Reproduce

1. Create a principal using the API:
   POST /api/management/v1/principals

Include user-defined attributes, for example:
region=northamerica
department=finance

2. Use the returned client-id and client-secret to obtain an OAuth token:
   POST /api/catalog/v1/oauth/tokens

3. Use the generated OAuth token to invoke an authenticated API (for example):
   GET /api/management/v1/catalogs

4. Inspect the server-side PolarisPrincipal object created during request processing.

Actual Behavior

The PolarisPrincipal object contains only internal attributes (for example, client_id) and does not include user-defined attributes that were supplied during principal creation.

Expected Behavior

The PolarisPrincipal object should include both:

• Internal attributes (such as client_id), and
• User-defined attributes supplied during principal creation.

Additional context

Based on initial debugging, it appears that when PolarisPrincipal is created from PrincipalEntity, the implementation uses:

principalEntity.getInternalPropertiesAsMap()

This retains internal attributes but excludes user-defined properties.

Using:
principalEntity.getPropertiesAsMap() along with principalEntity.getInternalPropertiesAsMap() will preserve both internal and user-defined attributes.

System information

No response

[Vishwaspatel2401]

Hi, I'd like to work on this issue.

Planned approach: Merge getInternalPropertiesAsMap() with getPropertiesAsMap() when constructing the PolarisPrincipal so that user-defined attributes are preserved alongside internal ones.

I'll follow the contribution guidelines — branch from main, run ./gradlew format compileAll, and ensure tests pass with ./gradlew check.

[sneethiraj]

Hi @Vishwaspatel2401 , I have already submitted a PR for resolving this issue earlier - #4292 ... Please review and provide your feedback.

[dimas-b]

@sneethiraj : your analysis of current Polaris behaviour in this issue's description seems correct. However, I'm not sure the intended use case for user-define PolarisPrincipal properties is clear. How do you foresee these properties to be used in practice?

Please note that the PolarisPrincipal class is distinct from Polaris Principal Entities. The former represents any authenticated actor, whose identity may be managed outside of Polaris (e.g. in Keycloak). The latter represents only local Polaris users.

A user managed in an external IdP may not have a corresponding Polaris Principal Entity.

In general, the current design calls for (pluggable) Authenticators to populate PolarisPrincipal properties from the information available in each request (e.g. from JWT claims). Properties of internal Polaris users can certainly be propagated into PolarisPrincipal, but it does not mean that such properties are available in all cases.

[sneethiraj]

@dimas-b - Thanks for the clarification. That distinction makes sense.

My intent here is not to assume that every PolarisPrincipal will always have a corresponding Polaris Principal Entity, or that entity-defined properties will be available in all authorization flows.

The main use case I had in mind is for local Polaris users, where user-defined principal entity properties can be propagated into PolarisPrincipal and then made available to downstream authorization logic, such as Ranger policy evaluation. For example, deployments may want to define attributes such as department, region, tenant, project, or environment on a local Polaris principal and use those attributes in externalized policy decisions.

I agree that for externally managed users, such as identities coming from Keycloak or another IdP, the PolarisPrincipal properties should generally come from the authenticator, for example from JWT claims or other request context. In those cases, there may not be any corresponding Polaris Principal Entity, and this change should not imply otherwise.

So I see this as supporting one valid source of PolarisPrincipal properties for local Polaris principals, while preserving the broader design where pluggable authenticators remain responsible for populating principal properties based on the authentication mechanism being used.

[dimas-b]

@sneethiraj : ^ makes sense. Thanks for the clarification!