Access Control

Casabase Cube provides row-level security for controlling which cube data individual users can access.

Security rules are defined against members of secured cube dimensions. When security applies to a user, Casabase Cube filters query results to the members permitted by those rules.

This allows multiple users to query the same cube and use the same query definitions while receiving only the data they are authorized to access.

How Access Control Works

Casabase Cube security operates at the cube dimension and member level.

For example, an organization might secure the ENTITY dimension:

Total Entity
├── North America
│   ├── United States
│   └── Canada
├── Europe
│   ├── Germany
│   └── France
└── Asia Pacific
    ├── Japan
    └── Australia

A user responsible for North America can be granted access to:

North America

and all of its descendants.

When that user executes a query requesting a broader Entity selection, Casabase Cube filters the result to the authorized portion of the hierarchy.

Conceptually:

Query Requests
Total Entity
     │
     ▼
Apply User Security
     │
     ▼
Permitted Hierarchy Scope

The query itself does not need to be rewritten for that user.

Security Is Opt-In Per User

Casabase Cube row-level security is opt-in per user.

Security filtering applies only when both of the following are true:

1. Security is enabled on at least one dimension of the cube.
2. The user has at least one active security rule for that cube.

A user with no active security rules for a cube is unrestricted by Casabase Cube row-level security.

Conceptually:

Security-enabled dimension exists?
        │
        ├── No ──► No row-level filtering
        │
        └── Yes
              │
              ▼
Does the user have an active rule?
              │
              ├── No ──► Unrestricted
              │
              └── Yes ──► Apply security rules

Do not assume that enabling security on a dimension automatically restricts every user.

If a user should have restricted access, that user must have at least one appropriate active security rule.

Security Behavior Summary

Security enabled on cube?	User has active rule?	Result
No	No	Full access
No	Yes	Full access; rule is inert
Yes	No	Full access
Yes	Yes	Security filtering applies

The third case is the most important:

Security Enabled
      +
No Active Rules for User
      =
Unrestricted

Application Roles vs. Data Access

Application roles and row-level security perform different functions.

Control	Purpose
Snowflake account role	Provides the path through which application access is granted.
CUBE_PUBLIC / CUBE_ADMIN	Determines which Casabase Cube capabilities the user can use.
Row-level security	Determines which cube data the user can see.

For example:

User A
├── CUBE_PUBLIC
└── ENTITY: North America

and:

User B
├── CUBE_PUBLIC
└── ENTITY: Europe

can execute the same query while receiving different data.

A user can also have:

CUBE_PUBLIC
+
No active security rules

in which case Casabase Cube row-level security does not restrict that user.

See Roles and Privileges for application-role access.

READ SESSION Requirement

Casabase Cube evaluates row-level security against the current Snowflake user.

The application therefore requires:

GRANT READ SESSION
ON ACCOUNT
TO APPLICATION CASABASE_CUBE;

Substitute your installed application name where appropriate.

READ SESSION allows the application to evaluate:

CURRENT_USER()

and apply the security rules associated with that Snowflake login.

Without READ SESSION, user-specific security rules cannot be evaluated.

Enabling Security on a Dimension

Security enablement is a property of the dimension.

It can be configured when the dimension is created or updated afterward.

For example:

CALL CUBE.MANAGE_DIMENSION_CONFIG(
    'UPDATE_DIMENSION',
    '{
      "cube_name": "FINANCE",
      "hier_name": "ENTITY",
      "use_security": true
    }'
);

To review dimensions that currently have security enabled:

SELECT
    CUBE_NAME,
    DIM_NAME,
    USE_SECURITY,
    SECURITY_MODE
FROM CASABASE_CUBE.CONFIG.CUBE_DIMENSIONS
WHERE USE_SECURITY = TRUE
ORDER BY
    CUBE_NAME,
    DIM_NAME;

Any dimension can be secured.

In practice, security is commonly applied to organizational dimensions such as:

ENTITY
COST CENTER
DEPARTMENT

