Datawiza Rules Configuration Guide

About 3 min

This section will talk about basic rule configuration and provide some use cases with examples.

Rule Configuration

First of all, let's introduce some basic concepts.

Resource Path Matching

resource path We offer two matching types for path configuration: Prefix and Exact. Prefix stands for "matching by prefix", meaning the request URI starting with the input string will be matched.

For example: If a resource path /site/ is configured with Prefix, then request URIs that look like /site/, /site/page1/index, or /site/index will get matched, but /api/site/ or /site-b/index will not. Similarly, if a resource path /site is configured with Prefix, then request URIs that look like /site123, /site456/page1, or /site/page2/index will get matched.

And Exact stands for "exact match", meaning only the request URI that equals to the input string will be matched.

For example: If a resource path /site/ is defined as Exact. Only request URI /site/ will be matched. Anything else like /site/index, /site-b/, or /site will not be matched.

Priority

Priority is used to set rule execution order. The lower number indicates higher priority. For example: As the above image shown, we configure two rules with the same URI /priority. The priority of the rule named priority 10 is 10 and the rule decision is Deny. The priority of the rule named priority 20 is 20 and the rule decision is Allow. The result is that the request accessing /priority* will hit the rule named priority 10, which means the request will be denied.

Rule Type

We offer three kinds of rule types: Protected: the request will be authenticated first, then will be allowed or denied based on the conditions defined in the rule. Note that any URI not hitting the rules needs authentication by default.

Not Protected: the request to the resource will pass through Access Proxy to upstream servers without being authenticated.

Authorization, the request will be authorized by the authorizer.

Example Config

Case 1

Goal: Suppose you want to get the following paths authenticated, and the others bypassing the Access Proxy.

/api-1/page/*
/api-n/page/*
/microservice-1/app/*
/microservice-n/app/*

You need to configure two rules: one is Protected Rule and the other is Not Protected Rule.

Rule #1 (Authentication-required paths): This is the Protected Rule that requires the request with the prefix URIs listed in the following screenshot to be authenticated. The priority of this rule 10: rule case

Rule #2 (Passthru paths): This is the Not Protected Rule that would not require any authentication for all paths. The priority of this rule is 1000. Since Rule #1 has higher priority than Rule #2, requests with URIs hitting Rule #1 will need authentication and the others will not need authentication. rule case

Summary: After saving the above 2 rules, you will see a summary as follows: rule case

Similarly, if you want to have request to certain path passing through directly, and all other paths need authentication, then you can change the Rule Type of the Rule #1 to Not Protected. And the Rule #2 is not needed because, by default, a URI not hitting any rule needs authentication.

Case 2

Goal: Suppose you want the resource path /api/ to be inaccessible, but /api/* be accessible.

You need to configure two rules: one for /api/, the other for /api/*.

Rule #1 For path /api/, we need to set the Priority higher. And set the Resource Path to Exact, Rule Decision to Deny. rule case

Rule #2 For path /api/*, we need to set the Priority lower. And set the Resource Path to Prefix, Rule Decision to Allow. rule case

Case 3

Goal: Suppose you want the resource path /hr* can only be accessed by group hr with the GET method during working hours(9 a.m. to 5 p.m. on weekdays). Add condition as follow: rule case And set default action to Deny:

Case 4

Goal: Restrict Certain Tenants When Using Microsoft Entra ID Multi-Tenant Add a new attribute, which is tid, in the Profile tab of the application. Then, add a mapping from tid to tid in the Mappings tab: rule case Last, add rules: Add a rule that only allows users in tenant A, for example, xxxxxxxx-xxxx-xxxx-xxxx-000000000001 and tenant B, xxxxxxxx-xxxx-xxxx-xxxx-000000000002: Change the default rule to deny which will deny users in any other tenant: