Hi folks, As a follow up to the many points that were brought up to prior proposals on decoupling RBAC resolution from catalog API calls, I’ve created an RFC[1] proposing a refactor of the Polaris authorization flow. The goal of this proposal is to better support external, policy-based authorizers (e.g. OpaPolarisAuthorizer) without requiring Polaris-native RBAC entities in Catalog API execution paths. The core idea is to decouple RBAC and principal resolution from handlers, move authorization and existence checks into the Authorizer, and shift the Authorizer API toward intent-level inputs (principal, operation, and path-based targets), while preserving existing behavior for PolarisAuthorizerImpl.
This proposal clarifies the longer term goals enabled by PR #3427[2], and explores how resolution requirements can be driven by the selected PolarisAuthorizer and the API being handled, rather than being hard-coded into every handler code path. It aims to keep handlers focused on execution, centralize authorization API input semantics, and align more closely with widely adopted subject–action–resource ABAC authorization input models. I’d appreciate review and feedback on the general direction and the open questions captured in the RFC. I’m also planning to walk through this proposal in the Polaris Community Sync tomorrow and would welcome discussion there as well. Thanks in advance for your time and input. Cheers, Sung [1] https://docs.google.com/document/d/1vV4p35feUqrEuG4ciZ2ccPJTli1tR4c9YD4M_2Bi0Wc/edit?pli=1&tab=t.0 [2] https://github.com/apache/polaris/pull/3427