rather than time or measure dimensions.

Each secured dimension adds another security filter to applicable queries.

Enabling Security Does Not Grant Access

Enabling security and defining user rules are two different steps:

Should this dimension participate in security?
            │
            └── Dimension configuration


What may this user access?
            │
            └── Security rule

Setting:

use_security = true

does not automatically restrict any user.

A user becomes security-filtered only after that user also has an active security rule on the cube.

Managing Security Rules

Security rules are managed with:

MANAGE_SECURITY_RULE

Supported actions are:

Action	Purpose
ADD	Create a security rule
UPDATE	Modify an existing rule by ID
DEACTIVATE	Suspend a rule while preserving it
DELETE	Permanently remove a rule

Security administration requires CUBE_ADMIN.

Adding a Security Rule

ADD requires:

cube_name
hier_name
member_name
user_name

For example:

CALL CUBE.MANAGE_SECURITY_RULE(
    'ADD',
    '{
      "cube_name":   "FINANCE",
      "hier_name":   "ENTITY",
      "member_name": "North America",
      "user_name":   "na.controller@company.com"
    }'
);

The user_name value is the Snowflake login matched against:

CURRENT_USER()

Security rules are assigned per user, not per Snowflake role.

Granting a Snowflake role does not create a Casabase Cube row-level security rule for the users who inherit that role.

Parameter Naming

The security-rule API uses:

hier_name

rather than:

dim_name

even though the product term is dimension and the stored configuration column is:

DIM_NAME

For example:

{
  "cube_name": "FINANCE",
  "hier_name": "ENTITY",
  "member_name": "North America",
  "user_name": "na.controller@company.com"
}

Using dim_name in this API is not equivalent.

Granting the Top Member

Granting the dimension’s top member effectively grants the complete dimension.

For example:

CALL CUBE.MANAGE_SECURITY_RULE(
    'ADD',
    '{
      "cube_name":   "FINANCE",
      "hier_name":   "ENTITY",
      "member_name": "Total Entity",
      "user_name":   "cfo@company.com"
    }'
);

Conceptually:

Grant Total Entity
        │
        ▼
Total Entity
├── North America
├── Europe
└── Asia Pacific

The user still has an active security rule, but the rule’s permitted branch spans the entire dimension.

Granting a Branch

A grant on:

North America

conveys:

North America
├── United States
└── Canada

at their full values.

The administrator does not need to create individual rules for every descendant.

Granting a Leaf

A security rule can also target a leaf member.

For example:

CALL CUBE.MANAGE_SECURITY_RULE(
    'ADD',
    '{
      "cube_name":   "FINANCE",
      "hier_name":   "ENTITY",
      "member_name": "US_West_001",
      "user_name":   "site.manager@company.com"
    }'
);

The user’s full-value access then begins at that leaf.

Member Inheritance

A security grant conveys:

Granted Member
      +
All Descendants

at full value.

For example:

Total Entity
├── North America
│   ├── US
│   │   ├── US East
│   │   └── US West
│   └── Canada
└── EMEA
    ├── UK
    └── Germany

A grant on:

North America

provides full-value access to:

North America
US
US East
US West
Canada

while:

EMEA
UK
Germany

are outside the granted branch.

Shared and Alternate Members

Shared and alternate hierarchy members resolve to their underlying base member for security purposes.

A grant on a shared member therefore conveys the same underlying leaf scope as a grant on the original member.

Security is based on the business member being represented, not on creating a separate security identity for each hierarchy placement.

Multiple Rules on the Same Dimension

A user can have more than one active rule on the same secured dimension.

Those permitted branches are combined.

For example:

ENTITY Rule 1
└── North America

ENTITY Rule 2
└── Europe

produces:

Allowed ENTITY Scope
├── North America
└── Europe

Conceptually, rules within one dimension behave as an OR:

North America
      OR
Europe
      │
      ▼
North America + Europe

Rules Across Multiple Dimensions

