Thanks for your example, Madhan! I believe your use case (while still hypothetical in Polaris) fits well within the current AuthZ SPI, which takes a List<AuthorizationTargetBinding> per authorization call [1][2]. Each of those entries would represent one reference from the view to a table.
I do not see an immediate need for additional SPI changes to support this use case. [1] https://github.com/apache/polaris/blob/0272f42fb3a5f6a542d9317c6c06c3b5e0dc8195/polaris-core/src/main/java/org/apache/polaris/core/auth/AuthorizationRequest.java#L58 [2] https://github.com/apache/polaris/blob/26dcf0b401bc6ee5eb6971bd4ef9edb0cfd2675b/polaris-core/src/main/java/org/apache/polaris/core/auth/PolarisAuthorizer.java#L51 Cheers, Dmitri. On Mon, Apr 20, 2026 at 4:11 PM Madhan Neethiraj <[email protected]> wrote: > > > Hi Dimitri, > > > mainly because there are no realistic use cases > Authorization to create a view from multiple tables would be a use case > for a single target (the view being created) with multiple secondaries > (tables from which the view is created), right? > > Authorizing such operations in a single call, with all entities accessed, > might be critical for authorizer implementations, for example to prevent > toxic joins involving 2 specific tables. I suggest retaining N:M > association between targets and secondaries in authorization calls. > > Thanks, > Madhan > > On 4/20/26, 12:22 PM, "Dmitri Bourlatchkov" <[email protected] <mailto: > [email protected]>> wrote: > > > Hi Yufei, > > > I appreciate having this discussion, as it will hopefully lead to more > clarity on the AuthZ SPI use cases. > > > However, at this point I find the many-to-many (N:M) association between > targets and secondaries very confusing (mainly because there are no > realistic use cases). > > > Transferring my comment from GH [1] for visibility: > > > If targets and secondaries form a non-trivial (size > 1) set, I believe a > more coherent approach would be for the caller to perform multiple > authorization checks for each <op, target, secondary> tuple as appropriate > for the use case. I believe the existing SPI covers that by > List<AuthorizationTargetBinding>. > > > > > Re: the Cartesian product of targets and secondaries - does anyone have > such a use case in practice? > > > [1] https://github.com/apache/polaris/pull/4201#issuecomment-4247944484 < > https://github.com/apache/polaris/pull/4201#issuecomment-4247944484> > > > Thanks, > Dmitri. > > > On Mon, Apr 20, 2026 at 2:25 PM Yufei Gu <[email protected] <mailto: > [email protected]>> wrote: > > > > Thanks for sharing more context. I copied the reason for introducing the > > binding here. > > > > Given current use cases, I wonder if a List-to-List relationship between > > > targets and secondary is actually correct in general. I'd imagine in > all > > > relevant cases it is a 1:1 association. When there are multiple > targets, > > > there are going to be multiple target/secondary pairs. > > > > > > I think the intuition may well be right for many current use cases, many > of > > them do look like 1:1 associations in practice. But I am not sure that > > means 1:1 should be treated as a required constraint in the model. > > > > I am hesitant to make that assumption for a few reasons. > > > > First, from a modeling perspective, the relationship is not necessarily > > 1:1. A target may depend on multiple secondaries, for example, it might > > grant multiple privileges to a role. You might argue this could be done > by > > flattening them into multiple pairs, but the flattening itself seems > > unnecessary. Conversely, multiple targets may also share the same > > secondary, such as supporting the attachment of one policy to multiple > > tables. > > > > Second, even if today's cases mostly look 1:1, keeping the API as list to > > list gives us more flexibility going forward. It avoids having to > redesign > > the API when new operations introduce more complex dependency > > relationships, and also prevents the SPI from being constrained to an > > overly narrow expressive model. > > > > To answer your questions and concerns: > > > > > Should these generally be treated as independent sets, where each > target > > and secondary is evaluated on its own without any pairing semantics? > > > > I'd prefer to treat them as independent sets because the privileges are > the > > same for either the whole target list or secondary list, using RBAC as an > > example. I think the paring semantics make more sense when we can apply > > different privileges to different pairs. > > > > > it’s not immediately clear whether we’re evaluating over pairs, or over > > the Cartesian product of targets and secondaries, or treating the two > lists > > completely independently. > > > > Maybe we just need to document the behavior here? I'm open to the ideas. > > > > > > Yufei > > > > > > On Tue, Apr 14, 2026 at 3:49 PM Sung Yun <[email protected] <mailto: > [email protected]>> wrote: > > > > > Thanks for putting this together Yufei, I think this is a very useful > > > discussion. > > > > > > For context, the notion of “binding” in the new SPI came out of the > > > earlier PR discussion [1], and at the time it felt like a reasonable > > > direction, especially since we don’t have concrete M:N or even 1:N use > > > cases today. > > > > > > One thing I’m still trying to understand is the intended semantic model > > > behind having two lists (targets and secondaries) without an explicit > > > binding. For example, for operations like ATTACH_POLICY_TO_TARGET, the > > name > > > suggests a pairwise relationship between the policy and target. With > the > > > existing shape (List<PolarisResolvedPathWrapper> targets, > > > List<PolarisResolvedPathWrapper> secondaries), it’s not immediately > clear > > > whether we’re evaluating over pairs, or over the Cartesian product of > > > targets and secondaries, or treating the two lists completely > > independently. > > > > > > I don’t have a strong preference on enforcing 1:1 vs reverting to two > > > independent lists, but I do think it would help to make the evaluation > > > semantics explicit. Otherwise different implementations may interpret > the > > > same request differently. > > > > > > Curious how you’re thinking about this: > > > - Should these generally be treated as independent sets, where each > > target > > > and secondary is evaluated on its own without any pairing semantics? > > > - Or should some operations still be interpreted as > > relationship-oriented, > > > even without explicit bindings? > > > And importantly, should these two questions be open to interpretation > per > > > each PolarisAuthorizer implementation? > > > > > > Sung > > > > > > [1] https://github.com/apache/polaris/pull/3760#discussion_r2830890135 > <https://github.com/apache/polaris/pull/3760#discussion_r2830890135> > > > > > > > > > On 2026/04/14 21:30:44 Yufei Gu wrote: > > > > Hi folks, > > > > > > > > I’d like to get feedback on a proposal to simplify the authorization > > API: > > > > https://github.com/apache/polaris/pull/4201 < > https://github.com/apache/polaris/pull/4201>. This PR removes > > > > AuthorizationTargetBinding and replaces it with a simpler model based > > on > > > > two lists: a target list and a secondary list. > > > > > > > > This avoids enforcing a 1:1 mapping in the binding class (I might > miss > > > > something regarding this enforcement, feel free to chime in), making > it > > > > more flexible to support 1:1, 1:N or even N:M relationships. For > > example, > > > > supporting the attachment of one policy to multiple tables requires > > > > duplicating bindings, which are then flattened anyway. This design > also > > > > aligns better with the existing RBAC semantics, where target > securables > > > are > > > > evaluated as one group and secondary securables as another, instead > of > > > > enforcing pairwise mappings. > > > > > > > > Open question: We may not need N:M relationships. I couldn’t come up > > > with a > > > > clear use case. > > > > > > > > Note: This interface was introduced recently and is not part of any > > > > release, so it can be removed without deprecation. > > > > > > > > Would love to hear feedback, especially on the intended semantics and > > > real > > > > use cases. > > > > > > > > Yufei > > > > > > > > > > > > > >
