Thanks for the feedback!
> support the commitTransaction API
Totally makes sense! It might depend on how we model the fine-grained
authorizable operations for commitTransaction. But If we reuse the
fine-grained operations defined for updateTable, we may need a new wrapper
type that encapsulates each fine-grained operation along with its own
targets and secondary entities to properly handle this case. According to
the code comments, we already have a TODO there that shares the similar use
case
// TODO: The authz actually needs to detect hidden updateForStagedCreate
UpdateTableRequests
// and have some kind of per-item conditional privilege requirement if
we want to make it
// so that only the stageCreate updates need TABLE_CREATE whereas
everything else only
// needs TABLE_WRITE_PROPERTIES.
I will take this into account when updating the proposed PR/proposal
Best regards,
Jonas
On Mon, Oct 13, 2025 at 1: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
> > >
> >
>
