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 >
