WAC Role & Policy Guide
QueryPie WAC, like other QueryPie products, offers RBAC (Role-Based Access Control).
This document provides guidance on WAC roles and policies.
WAC Roles and Policies
A policy is a specification that describes how to control access to resources registered in WAC, written in YAML format.
It includes allowing or denying access to web app resources.
A role is an object that defines what a user can and cannot do.
A single role can have multiple policies assigned, and in this case, the policies are combined using an OR condition.
If multiple policies exist for the same web app and sub-path, a Deny policy takes precedence over an Allow policy.
A user can be assigned multiple roles but can only select and use one at a time.
Note
When all policies included in a role are combined, at least one Allow policy must remain. A role consisting solely of Deny policies will not grant any app permissions, making normal use impossible.
Basic Structure of WAC YAML Policy
WAC policies are written in YAML format, and their basic structure is as follows.
Category | Property | Required | Description | Valid Values |
---|---|---|---|---|
| - | REQUIRED | Version of the Written YAML Code This is a system-managed value and does not require modification. |
|
| - | REQUIRED | Type of the Written YAML Code This is a system-managed value and does not require modification. |
|
| - | REQUIRED | Detailed Rules in the Policy (Allow or Deny) |
|
|
| REQUIRED | Specify the Resources to Allow/Deny Access |
|
|
| OPTIONAL | Detailed Conditions for Applying the Rule (Only applicable for |
|
Below is the syntax for writing a QueryPie WAC Policy YAML.
spec: <effect> REQUIRED
Specifies whether the specific rule in the policy is allowed or denied. It supports spec: allow
or spec: deny
.
A policy can have at most one
allow
and onedeny
.If both
deny
andallow
are declared for the same element within the policy,deny
takes precedence.
Resources REQUIRED
Specifies the web app resources for which the allow or deny policy is to be set. It includes webApp
and urlPaths
as sub-elements.
resources
is allowed in both spec: allow
and spec: deny
webApp REQUIRED
Enter the web app resource name defined in QueryPie.
The web app must be explicitly specified, and wildcards or regular expressions are not allowed.
- webApp: "QueryPie"
(O)- webApp: "*Query*"
(X)- webApp: "QueryPie$"
(X)
Multiple web apps can be listed within a single
spec
.CODEspec: allow: resources: - webApp: "Querypie Web Admin" urlPaths: - "/general-settings/user-management" - "/database-settings/policies" - webApp: "QueryPie Customer Portal"
The web app name must meet the following conditions:
Maximum length of 120 characters
Only uppercase and lowercase alphabet letters (case-sensitive), numbers, and certain special characters (
_
,-
,(
,)
,[
,]
) are allowedSpaces are allowed
The name must start and end with an uppercase or lowercase letter or a number
Duplicates are not allowed
urlPaths OPTIONAL
Specifies the sub-paths of the specific web app resource where the policy is to be applied.
Only subpaths registered under Admin > Web App can be added.
To allow or deny access to all sub-paths within the web app, including the Base URL, follow the method below.
Do not include the urlPaths field.
Example: Allow access to the entire path of QueryPie Web Admin.
CODEspec: allow: resources: - webApp: "Querypie Web Admin"
Write as
urlPaths: []
.Example: Deny access to the entire path of QueryPie Web Admin.
CODEspec: deny: resources: - webApp: "Querypie Web Admin" urlPaths: []
When specifying a particular sub-path, the policy will be applied to the entered path and all its sub-paths.
Sub-paths are listed as a list, and multiple entries can be added.
Example: Allow access to
/general-settings/user-management
and/general-settings/user-management/*
, as well as/kubernetes-settings
and/kubernetes-settings/*
for QueryPie Web Admin.CODEspec: allow: resources: - webApp: "Querypie Web Admin" urlPaths: - "/general-settings/user-management" - "/kubernetes-settings"
Sub-paths and their detailed paths cannot be entered simultaneously.
Example: It is not allowed to enter both
/general-settings
and/general-settings/user-management
simultaneously for QueryPie Web Admin.CODEspec: allow: resources: - webApp: "Querypie Web Admin" urlPaths: - "/general-settings" - "/general-settings/user-management"
To enter a specific sub-path in urlPaths, Path Management must be enabled in the Web App details. An error will occur if an unregistered sub-path is entered.
Wildcards or regular expressions are not supported.
"/*-settings"
(X)"^/database-settings/policies/data-.*$"
(X)
If a deny policy and an allow policy overlap for the same resource (and sub-path), the deny policy takes precedence.
Conditions OPTIONAL
conditions
define the criteria to narrow the scope of the rule's application. It is possible to specify three types of conditions: urlPathTags
, userAttributes
, and ipAddresses
.
conditions
are syntactically allowed only in spec: allow
.
urlPathTags OPTIONAL
Limits the scope of resources allowed by the rule based on tags granted in the Web App's Path Management.
Tags are case-sensitive, and multiple tags can be entered.
If multiple tags with the same key are entered, they will function with an OR condition.
Example: Allow access to paths where
access: admin
oraccess: user
is granted.CODEurlPathTags: "access": "admin" "access": "user"
If multiple tags with different keys are entered, they will function with an AND condition.
Example: Allow access to paths where
access: admin
andtype: general
are both granted.CODEurlPathTags: "access": "admin" "type": "general"
It works in conjunction with
resources[].urlPaths
.If the target urlPath of the web app resource is not specified:
It allows all paths with a urlPathTag from all registered sub-paths.
Example: For the Web App "QueryPie Web Admin," allow access only to paths with the
access: admin
tag from all sub-paths registered in Path Management.CODEspec: allow: resources: - webApp: "Querypie Web Admin" urlPaths: [] conditions: urlPathTags: "access": "admin"
If the target urlPath of the web app resource is specified:
Only the paths with a urlPathTag among the specified paths are allowed.
Example: For the Web App "QueryPie Web Admin," allow access only to the paths specified in
resources[].urlPaths
that have theaccess: admin
tag assigned in Path Management.CODEspec: allow: resources: - webApp: "Querypie Web Admin" urlPaths: - "/general-settings/user-management" - "/database-settings/policies" conditions: urlPathTags: "access": "admin"
If the target urlPath of the web app resource is specified but no matching urlPathTag exists within the scope:
Since no urlPath matching the condition exists, no paths will be allowed.
userAttributes OPTIONAL
It limits the scope of users who are allowed to access resources based on the attributes of the QueryPie user.
User attributes can be viewed on the detailed page for each user in the Administrator > General > Users menu. Attributes for users added in QueryPie can be added, modified, or deleted on the detailed page, while attributes for users added via IdP synchronization can be modified in the user ledger (e.g., Okta, LDAP).
Attribute information is case-sensitive, and multiple entries can be provided.
If multiple attributes with the same key are entered, they will function with an OR condition.
Example: Allow access to users whose department is either PM or QA.
CODEuserAttributes: "department": "PM" "department": "QA"
If multiple attributes with different keys are entered, they will function with an AND condition.
Example: Allow access to users whose department is PM and title is Manager.
CODEuserAttributes: "department": "PM" "title": "Manager"
ipAddresses OPTIONAL
The IP access control conditions for the resource are defined in a list using either a single IP or CIDR format.
ipAddresses: ["10.10.0.0/24", "10.11.10.1"]
If not explicitly defined, the default is to allow all (0.0.0.0/0
).
Recommended Usage Method
Allow All + Deny Some
The most basic usage method is to create an Allow All policy and separate Deny policies for specific purposes, then assign them to a single role.
For example, the policies are configured as follows:
All Allow policy (access to all sub-links, including services and management consoles)
Service A Console Deny policy (e.g., block access to Management Console A)
Service B Console Deny policy (e.g., block access to Management Console B)
Then, policies are combined for each role:
General User Role
Policy 1 + 2 + 3 = Access only to services
Service A Admin Role
Policy 1 + 3 = Access only to service and Management Console A
Service B Admin Role
Policy 1 + 2 = Access only to service and Management Console B
This pattern can be used when leaving access open to unidentified sub-paths is not problematic.
Allow Some + Deny All
If access to unidentified sub-paths should not be allowed, the allowed paths must be explicitly specified.
All paths that require access in Path Management should be registered, and Path Tags should be appropriately assigned.
When configuring policies, conditions such as tags, user attributes, and IPs are used.
Even if the urlPaths of the controlled web app are specified in full, when tag conditions are applied, the policy will be set only for the paths registered in Path Management.
If necessary, user attributes or IPs can be used to specify the range of users allowed to access the web app.
Note
When using some allowed patterns, it is essential to configure the landing pages that are required for normal website usage as a separate policy and include them in the appropriate role.
Example: Login page, Redirect page, etc.