Hi folks, Thank you all so much for your interest and reviews.
Dmitri - I absolutely agree that seeing the end-to-end solution would be a good way to get clarity on the direction we want to take our authorization/resolution subsystem. PR #3427 will be one of many PRs to achieve the target state, and I'm happy to put in a bit more work towards getting community agreement before we merge it in. I was hoping that the RFC and the PR would be a good starting artifacts to help facilitate the discussion. To recap, during the 1/22 Polaris community sync, there seemed to be openness to stepping back and reviewing the current roles, responsibilities, and contracts between the authorization and resolution components in Polaris, including the possibility of a larger refactor to better support external PDP–backed authorizers (e.g. OpaPolarisAuthorizer) without requiring internal Polaris principal or role resolution. There was also interest in continuing this discussion during the Polaris Community Sprint on 1/27. Based on JB’s suggestion that some upfront preparation would be helpful to keep the sprint discussion focused and productive, I put together a Google Doc[1] that proposes a structured way to discuss this problem in a hybrid (zoom/in-person) meeting. The document is intended as a discussion aid rather than a proposal, and I'd be happy to help facilitate the discussion by walking through it. The goal will be to not to make decisions during the sprint, but to explore and compare proposals that can then be shared with the broader Polaris community via the dev mailing list. I'm very much looking forward to continuing the discussion with everyone! Cheers, Sung [1] https://docs.google.com/document/d/1-CgtpFB_N70AwQnjyHRR1QZYc4RLmz-F3GmXBAfyHrk/edit?usp=sharing On 2026/01/22 08:39:21 Jean-Baptiste Onofré wrote: > Hi Sung, > > I agree with the path-centric approach. However, I am still a bit confused > by the required changes on the Authorizer, as they seem somewhat > disconnected to me. > > I will review the RFC to get a better understanding. > > Regards, > JB > > On Wed, Jan 21, 2026 at 3:54 PM 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 > > >
