Hi Dmitri, Awesome - that's what I was intending as well. As I noted in the Community Sprint Notes[1] I think it would be good to introduce an AuthorizationCallContext that has a PolarisResolutionManifest as one of its attributes. I intend to populate and then pass the PolarisResolutionManifest from the Handler call sites to a preAuthorize function, that it will be able to resolve the appropriate entities and optionally RBAC needed by the PolarisAuthorizer.
I think this will also allow us to start making use of the intent-based args (like unresolved targets/secondaries) in the new SPI. I'm almost done taking a pass through an updated version of the RFC. I'll aim to send it out in the mailing list tonight so that we can discuss, reach a decision and begin making progress on the incremental items. Cheers, Sung [1] https://docs.google.com/document/d/1cUg4HnUGDN0JKMr0JWQTaKkgzSXENHZ4VMuyRfJ9oTQ/edit?tab=t.lzwxdgyu5e82#heading=h.t0xyb5l966n9 On 2026/02/04 19:45:20 Dmitri Bourlatchkov wrote: > Hi Sung, > > Apologies for the delay. > > I'm trying to move forward based on the Working Doc [1] I hope I identified > it correctly as the latest state of this AuthZ refactoring proposal :) > > In the proposed flow diagram for loadTable, I see that the Authorizer > populates the Resolution Manifest (addABC() calls) and then calls the > Resolver. The idea of the Authorizer enveloping the main resolution action > sounds good to me. However, I wonder if the Authorizer should be in control > of populating the Resolution Manifest? In that case the Authorizer will > have to know API-level specific, like what entities are involved in the > request and what the API call is expected to find. > > WDYT about Catalog Handler (or higher-level) code preparing the Resolution > Manifest, then passing it to the Authorizer, who will then invoke Resolver. > The Manifest will have to distinguish API Principals from Entities, of > course. > > The internal RBAC Authorizer will resolve all Principals and roles to their > respective Entities and Grant records (same as currently). > > The OPA Authorizer will perform "path-only" resolution only for Catalog > Entities and will use API Principals directly when invoking the PDP. > > The key point is that different Authorizer implementations will only have > to make sure that entity resolution happens, so the differences in their > code will be rather minimal (resolveAll vs. resolvePathsOnly), which will > ensure logical coherence in terms of handling API-level data if > auth-related config changes. > > I believe this will allow Polaris to maintain the holistic resolution > manifest, which is important as Dennis mentioned in the Community Sprint. > At the same time, the Authorizer should hopefully be more generic as it > will only bind to the pre-declared Manifest data and will not have to be > updated when new API endpoints are introduced. > > Essentially, I'm trying to move targets/secondaries from the Authorizer > method parameters into the Manifest object. I hope it should make the code > easier to evolve for future features. > > The Manifest object serving as input to the Authorizer could be a new class > with conversion to PolarisResolutionManifest in utility methods for maximum > backward compatibility at the Java level. This might cause more (trivial) > changes at the REST API level, but I hope the simplification of the > Authorizer contract is worth it. > > WDYT? > > Thanks, > Dmitri. > > [1] > https://docs.google.com/document/d/1-CgtpFB_N70AwQnjyHRR1QZYc4RLmz-F3GmXBAfyHrk/edit?tab=t.0#heading=h.6qbf24wpcmxa > > > On Wed, Jan 28, 2026 at 10:34 PM Sung Yun <[email protected]> wrote: > > > 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 > > > > > > > > > > > > > > > > > -- > Dmitri Bourlatchkov > Senior Staff Software Engineer, Dremio > Dremio.com > <https://www.dremio.com/?utm_medium=email&utm_source=signature&utm_term=na&utm_content=email-signature&utm_campaign=email-signature> > / > Follow Us on LinkedIn <https://www.linkedin.com/company/dremio> / Get > Started <https://www.dremio.com/get-started/> > > > The Agentic Lakehouse > The only lakehouse built for agents, managed by agents >
