Access policies

You can use the access_policy parameter within cubes and views to configure access policies for them.

Parameters

The access_policy parameter should define a list of access policies. Each policy can be configured using the following parameters:

• group or groups define which groups a policy applies to.
• conditions can be optionally used to specify when a policy takes effect.
• member_level and row_level parameters are used to configure member-level and row-level access.

group

The group parameter defines which group a policy applies to. To define a policy that applies to all users regardless of their groups, use the any group shorthand: group: "*".

In the following example, two access policies are defined for users with marketing or finance groups, respectively.

cubes:
  - name: orders
    # ...
 
    access_policy:
      - group: marketing
        # ...
 
      - group: finance
        # ...

groups

The groups parameter (plural) allows you to apply the same policy to multiple groups at once by providing an array of group names.

In the following example, a single policy applies to both analysts and managers groups:

cubes:
  - name: orders
    # ...
 
    access_policy:
      - groups: [analysts, managers]
        member_level:
          includes: "*"

conditions

The optional conditions parameter, when present, defines a list of conditions that should all be true in order for a policy to take effect. Each condition is configured with an if parameter that is expected to reference the security context or user attributes.

In the following example, a permissive policy for all groups will only apply to EMEA-based users, as determined by the is_EMEA_based user attribute:

cubes:
  - name: orders
    # ...
 
    access_policy:
      - group: "*"
        conditions:
          - if: "{ userAttributes.is_EMEA_based }"
        member_level:
          includes: "*"

You can use the conditions parameter to define multiple policies for the same group.

In the following example, the first policy provides access to a subset of members to users in the manager group who are full-time employees while the other one provides access to all members to users in the manager group who are full-time employees and have also completed a data privacy training:

cubes:
  - name: orders
    # ...
 
    access_policy:
      - group: manager
        conditions:
          - if: "{ userAttributes.is_full_time_employee }"
        member_level:
          includes:
            - status
            - count
 
      - group: manager
        conditions:
          - if: "{ userAttributes.is_full_time_employee }"
          - if: "{ userAttributes.has_completed_privacy_training }"
        member_level:
          includes: "*"

member_level

The optional member_level parameter, when present, configures member-level access for a policy by specifying allowed or disallowed members.

You can either provide a list of allowed members with the includes parameter, or a list of disallowed members with the excludes parameter. There's also the all members shorthand for both of these paramaters: includes: "*", excludes: "*".

In the following example, member-level access is configured this way:

cubes:
  - name: orders
    # ...
    
    access_policy:
      - group: manager
        member_level:
          # Includes all members except for `count`
          excludes:
            - count
      
      - group: observer
        member_level:
          # Includes all members except for `count` and `count_7d`
          excludes:
            - count
            - count_7d
      
      - group: guest
        # Includes only `count_30d`, excludes all other members
        member_level:
          includes:
            - count_30d

Note that access policies also respect member-level security restrictions configured via public parameters. See member-level access to learn more about policy evaluation.

row_level

The optional row_level parameter, when present, configures row-level access for a policy by specifying filters that should apply to result set rows.

In the following example, users in the manager group are allowed to access only rows that have the state dimension matching the state from the security context. All other users are disallowed from accessing any rows at all.

cubes:
  - name: orders
    # ...
    
    access_policy:
      - group: manager
        row_level:
          filters:
            - member: state
              operator: equals
              values: [ "{ userAttributes.state }" ]

For convenience, row filters are configured using the same format as filters in REST API queries, allowing to use the same set of filter operators, e.g., equals, contains, gte, etc. You can also use and and or parameters to combine multiple filters into boolean logical operators.

Note that access policies also respect row-level security restrictions configured via the query_rewrite configuration option. See row-level access to learn more about policy evaluation.

Using securityContext

The userAttributes object is only available in Cube Cloud platform. If you are using Cube Core or authenticating against Core Data APIs directly, you won't have access to userAttributes. Instead, you need to use securityContext directly when referencing user attributes in access policies (e.g., in row_level filters or conditions). For example, use securityContext.userId instead of userAttributes.userId.

cubes:
  - name: orders
    # ...
 
    access_policy:
      - group: manager
        row_level:
          filters:
            - member: country
              operator: equals
              values: [ "{ securityContext.country }" ]