Deduplicate intent-to-resolved-path resolution across authorizers

[ZephyrYWZhou]

Summary

Follow-up to #5194 (which routed the CatalogHandler / PolarisAdminService call sites through authorize(AuthorizationState, AuthorizationRequest)), as discussed on #5170.

After #5194, each PolarisAuthorizer implementation re-derives the securables it needs from an AuthorizationRequest's intents. The mechanical mapping from an AuthorizationIntent to its resolved target/secondary paths was duplicated verbatim in two authorizers:

• PolarisAuthorizerImpl (built-in RBAC, polaris-core)
• RangerPolarisAuthorizer (Apache Ranger extension)

Both contained the same per-intent-type dispatch over the seven sealed AuthorizationIntent types plus identical private getResolvedSecurable(...) and getPathNamesWithinCatalog(...) helpers. This is correctness-sensitive and drift-prone — for example, the CATALOG branch in getResolvedSecurable had to be added to both copies. A future change to the resolution rules or a new intent type risks being applied to one authorizer and missed in the other.

This PR extracts that translation into a single AuthorizationIntentResolver in org.apache.polaris.core.auth, so both authorizers (and any future resolved-path authorizer) share one implementation.

Changes

• New AuthorizationIntentResolver (polaris-core): resolve(manifest, intent, prependRootContainer) returns a ResolvedIntent(targets, secondaries). It holds the per-intent dispatch, getResolvedSecurable (reference-catalog / top-level / path), and getPathNamesWithinCatalog.
• PolarisAuthorizerImpl and RangerPolarisAuthorizer: authorizeIntent now calls the shared resolver; the duplicated private helpers are removed. Each authorizer keeps its own operation-semantics / rooting decision (passing its own prependRootContainer), its terminal decision call (authorizeRbacOrThrow / authorizeRangerOrThrow), and its exception handling.
• Whether an operation roots its path at the root container is authorizer-specific, so that flag is passed in rather than decided by the resolver.
• OpaPolarisAuthorizer is unchanged — it maps intents to its own ResourceEntity model and does not perform resolution-manifest path resolution.

Behavior

No behavioral change. The extracted logic is identical to what each authorizer previously ran, and the resolver executes inside the same try that translates a ForbiddenException into a decision.

Testing

• New AuthorizationIntentResolverTest covering all seven intent types, the three securable-resolution branches (reference catalog / top-level / path), the rooted vs. non-rooted targetless cases, and the unresolvable-securable IllegalStateException.
• Existing suites pass unchanged: PolarisAuthorizerImplTest, the runtime-service catalog handler authz tests (IcebergCatalogHandlerAuthzTest, IcebergCatalogHandlerFineGrainedDisabledTest, PolicyCatalogHandlerAuthzTest, PolarisGenericTableCatalogHandlerAuthzTest), the Ranger unit tests + intTest, and the OPA tests.
• ./gradlew :polaris-core:check passes (Spotless + Checkstyle + tests).

Note

polaris-core compiles with --release 17, so the resolver uses an if / else if chain rather than a Java 21 pattern switch. A natural follow-up (noted in #5485) is to let each AuthorizationIntent expose its own securables, which would remove the dispatch entirely and provide compile-time exhaustiveness for future intent types.

Checklist

• 🛡️ Not a security issue
• 🔗 Fixes Deduplicate intent-to-resolved-path resolution shared by PolarisAuthorizerImpl and RangerPolarisAuthorizer #5485
• 🧪 Added AuthorizationIntentResolverTest; existing authz suites pass
• 💡 Added Javadoc for the new resolver
• 🧾 No CHANGELOG update needed (internal refactoring)
• 📚 No documentation update needed

[ZephyrYWZhou]

The CI is green, kindly tagging @flyrain and @sungwy for review as the primary driver of the authorize(state, request) migration.

[flyrain]

+1 Thanks for the refactor, @ZephyrYWZhou !

[flyrain]

nit: this line isn't necessary

[ZephyrYWZhou]

Thanks @flyrain! Good catch on this and let me address this.

[flyrain]

same here

[flyrain]

I would pass it down to the method findMissingPrivileges(), given that the structure of targets and secondaries could change in the future. Not a blocker. I'd prefer to refactor further in a followup.

[ZephyrYWZhou]

Sounds good that's a good call-out and I agree. I'll add a note on #5485 so this follow-up refactor (passing the resolved targets/secondaries down into findMissingPrivileges()) isn't missed. I'll start on it right after this PR merges.

[ZephyrYWZhou]

Thanks for the review and the insight @flyrain!

For the two nits, I've pushed a follow-up commit that addresses both. For the findMissingPrivileges() refactor, I've added a note to the tracking issue (#5485) so it won't be missed - I'll pick it up right after this PR merges.

Since the new commit dismissed your earlier approval, could you take another look when you get a chance? And once it's approved, I'd appreciate it if you could help merge it - I don't appear to have merge permission yet. Thanks again!

[flyrain]

Thanks @ZephyrYWZhou for the contribution!

[ZephyrYWZhou]

Thanks @flyrain! Will pick up the recommended refactor next.