data-access-policies.mdx

Data access policies

You can use the access_policy parameter within cubes and views to configure data 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:

• role defines which data access role 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.

role

The role parameter defines which data access role, as defined by the context_to_roles configuration parameter, a policy applies to. To define a policy that applies to all users regardless of their roles, use the any role shorthand: role: "*".

In the following example, three access policies are defined, with the first one applying to all users and two other applying to users with marketing or finance roles, respectively.

cubes:
  - name: orders
    # ...

    access_policy:
        # Applies to any role
      - role: "*"
        # ...

      - role: marketing
        # ...

      - role: finance
        # ...

cube(`orders`, {
  // ...

  access_policy: [
    {
      // Applies to any role
      role: `*`,
      // ...
    },
    {
      role: `marketing`,
      // ...
    },
    {
      role: `finance`,
      // ...
    }
  ]
})

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.

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

cubes:
  - name: orders
    # ...

    access_policy:
      - role: "*"
        conditions:
          - if: "{ securityContext.is_EMEA_based }"
        member_level:
          includes: "*"

cube(`orders`, {
  // ...

  access_policy: [
    {
      role: `*`,
      conditions: [
        { if: securityContext.is_EMEA_based }
      ],
      member_level: {
        includes: `*`
      }
    }
  ]
})

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

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

cubes:
  - name: orders
    # ...

    access_policy:
      - role: manager
        conditions:
          - if: "{ securityContext.is_full_time_employee }"
        member_level:
          includes:
            - status
            - count

      - role: manager
        conditions:
          - if: "{ securityContext.is_full_time_employee }"
          - if: "{ securityContext.has_completed_privacy_training }"
        member_level:
          includes: "*"

cube(`orders`, {
  // ...

  access_policy: [
    {
      role: `manager`,
      conditions: [
        { if: securityContext.is_full_time_employee }
      ],
      member_level: {
        includes: [
          `status`,
          `count`
        ]
      }
    },
    {
      role: `manager`,
      conditions: [
        { if: securityContext.is_full_time_employee },
        { if: securityContext.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:

Scope	Access
Users with the manager role	All members except for count
Users with the observer role	All members except for count and count_7d
Users with the guest role	Only the count_30d measure
All other users	No access to this cube at all

cubes:
  - name: orders
    # ...
    
    access_policy:
      - role: "*"
        member_level:
          # Includes nothing, i.e., excludes all members
          includes: []
      
      - role: manager
        member_level:
          # Includes all members except for `count`
          excludes:
            - count
      
      - role: observer
        member_level:
          # Includes all members except for `count` and `count_7d`
          excludes:
            - count
            - count_7d
      
      - role: guest
        # Includes only `count_30d`, excludes all other members
        member_level:
          includes:
            - count_30d

cube(`orders`, {
  // ...

  access_policy: [
    {
      role: `*`,
      // Includes nothing, i.e., excludes all members
      member_level: {
        includes: []
      }
    },
    {
      role: `manager`,
      // Includes all members except for `count`
      member_level: {
        excludes: [
          `count`
        ]
      }
    },
    {
      role: `observer`,
      // Includes all members except for `count` and `count_7d`
      member_level: {
        excludes: [
          `count`,
          `count_7d`
        ]
      }
    },
    {
      role: `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 with the manager role 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:
      
      - role: manager
        row_level:
          filters:
            - member: state
              operator: equals
              values: [ "{ securityContext.state }" ]

cube(`orders`, {
  // ...

  access_policy: [
    {
      role: `manager`,
      row_level: {
        filters: [
          {
            member: `state`,
            operator: `equals`,
            values: [ securityContext.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.