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
