Hi Jonas, While I do not see any major problem with the current state of PR 2767 (using default methods, which I mentioned in GH is a minor concern), I agree with Michael that it might be worth taking a more holistic approach to updating the authorizer API to avoid having too many method variants that implementations have to deal with and match (possibly different) behaviour expectations for each of them.
I'd like to propose using a set of java objects as input, where each of those objects represents one specific operation to be authorized. The implementation will then be free to batch those checks or execute them one by one as appropriate to the authorization technology. API sketch: List<Failures> authorize(List<Operation> ops) This will cause a code change to downstream projects that have custom authorizers, but adapting to the new API should not be too difficult, I hope, as it will operate on the same conceptual model of Polaris operations, targets, secondaries, etc. Plus it will still be in line with our code evolution guidelines [1]. WDYT? [1] https://polaris.apache.org/releases/1.1.0/evolution/ Thanks, Dmitri. On Mon, Oct 13, 2025 at 2:19 PM Michael Collado <[email protected]> wrote: > I think there's some unfortunate ambiguity in the simple addition of a List > parameter to the APIs. The List of targets variation of the API was added > to support the commitTransaction API, where the privilege needed is simply > TABLE_WRITE_DATA for all tables in the list. When we start batching > multiple targets with finer grained privileges, the operation is more > nuanced and I think we need a more precise API. For example, what if a user > has TABLE_ADD_SCHEMA privilege on one table in the commit, but not on > another? We need to ensure that we are enforcing the right privileges on > the right target so that the user could alter a schema on one table and add > a snapshot on another, but not the other way around (according to the > defined privileges). Maybe a new type is required to avoid the ambiguity? > > Mike > > On Sat, Oct 11, 2025 at 4:15 PM Sung Yun <[email protected]> wrote: > > > Hi Honah, thanks for starting this discussion. > > > > I’m really excited to see the community already thinking ahead about how > > we can evolve our authorization APIs, especially alongside the ongoing > > OpaPolarisAuthorizer work. > > > > I’m supportive of the proposed batch API addition. It seems like a > natural > > next step given the introduction of fine-grained AuthorizableOperations, > > and it will definitely help reduce the overhead for REST-based > authorizers > > like the OPA plugin. > > > > One thing we might also want to think about, either now or in a > follow-up, > > is whether the OPA request schema for the authorize (true/false) endpoint > > should also take a list of actions rather than a single one, as the > current > > RFC proposes. This would align well with the batch semantics here and > > potentially improve efficiency for multi-operation checks. Since the OPA > > plugin is still planned as a beta release, we’d have some flexibility to > > iterate and introduce breaking changes as we continue refining our policy > > authorization framework in this early phase. > > > > Thanks again for driving this! It’s great to see this kind of > > forward-looking discussion happening so early in the lifecycle of the new > > authorizer APIs. > > > > Cheers, > > Sung Yun > > > > On 2025/10/11 18:51:37 "Honah J." wrote: > > > Hi everyone, > > > > > > I'd like to start a discussion regarding an API addition in the > > > PolarisAuthorizer. > > > > > > We recently introduced fine-grained AuthorizableOperations[1], > allowing a > > > single updateTable request to trigger multiple logical operations that > > each > > > require authorization checks. Currently, PolarisAuthorizer provide: > > > > > > void authorizeOrThrow( > > > PolarisPrincipal principal, > > > PolarisBaseEntity entity, > > > PolarisAuthorizableOperation operation, > > > @Nullable List<PolarisResolvedPathWrapper> targets, > > > @Nullable List<PolarisResolvedPathWrapper> secondaries); > > > > > > which could only checks one operation each time, being inefficient when > > > many fine-grained table updates operations are combined in a single > > > updateTable request (e.g. CTAS) > > > > > > The proposal is to introduce new apis to authorize a batch of > > > AuthorizableOperations, each with the same set of targets and > > secondaries. > > > e.g. > > > > > > void authorizeOrThrow( > > > PolarisPrincipal principal, > > > Set<PolarisBaseEntity> activatedEntities, > > > Set<PolarisAuthorizableOperation> operations, > > > @Nullable List<PolarisResolvedPathWrapper> targets, > > > @Nullable List<PolarisResolvedPathWrapper> secondaries); > > > > > > This allows authorizer impl to perform a single batch check for one > > > updateTable call, which saves resources for OpaAuthorizer[2] or other > > > REST-based authorizer. > > > > > > The implementation could be found in PR#2767[3] > > > > > > I’d love to hear your thoughts. If there are (will be) any other > proposed > > > API changes for PolarisAuthorizer, we could look into combining them > for > > a > > > new version of the authorizer APIs together. > > > > > > [1] https://github.com/apache/polaris/pull/2697 > > > [2] https://github.com/apache/polaris/pull/2680 > > > [3] https://github.com/apache/polaris/pull/2767 > > > > > > Best regards, > > > Jonas > > > > > >