When a user has security rules on multiple secured dimensions, the restrictions apply together.

For example:

ENTITY
└── North America

and:

PRODUCT
└── Personal Electronics

produce an effective permitted intersection of:

North America
      AND
Personal Electronics

Conceptually:

Allowed ENTITY
      │
      ├─────────┐
      │         │
      ▼         ▼
North America   AND   Personal Electronics
                        ▲
                        │
                   Allowed PRODUCT

Therefore:

• Multiple rules within one dimension expand the permitted set.
• Restrictions across dimensions constrain the result together.

Ancestors Remain Visible

A security grant does not necessarily hide every member above the granted branch.

Ancestors can remain visible when requested.

What changes is their value.

An ancestor is calculated using only the leaves permitted to the executing user.

For example:

Promotions               94,503
├── No Promotion         90,866
├── Coupon                1,247
├── Newspaper Ad          1,171
└── Temporary Price Red.  1,219

An unrestricted user can see:

Promotions               94,503
No Promotion             90,866
Coupon                    1,247
Newspaper Ad              1,171
Temporary Price Red.      1,219

A user granted only:

Coupon

can see:

Promotions                1,247
Coupon                    1,247

The ancestor remains visible, but its value is a partial rollup.

Partial Rollups

A partial rollup is an aggregate calculated from only the leaves the user is permitted to access.

Conceptually:

True Parent
   =
All Descendants

while for a restricted user:

Visible Parent
   =
Permitted Descendants Only

The result is not marked:

PARTIAL
RESTRICTED
INCOMPLETE

This means the same member label can legitimately have different values for different users.

For example:

User A
Total Entity = 100,000

and:

User B
Total Entity = 27,000

can both be valid when the users have different security scopes.

Do not compare an aggregate between users with different grants unless the differing population is understood.

If a report requires a complete total, grant access at a hierarchy branch where that total is complete rather than granting only a subset of the children.

Siblings and Unrelated Branches

A grant does not make siblings of the granted branch visible.

For example:

Total Entity
├── North America
└── EMEA

with a grant on:

North America

can result in:

Total Entity
North America

while:

EMEA

and its descendants are absent.

The ancestor can remain visible as a partial rollup, while unrelated branches are omitted.

Same Query, Different Users

Consider:

{
  "MEASURES": ["Units"],
  "ENTITY": [{"idescendants": "Total Entity"}],
  "YEARS": ["Curr Year"]
}

The POV structurally requests the complete Entity hierarchy.

An unrestricted user can receive the complete result.

A user restricted to North America can receive:

Total Entity
North America
United States
Canada

where the value of Total Entity represents only the permitted North America population.

A user restricted to Europe can receive:

Total Entity
Europe
Germany
France

with a different partial value for Total Entity.

The POV has not changed.

The executing user’s security scope has.

Restricted Members Are Silently Omitted

A query that requests members outside the user’s permitted scope does not normally return an access-denied error.

Restricted rows are silently omitted.

For example:

{
  "ENTITY": [
    {"idescendants": "Total Entity"}
  ]
}

can return only the permitted branch rather than an error identifying the names of restricted members.

This behavior avoids using access-denied responses to confirm that hidden members exist.

It also means security should be considered when troubleshooting unexpectedly small result sets.

Security and Hierarchy Expansion

Hierarchy operators are resolved structurally and then evaluated within the user’s permitted scope.

Conceptually:

POV Expansion
      │
      ▼
Structural Hierarchy
      │
      ▼
Apply User Scope
      │
      ▼
Permitted Result

A hierarchy expansion does not bypass security.

Security Modes

Each secured dimension has a:

SECURITY_MODE

The default and supported mode is:

EXCLUDE

MASK is also defined but has important limitations.

EXCLUDE

Under EXCLUDE, restricted leaves are removed from the calculation population.

For example:

Total Entity
├── A
├── B
├── C
├── D
└── E

If the user can access only:

A
B
C

then:

Total Entity

