Fine-grained access control to data has always been one of the foundational pillars of Cube's universal semantic layer.

With tools such as dynamic data modeling, multitenancy, visibility settings, and the query rewrite security hook, Cube provides comprehensive support for all kinds of column-level and row-level security scenarios. Furthermore, with integrations to third party identity providers (IdP) such as Microsoft Entra ID and Secure LDAP in Google Workspace, Cube is capable of retrieving user and group data via SAML and other means and leveraging it in custom authentication implementations.

Today, we are delighted to announce an overarching Data Access Policies feature in Cube and Cube Cloud. With this feature, you can now define and visualize policies that govern access to data in an easy-to-use UI in Cube Cloud, maintain them as part of your data model, and enforce them for users accessing your semantic layer with respect to their roles retrieved via a user directory integration.

Data Access Policies in the data model

We believe that data access policies should be part of the data model that they govern, so it's only natural to maintain them alongside the code of your cubes and views.

Now you can add the access_policy parameter to any cube or view to provide declarative definitions of your access policies. Each cube or view can have only one access policy. Each access policy can govern access for many roles that your users bear.

Let's explore a few data model examples to get a grasp of access policies. With the following access policy, only users with admin or sales_manager roles will have access to data in the orders cube; however, no row-level or column-level restrictions will be applied to them. Users without these roles will have no access to orders.

cubes:
  - name: orders
    sql_table: orders


    # Member definitions skipped


    access_policy:
      - roles:
        - admin
        - sales_manager

With the following access policy, users with the admin role will have full access to data in the customers cube. Users with the sales_manager role will have no access to the full_name dimension at the member level; furthermore, at the row level, they will only have access to customer data with the state matching their manager_state attribute (retrieved from a user directory). Finally, users with all other roles will only have access to the state dimension and the count measure at the member level.

cubes:
  - name: customers
    sql_table: customers


    dimensions:
      - name: state
        sql: state
        type: string


      - name: full_name
        sql: full_name
        type: string


    measures:
      - name: count
        type: count


    access_policy:
      - role: admin


      - role: sales_manager
        member_level:
          excludes:
            - full_name
        row_level:
          filters:
            - member: "{state}"
              operator: equals
              values: "{ [securityContext.manager_state] }"


      - role: '*'
        member_level:
          includes:
            - state
            - count

As you can see, access policies follow the industry-standard approach for defining row-level and column-level security policies, only slightly adjusting them to the semantic layers domain that operates with data model members (i.e., dimensions and measures) instead of raw table columns.

Surely, access policy definitions can get more advanced and intricate, applying to roles conditionally and implementing complex boolean logic in row-level filters. However, you would hardly find them difficult to read and maintain. Instead of authoring access policies in code, we invite you to define and visualize them in an easy-to-use UI in Cube Cloud.

Data Access Policies in Cube Cloud

According to access policies defined in your data model, Cube Cloud provides you with an access control matrix visualization for each user role so you can instantly see which part of the data model is accessible or inaccessible to a specific role:

You can always drill down and adjust an access policy in the UI, using Cube Cloud to generate an updated definition and save it to the data model code, similarly to how you add pre-aggregation definitions in Rollup Designer.

Identity provider integrations

As shown above, access policies are applied to user roles rather than individual users. Also, access policy definitions can reference user attributes retrieved from a user directory.

Data Access Policies are powered by existing single sign-on (SSO) integrations in Cube Cloud. Not only can you govern access to Cube Cloud based on a user directory data from supported identity providers; now you can also use it to govern access to the data in your semantic layer.

What's next?

We're launching Data Access Policies in a private preview today. If you'd like to get access to Data Access Policies in Cube Cloud, please reach out to us. We'll be happy to guide you though the implementation and ensure that your security requirements are accounted for.