Thanks for the RFC, Sung! I think it is the right direction to resolve only paths when external PDP are used. Left some comments in the doc.
Yufei On Wed, Jan 21, 2026 at 6:54 AM Sung Yun <[email protected]> wrote: > 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 >