is calculated from:

A + B + C

This produces the partial-rollup behavior described above.

EXCLUDE is the normal security mode.

MASK

MASK returns a no-access marker when a requested cell depends on data the user cannot access rather than returning a partial value.

However, MASK is refused when a query must resolve calculated members.

A formula evaluated using only permitted leaves could produce a partial value, which conflicts with the contract of MASK.

Rather than return a misleading calculation, Casabase Cube refuses that query.

Use EXCLUDE unless there is a specific reason to use MASK and the affected query patterns have been validated.

Security Across Query Interfaces

When security applies to a user, it is enforced across supported Casabase Cube read paths, including:

• Query Builder
• QUERY_CUBE
• QUERY_CUBE_PIVOT_JSON
• Secure fact views
• Secure dimension views
• Formula evaluation
• Scheduled Saved Query execution

Switching from Query Builder to SQL does not provide an alternate path around configured Casabase Cube security.

Secure Fact View

Each cube exposes:

<CUBE>_FACT_SECURE

For example:

SELECT *
FROM CASABASE_CUBE.SHARED_DATA.ASOSAMP_FACT_SECURE;

returns stored fact rows available to the current user under the applicable security configuration.

The view exposes stored data rather than full calculation-engine semantics.

See Querying with SQL.

Secure Dimension View

Each cube also exposes:

<CUBE>_DIMENSIONS

The dimension view provides security-aware hierarchy metadata.

This prevents hierarchy metadata from becoming an alternate path for discovering members outside the user’s permitted scope.

Security and Calculations

Security scope is established before aggregation and formula evaluation.

Conceptually:

Requested Cube Data
       │
       ▼
Apply User Security
       │
       ▼
Permitted Leaf Scope
       │
       ▼
Aggregation
       │
       ▼
Formula Calculation
       │
       ▼
User Result

A formula therefore cannot be used to retrieve data the executing user could not otherwise access.

Formula References

The basic formula behavior is:

Formula references permitted member
        │
        ▼
Permitted value

Formula references denied member
        │
        ▼
Restricted value unavailable

Formula references ancestor above grant
        │
        ▼
Partial aggregate over permitted leaves

Calculated results can therefore vary between users when their permitted operands differ.

That is security-scoped calculation, not a security bypass.

Security and Default Members

Default members continue to participate in normal POV resolution when row-level security is enabled.

For example, an omitted dimension can resolve to a configured default member even though that dimension was not explicitly included in the POV.

Security is then applied to the resulting query context.

Administrators should therefore consider both:

Default Member Configuration
           +
User Security Rules
           │
           ▼
Effective Query Context

when troubleshooting a result.

See Point of View (POV).

Scheduled Saved Queries

A scheduled Saved Query executes under a Snowflake identity.

Casabase Cube security is evaluated under that identity when the query runs.

Conceptually:

Scheduled Execution Identity
          │
          ▼
Casabase Cube Security
          │
          ▼
Calculated Result
          │
          ▼
Materialized Snowflake Table

After materialization, consumers are reading a plain Snowflake table.

Casabase Cube row-level security is not dynamically reevaluated for each reader of that table.

Subsequent access is governed by Snowflake privileges on the materialized table.

Do not use one scheduled result table to serve users who require different Casabase Cube security scopes.

Instead:

Query the cube directly per user

or:

Create separate appropriately scoped materializations

for the intended audiences.

Security Changes Take Effect Immediately

Security configuration is evaluated at query time.

A rule change takes effect on the next query.

No dimension rebuild is required simply because a security rule was added, changed, activated, deactivated, or removed.

Conceptually:

Change Rule
    │
    ▼
Next Query
    │
    ▼
New Security Scope

Reviewing Active Rules

To review all active rules for a cube:

SELECT
    DIM_NAME,
    USER_NAME,
    MEMBER_NAME,
    UPDATED_BY,
    UPDATED_DATE
