Enable filtering with custom roles

[lionelschiepers]

Why make this change?

This pull request is related to issue 2115 (#2115) that reports that it's not
possible to filter entities anonymously accessible when the caller is using a custom role.

What is this change?

When filtering is disallowed for a custom role because the role is not defined for that entity, it is then checked for the authenticated role the custom role inherits from. Please note that when no authenticated role is defined for an entity, it is automatically defined using the definition of the anonymous role.

How was this tested?

I've tested in our live environment.

[seantleonard]

Thank you for your contribution, I will take a look soon. But in the meantime, please add tests that exercise this scenario that you are fixing.

[JerryNixon]

@Aniruddh25 we should review this this semester.

[JerryNixon]

+1

[JerryNixon]

This behavior described is by design, not a bug.

Here’s the key:

Data API builder does not perform role inheritance. Each role must be explicitly defined per entity in the configuration.

So when you set X-MS-API-ROLE = role-a, DAB looks for an explicit role-a permission block on that entity. If it doesn’t find one, it does not automatically inherit permissions from authenticated or anonymous. That’s why the filter authorization check fails.

The apparent inconsistency—being able to read fields but not filter—comes from how GraphQL and REST differ in execution paths. In the read operation, the engine evaluates “access to entity” (which passes through because of anonymous read permissions), but filtering checks column-level permission for the active role, which is undefined for role-a. Since DAB sees role-a but can’t find corresponding metadata, it correctly blocks the filter for security reasons.