Hi folks, We had a productive discussion on authorization during the Polaris Community Sprint this week. No decisions were made during the sprint (decisions will be made here on the mailing list), but we were able to find general alignment on both an immediate next step and a longer-term direction for the PolarisAuthorizer SPI.
For those interested in the detailed discussion and diagrams, the sprint notes and working material are captured here [1]. There was alignment on an incremental, non-controversial enhancement to the PolarisAuthorizer SPI that introduces a three-phase authorization model: a pre-authorization phase to attach request-scoped state, the core authorizeOrThrow call, and a post-authorization phase to filter or transform responses (for example, for listing APIs). This approach centralizes resolution decisions inside the authorizer, preserves the existing request-scoped PolarisResolutionManifest and consistency semantics, and improves support for external PDP-backed authorizers without changing existing RBAC behavior. There was also interest in evolving the PolarisAuthorizer SPI longer-term toward intent-based authorization inputs (subject-operation-resource) and further reducing the coupling to resolved RBAC and entities, while still preserving today’s consistency and performance guarantees. Whether this can be achieved by implementing a pluggable request-scoped Resolver selected by the Persistence remains an open question. Feedback on this direction is very welcome here on the mailing list. I’ll begin updating the existing RFC to reflect the sprint outcome and to outline a staged, non-breaking plan forward. Thanks again for the great discussion. Cheers, Sung [1] https://docs.google.com/document/d/1cUg4HnUGDN0JKMr0JWQTaKkgzSXENHZ4VMuyRfJ9oTQ/edit?usp=sharing [2] https://docs.google.com/document/d/1vV4p35feUqrEuG4ciZ2ccPJTli1tR4c9YD4M_2Bi0Wc/edit?usp=sharing On 2026/01/25 04:00:48 Sung Yun wrote: > 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 > > > > > >