FROM CASABASE_CUBE.CONFIG.SECURITY
WHERE CUBE_NAME = 'FINANCE'
  AND ACTIVE = TRUE
ORDER BY
    DIM_NAME,
    USER_NAME;

Access Summary Per User

To summarize active grants:

SELECT
    USER_NAME,
    DIM_NAME,
    COUNT(*) AS granted_members,
    LISTAGG(MEMBER_NAME, ', ') AS members
FROM CASABASE_CUBE.CONFIG.SECURITY
WHERE CUBE_NAME = 'FINANCE'
  AND ACTIVE = TRUE
GROUP BY
    USER_NAME,
    DIM_NAME
ORDER BY
    USER_NAME,
    DIM_NAME;

This provides a concise view of each user’s configured member scope.

Required Unrestricted-User Control

Because security is opt-in, administrators should explicitly identify users who have queried a secured cube without any active rules.

Use:

SELECT DISTINCT
    a.USER_NAME
FROM CASABASE_CUBE.CONFIG.AUDIT_LOG a
WHERE a.CUBE_NAME = 'FINANCE'
  AND a.EVENT_TYPE = 'DATA_QUERY'
  AND NOT EXISTS (
        SELECT 1
        FROM CASABASE_CUBE.CONFIG.SECURITY s
        WHERE s.CUBE_NAME = a.CUBE_NAME
          AND s.USER_NAME = a.USER_NAME
          AND s.ACTIVE = TRUE
      )
ORDER BY 1;

Every user returned by this query has queried FINANCE without active Casabase Cube row-level security rules.

On a cube where security has been enabled, this list should contain only users who are intentionally unrestricted.

This is a core control for the opt-in security model.

Updating a Security Rule

Rules are identified by ID.

For example, to move a user to a different branch:

CALL CUBE.MANAGE_SECURITY_RULE(
    'UPDATE',
    '{
      "id": 101,
      "member_name": "EMEA"
    }'
);

Deactivating Rules

Use DEACTIVATE to suspend one or more rules while preserving the configuration:

CALL CUBE.MANAGE_SECURITY_RULE(
    'DEACTIVATE',
    '{"ids":[101,102]}'
);

This is useful for temporary situations such as:

• Leave
• Role changes
• Access investigations
• Reversible administrative changes

Reactivating a Rule

A deactivated rule can be reactivated with UPDATE:

CALL CUBE.MANAGE_SECURITY_RULE(
    'UPDATE',
    '{
      "id": 101,
      "active": true
    }'
);

Deactivating the Final Rule

Only active rules participate in security evaluation.

If a user’s final active rule is deactivated:

Before

Active Rule
    │
    ▼
Restricted User

becomes:

After

No Active Rules
    │
    ▼
Unrestricted User

This is why deactivation must be treated as an access-control change rather than simply administrative cleanup.

Deleting Rules

To permanently remove rules:

CALL CUBE.MANAGE_SECURITY_RULE(
    'DELETE',
    '{"ids":[101,102,103]}'
);

Deleting is permanent.

When a change may need to be reversed, deactivation is preferable because it preserves the prior configuration.

Finding Rule IDs

Before updating, deactivating, or deleting rules:

SELECT
    ID,
    DIM_NAME,
    USER_NAME,
    MEMBER_NAME
FROM CASABASE_CUBE.CONFIG.SECURITY
WHERE CUBE_NAME = 'FINANCE'
  AND USER_NAME = 'departing.user@company.com';

Use the returned IDs with UPDATE, DEACTIVATE, or DELETE.

Removing a User’s Application Access

Deleting security rules does not remove application access.

In fact, removing the user’s final active rule can expand the user’s effective scope by making that user unrestricted.

To remove application access completely:

1. Revoke the applicable Snowflake role path that provides Casabase Cube access.
2. Verify the user no longer inherits CUBE_PUBLIC or CUBE_ADMIN.
3. Deactivate or delete obsolete security rules as appropriate.
4. Preserve the user’s audit history.

See Operational Tasks.

