[10.2.8~] WAC RBAC Guide

QueryPie WAC provides Role-Based Access Control (RBAC).

This document provides information on WAC Roles and Policies applicable to versions 10.2.8 and later.

WAC Roles and Policies

• A Policy is a specification, written in YAML format, that describes how to control access to resources registered in WAC.

  • It includes allowing or blocking access to web app resources.

• A Role is an object that defines what a user can and cannot do.

  • Multiple policies can be assigned to a single Role; in this case, the policies are combined with an OR condition.

  • If multiple policies exist for the same Web App and sub-path, Deny policies take precedence over Allow policies.

• Users can be assigned multiple Roles but can only select and use one at a time.

Warning

When all policies included in a Role are consolidated, at least one Allow policy must remain.

A Role consisting only of Deny policies does not grant any app permissions and therefore cannot be used normally.

Basic Structure of WAC YAML Policies

WAC policies are written in YAML format, and their basic structure is as follows:

YAML Document Example

apiVersion: webApp.rbac.querypie.com/v1
kind: WacPolicy

spec:
  allow:
    resources:
      - webApp: "Querypie Web Admin"
        urlPathTags:              
          access: "admin"
      - webApp: "QueryPie Customer Portal"
        urlPaths: ["*"]          
    conditions:
      userAttributes:
        department: "White"
      ipAddresses: 
        - "10.10.0.0/24"
        - "10.10.1.79"
  deny:
    resources:
      - webApp: "Querypie Web Admin"
        urlPaths: 
          - "/general-settings/user-management/roles"

YAML 명세

아래에서 정책 작성에 필요한 QueryPie WAC Policy YAML 문법을 안내합니다.

spec: <effect> REQUIRED

Specifies whether the specific rules of the policy are to allow or deny access. Supports spec: allow or spec: deny.

1. A single policy can contain at most one allow block and one deny block.

2. If deny and allow are declared for the same element within a policy, deny takes precedence.

Resources REQUIRED

Specifies the web app resources for which to set allow or block policies. It must have webApp as a sub-property, and either urlPaths or urlPathTags.

resources is permitted in both spec: allow and spec: deny.

However, specifying resources via urlPathTags is only supported in spec: allow.

webApp REQUIRED

Enter the name of the web app resource defined in QueryPie.

1. The web app must be explicitly specified; wildcards or regular expressions are not allowed

   • - webApp: "QueryPie" (O)

   • - webApp: "*Query*" (X)

   • - webApp: "QueryPie$" (X)

2. Multiple web apps can be listed within a single spec.

   CODE

   spec:
     allow:
       resources:
         - webApp: "Querypie Web Admin"
           urlPaths: 
             - "/general-settings/user-management"
             - "/database-settings/policies"
         - webApp: "QueryPie Customer Portal"
           urlPathTags: 
             access: "admin"

3. The web app name must satisfy the following conditions:

   • Maximum 120 characters.

   • Only uppercase/lowercase alphabets (case-sensitive), numbers, and some special characters (_, -, (, ), [, ]) are allowed.

   • Spaces are allowed.

   • Must start and end with an uppercase/lowercase alphabet or a number.

   • Cannot be duplicated.

• To operate access control policies at the sub-path level of a web app, you can enter either urlPaths or urlPathTags under webApp. It is not possible to specify both urlPaths and urlPathTags simultaneously for the same web app within a single policy.

urlPaths OPTIONAL

Specifies the sub-paths of a particular web app resource to which the policy applies.

1. Only sub-paths registered for the Web App (typically managed under Admin > Web Apps) can be listed.

2. To allow or deny all sub-paths of a web app, including the Base URL, write urlPaths: ["*"].

   • e.g., Deny access to all paths of Querypie Web Admin:

     CODE

     spec:
       deny:
         resources:
           - webApp: "Querypie Web Admin"
             urlPaths: ["*"]

