Different AuthorizationPolicy actions based on paths

After reviewing the AuthorizationPolicy specification it appears that it will not be possible to implement the following authorization requirements.

We have two broad URL patterns where we need to have different conditions that will either allow/deny the requests.

  1. https://FQDN[:port]/EnterpriseConfig/odata/Enterprises/{integral-enterprise-id-value}?querystring-params
  2. https://FQDN[:port]/EnterpriseConfig/odata/Enterprises/{integral-enterprise-id-value}/BusinessUnits/{integral-businessunit-id-value}?querystring-params

The integral-enterprise-id-value is not fixed but could be any integer value like 123. I think this poses a problem in defining different authorization policies that will get matched correctly.
My main issue is how should the paths be specified in the policies.

Whether “paths” specified in one policy as
paths: ["/EnterpriseConfig/odata/Enterprises/*"]
would always subsume the “paths” specified in the second policy as
paths: ["/EnterpriseConfig/odata/Enterprises/*/BusinessUnits/*"]
resulting in only the first policy to get triggered?

Basically can one have a portion of path a wildcard?


@YangminZhu could you please take a look?

Basically can one have a portion of path a wildcard?

No, "/EnterpriseConfig/odata/Enterprises/*/BusinessUnits/*" will not work as expected because currently the authz doesn’t support regex matching. “*” can be used only either in the beginning (for suffix match) or in the end (for prefix matching).

We’re working on a design to add regex support in 1.8.