Validating Security

After adding or changing security rules, validate the effective result using the intended user identity or an appropriate test identity.

A useful test is a broad hierarchy query such as:

{
  "MEASURES": ["Units"],
  "ENTITY": [
    {"idescendants": "Total Entity"}
  ],
  "YEARS": ["Curr Year"]
}

For a North America user, verify:

• The permitted branch appears.
• Unrelated branches do not appear.
• Ancestors above the grant contain the expected partial rollup.
• Explicit requests for denied members do not return restricted data.

Also validate queries that:

• Request an unauthorized member directly
• Expand above the granted branch
• Use calculated members
• Omit secured dimensions
• Query secure SQL views

Troubleshooting: User Can See Too Much

First determine whether the user has any active rules:

SELECT *
FROM CASABASE_CUBE.CONFIG.SECURITY
WHERE CUBE_NAME = 'FINANCE'
  AND USER_NAME = '<user>'
  AND ACTIVE = TRUE;

If no rows are returned, the user is unrestricted by Casabase Cube row-level security.

Also confirm that the intended dimension has:

USE_SECURITY = TRUE

Troubleshooting: User Sees Fewer Rows Than Expected

Review:

• All of the user’s active rules
• Every secured dimension
• Multiple grants within each dimension
• Intersections across secured dimensions
• The requested POV
• Default-member configuration
• Hierarchy relationships

Remember that restricted members are silently omitted.

Troubleshooting: Parent Value Looks Too Small

A parent above the user’s granted branch can represent a partial rollup.

For example:

Total Entity

for a restricted user can mean:

All Entity leaves this user may access

rather than:

All Entity leaves in the cube

This is expected under EXCLUDE.

Compare the user’s grants before treating the value as a data or aggregation problem.

Troubleshooting: Removing Rules Increased Access

This is expected if the removed rule was the user’s final active rule.

The user changes from:

Restricted

to:

No Casabase Cube row-level restriction

If the intention is to eliminate access, revoke application access through the user’s Snowflake role path.

Troubleshooting: Formula Returns a Different Value for Different Users

This can also be expected.

Formula operands are security-scoped.

For example:

Share of Total
=
Current Member / Total

can have a different denominator for users with different permitted populations.

The formula remains secure, but its result can vary by user.

Recommended Practices

When administering row-level security:

• Remember that security is opt-in per user.
• Enable security only on dimensions that require data-level filtering.
• Create at least one active rule for every user who must be restricted.
• Grant access at meaningful hierarchy branches where practical.
• Understand that grants include descendants at full value.
• Understand that ancestors can remain visible as partial rollups.
• Do not compare partial totals across users without considering security scope.
• Use multiple rules within one dimension when a user requires multiple branches.
• Consider the intersection of restrictions across dimensions.
• Use EXCLUDE unless there is a specific validated reason to use MASK.
• Validate security changes with representative queries.
• Review users querying secured cubes without active rules.
• Prefer deactivation when a rule change may need to be reversed.
• Treat deactivation or deletion of a user’s final active rule as an access-expanding change.
• Revoke application-role access when a user should no longer access Casabase Cube.
• Remember that security changes take effect on the next query without a rebuild.
• Do not use one materialized Saved Query table for audiences requiring different security scopes.

Key Principle

The most important Casabase Cube access-control rule is:

No active security rules means no Casabase Cube row-level restriction.

A user is security-filtered only when security is enabled on the cube and that user has at least one active rule.

Once security applies:

User Rules
    │
    ▼
Granted Members
    │
    ▼
Granted Members + Descendants
    │
    ▼
Permitted Leaf Scope
    │
    ▼
Aggregation and Formulas
    │
    ▼
User Result

Ancestors can remain visible, but their values are calculated only from that permitted scope.

Related Topics

• Administration Overview
• Roles and Privileges
• Data Classification
• Compliance and Privacy
• Audit Log
• Operational Tasks
• Security Model
• Querying with SQL