3. When a sub-path is entered, the policy applies to that specific path.

   • Sub-paths are listed as a list, and multiple entries are allowed.

   • You can use a wildcard (*) at the end of a path to specify all paths under that particular path (it does not include the parent path itself).

     CODE

     spec:
       allow:
         resources:
           - webApp: "Querypie Web Admin"
             urlPaths: 
               - "/general-settings/user-management"     # Specific sub-path
               - "/general-settings/user-management/*"   # All sub-paths under the specific path

   • Overlapping paths cannot be entered simultaneously.

     • e.g., Cannot simultaneously enter /general-settings/* and /general-settings/user-management for Querypie Web Admin:

       CODE

       spec:
         allow:
           resources:
             - webApp: "Querypie Web Admin"
               urlPaths: 
                 - "/general-settings/*"
                 - "/general-settings/user-management"

4. Wildcards in the middle of a path or as part of a path name, or regular expressions, are not allowed.

   • "/*-settings" (X)

   • "/*/edit" (X)

   • "^/database-settings/policies/data-.*$" (X)

5. If Deny and Allow policies overlap for the same resource (and sub-path), the Deny policy takes precedence.

urlPathTags OPTIONAL

Specifies sub-paths to allow access to, based on URL Path tags assigned to sub-paths registered for the web app.

1. ags are case-sensitive, and multiple tags can be entered.

   • If multiple tags with the same Key are entered, they operate under an OR condition.

     • e.g., Allow access to paths tagged with access: admin OR access: user:

       CODE

       urlPathTags: 
         "access": "admin"
         "access": "user"

   • If multiple tags with different Keys are entered, they operate under an AND condition.

     • e.g., Allow access to paths tagged with access: admin AND type: general:

       CODE

       urlPathTags: 
         "access": "admin"
         "type": "general"

Conditions OPTIONAL

conditions define criteria to narrow the scope of resources to which a rule applies. Two types of conditions can be specified: userAttributes and ipAddresses.

conditions are syntactically allowed only in spec:allow.

userAttributes OPTIONAL

Limits the scope of users allowed resource access by a rule, based on QueryPie user attributes.

User attributes can be viewed on the user details page in the Administrator > General > Users menu. Attributes for users added in QueryPie can be added/modified/deleted on the details page, while attributes for users added via IdP synchronization can be changed in the user directory (e.g., Okta, LDAP).

Attribute information is case-sensitive, and multiple attributes can be entered.

• If multiple attributes with the same Key are entered, they operate under an OR condition.

  • e.g., Allow access for users whose department (department) is PM OR QA:

    CODE

    userAttributes: 
      "department": "PM"
      "department": "QA"

• If multiple attributes with different Keys are entered, they operate under an AND condition.

  • e.g., Allow access for users whose department (department) is PM AND title (title) is Manager:

    CODE

    userAttributes: 
      "department": "PM"
      "title": "Manager"

ipAddresses OPTIONAL

Defines a list of IP access control conditions for resources, in single IP or CIDR format.

ipAddresses: ["10.10.0.0/24", "10.11.10.1"]

If not defined separately, the default is to allow all (0.0.0.0/0).

Recommended Operational Approach

It is recommended to specify web apps and sub-paths to allow access to based on defined privileges.

1. Identify existing privileges for each web app.

   1. e.g., For a hiring platform:

      1. HR - Has all privileges.

      2. Interviewer - Can only access pages for managing interview results.

2. Create separate Roles for each privilege level of the web app

   1. e.g., HR, Interviewer

3. Create separate access policies for each privilege level and assign them to the Roles.

   1. HR policy - Allow access to all paths within the hiring platform.

   2. Interviewer policy - Allow access only to interview result pages within the hiring platform.

Warning

When using a pattern that allows only some access, landing pages essential for normal website use (e.g., login pages, redirect pages) must be configured as separate policies and included in the Role.

Please choose one of the following two methods to specify sub-paths for allowed access:

Tag-Based Access Control

It is recommended to register Paths for the web app, assign appropriate tags to each Path, and then control access based on these tags in the policy. This approach offers the following advantages:

• Ease of role-based policy management: Paths required for a specific role can be managed by assigning them the same tag.

• Simplified policy maintenance: If new paths are added to the web app, access control can be managed by simply assigning the appropriate tags without modifying existing policies.

• Implementation of complex access control: Fine-grained access control can be achieved by combining various conditions (user attributes, IP addresses, etc.) with tags.

Utilizing Wildcards

With the wildcard feature, you can efficiently control access to all pages under a specific path.

• Control access to all admin pages: /admin/*

• Control access to an entire specific feature module: /module/orders/*