Security Model

Casabase Cube builds on Snowflake identity and access control while adding application-specific row-level security for multidimensional data.

The security model has three distinct layers:

Snowflake Identity and Account Roles
              │
              ▼
Casabase Cube Application Roles
              │
              ▼
Casabase Cube Row-Level Security

These layers answer different questions:

Layer	Determines
Snowflake identity and account roles	How the user authenticates and receives access to the Native App
CUBE_PUBLIC / CUBE_ADMIN	What Casabase Cube functionality the user can perform
Row-level security	Which cube members and data the user can see

Row-level security is opt-in per user, not deny-by-default. This is the most important characteristic of the Casabase Cube security model.

Snowflake Identity

Casabase Cube does not maintain a separate end-user identity store.

Queries execute under Snowflake identity, and Casabase Cube evaluates the current user through Snowflake session context.

Conceptually:

User
 │
 ▼
Snowflake Authentication
 │
 ▼
Snowflake Session
 │
 ▼
CURRENT_USER()
 │
 ▼
Casabase Cube Security

This allows Casabase Cube security to use the same user identity already established by Snowflake.

READ SESSION

Row-level security depends on the application being able to read Snowflake session context.

The required account-level privilege is:

GRANT READ SESSION ON ACCOUNT TO APPLICATION CASABASE_CUBE;

READ SESSION allows Casabase Cube to evaluate values such as:

CURRENT_USER()

Without this privilege, row-level security cannot determine the identity against which user security rules should be evaluated.

The installed application privileges can be reviewed with:

SHOW GRANTS TO APPLICATION CASABASE_CUBE;

Substitute the name of your installed Casabase Cube application where appropriate.

Application Roles

Casabase Cube provides two primary application roles:

CUBE_PUBLIC
CUBE_ADMIN

CUBE_PUBLIC provides query and discovery capabilities.

CUBE_ADMIN inherits CUBE_PUBLIC and adds modeling and administrative functionality, including security administration.

Conceptually:

CUBE_ADMIN
    │
    └── inherits
          │
          ▼
     CUBE_PUBLIC

Application roles determine what the user can do.

They do not by themselves define which members that user can see.

See Roles and Privileges for the complete role model.

Row-Level Security

Casabase Cube row-level security restricts the multidimensional data visible to individual users.

It is:

Configured per dimension
        +
Granted per user
        +
Evaluated at query time

A security rule associates a user with a member in a secured dimension.

The hierarchy then determines the scope represented by that grant.

Security Is Opt-In Per User

A user is filtered only when both of the following are true:

1. At least one dimension on the cube has security enabled.
2. The user has at least one active security rule on the cube.

The complete behavior is:

Dimension secured?	User has active rule?	Result
No	No	Full access
No	Yes	Full access; rule is inert
Yes	No	Full access
Yes	Yes	Filtered to the user’s grants

The third case is the one most likely to be misunderstood:

Security Enabled on Dimension
          +
User Has No Active Rules
          │
          ▼
Full Casabase Cube Access

Enabling security on a dimension makes that dimension eligible for restriction. It does not automatically restrict every user.

Why Security Is Opt-In

This behavior is deliberate.

With a deny-by-default model, enabling security on an existing dimension would immediately remove access for every user until grants had been created for all of them.

Casabase Cube instead allows security to be introduced incrementally:

Enable Security
      │
      ▼
Existing Users Continue to Work
      │
      ▼
Add Rules for Users Who Need Restriction
      │
      ▼
Validate Each Scope

This makes security rollout gradual and reversible.

The tradeoff is operational: a user intentionally left unrestricted is technically indistinguishable from a user who should have been restricted but never received a rule. The architecture therefore requires explicit review of users who have application access but no active security rules.

Active Rules Matter

Only active security rules participate in filtering.

A deactivated rule is ignored.

This creates an important consequence:

User Has One Active Rule
        │
        ▼
Restricted

If that final rule is deactivated:

No Active Rules
        │
        ▼
Unrestricted

Deactivating a user’s final rule does not lock the user out. It removes Casabase Cube row-level restriction.

To remove the user’s application access entirely, revoke the relevant Snowflake/application-role access instead.

Rules Are Per User

Casabase Cube row-level security rules are associated with individual users.

They are not inherited from Snowflake account-role membership.

Conceptually:

Snowflake Role
     │
     └── Grants access to Casabase Cube


Casabase Cube Security Rule
     │
     └── Defines member scope for a user

Adding a user to a Snowflake role that has CUBE_PUBLIC allows that user to use Casabase Cube, but it does not automatically create a member-level security scope.

If that user should be restricted, the appropriate Casabase Cube security rule must also exist.

Dimension Security

Security enablement is a property of a cube dimension.

For example:

ENTITY       Secured
DEPARTMENT   Secured
PERIOD       Not Secured
MEASURES     Not Secured

Any dimension can be secured, although organizational dimensions such as Entity, Cost Center, or Department are common candidates.

Each secured dimension adds another security constraint to query processing.

Security Scope

A member grant conveys:

Granted Member
      +
All Descendants

at full value.

For example:

Total Entity
├── North America
│   ├── United States
│   └── Canada
└── Europe

A grant on:

North America

provides access to:

North America
├── United States
└── Canada

The user does not require separate grants for every descendant.

Multiple Grants

Multiple grants in the same dimension are combined.

For example:

Grant 1
└── North America

Grant 2
└── Europe

produces:

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

Conceptually, multiple grants within one dimension behave as a union.

Shared and Alternate Members

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

A grant on a shared member therefore conveys the same underlying leaves as a grant on the corresponding original member.

This prevents alternate hierarchy placement from creating a separate security identity for the same underlying business member.

Security Across Dimensions

Restrictions across secured dimensions apply together.

For example:

ENTITY
└── North America

and:

PRODUCT
└── Consumer Products

produce an effective scope of:

North America
      AND
Consumer Products

Conceptually:

ENTITY Scope
     │
     ├──────────┐
     │          │
     ▼          ▼
North America   AND   Consumer Products
                         ▲
                         │
                    PRODUCT Scope

The readable fact population is the intersection of the permitted scopes.

Ancestors Remain Visible

A member above a user’s granted branch can remain visible even though the user cannot access all of its descendants.

Its value is calculated only from permitted leaves.

For example, suppose:

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

An unrestricted user sees:

Promotions      94,503

A user granted only Coupon can see:

Promotions       1,247
Coupon           1,247

The Promotions member remains visible, but it represents a partial rollup over the user’s permitted leaves.

Partial Rollups Are Not Flagged

The partial parent value is intentionally returned as the value of that member.

It is not labeled:

Partial
Restricted
Incomplete

This means:

Same Member Name
       │
       ├── User A: 94,503
       └── User B: 1,247

can be valid behavior.

The value of an aggregate on a secured cube can therefore depend on who requested it.

When a report requires a true complete total, security should be granted at a hierarchy level where the complete population for that total is available.

Silent Filtering

Restricted members are silently omitted.

For example, a broad query such as:

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

can return the full hierarchy for an unrestricted user and only the permitted branch for a restricted user.

Casabase Cube does not normally return an error revealing that other members were requested but denied.

This avoids using access-denied messages as a mechanism for discovering the existence of restricted members.

Security Modes

Each secured dimension has a:

SECURITY_MODE

The default and supported mode is:

EXCLUDE

MASK is also supported, with important limitations.

EXCLUDE

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

Conceptually:

Full Leaf Population
        │
        ▼
Remove Restricted Leaves
        │
        ▼
Permitted Leaf Population
        │
        ▼
Aggregate

Parents are then calculated from the remaining permitted leaves.

This is why restricted users receive partial rollups.

For example:

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

If a user can access only:

A
B
C

then:

Total Entity

is calculated from:

A + B + C

not from all five children.

MASK

MASK follows a different contract.

Instead of returning a partial value where the calculation touches data the user cannot access, MASK returns a no-access marker.

However, MASK is refused when the query requires calculated members.

A formula evaluated only over granted leaves would naturally produce a partial result, which conflicts with the semantics of MASK. Rather than return a misleading value, Casabase Cube refuses the query.

For this reason, EXCLUDE is the supported default and should be used unless there is a specific reason to use another mode and the affected query patterns have been validated.

Where Security Is Enforced

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

QUERY_CUBE
QUERY_CUBE_PIVOT_JSON
<CUBE>_FACT_SECURE
<CUBE>_DIMENSIONS
Formula Evaluation
Scheduled Saved Query Execution

There is not a separate unsecured direct-query path around the same cube data.

Query Engine Security

For calculation-engine queries, security scope is established before aggregation and formula calculation.

The sequence is:

Resolve POV
     │
     ▼
Determine User Scope
     │
     ▼
Permitted Leaves
     │
     ▼
Aggregate
     │
     ▼
Calculate Formulas
     │
     ▼
Return Result

This ordering ensures that downstream calculations operate only on the user’s permitted population.

Secure Fact View

The secure fact view:

<CUBE>_FACT_SECURE

applies the same user security scope when exposing stored fact rows.

It provides relational access to permitted stored data.

The view does not evaluate calculated members or multidimensional aggregation logic.

Secure Dimension View

The secure dimension view:

<CUBE>_DIMENSIONS

provides security-aware access to supported hierarchy metadata.

This prevents a relational metadata interface from becoming an alternate path around the cube’s security model.

Formula Security

Security is applied before formula evaluation.

A formula therefore cannot retrieve a value the executing user could not retrieve directly.

The authoritative Architecture guide documents a direct test where a formula explicitly referenced a denied member. The unrestricted user received the actual value, while the restricted user did not receive the denied value. A formula reference to an allowed member continued to resolve normally.

The formula rule is:

Formula references permitted member
        │
        ▼
Permitted value

Formula references denied member
        │
        ▼
Restricted value unavailable

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

Formulas are security-scoped, not security-exempt.

Scope-Dependent Formulas

A formula can still produce different answers for users with different security scopes.

For example:

Share of Total
=
Current Value / Total

A fully scoped user’s denominator can represent the entire population.

A restricted user’s denominator can represent only permitted leaves.

The formula remains secure, but the result is scope-dependent.

This is an architectural consequence of applying security before calculation:

Security Before Calculation
        │
        ├── Prevents restricted-data leakage
        │
        └── Allows calculations over partial operands

This is an important architectural tradeoff.

Materialized Results

A scheduled Saved Query is evaluated under the identity that executes it.

Casabase Cube security applies during that execution.

The result is then written to a normal Snowflake table.

Conceptually:

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

After the table is written, consumers are reading the table rather than the cube.

At that point:

Snowflake Table Grants

control access.

Casabase Cube row-level security does not dynamically reevaluate for every reader of the materialized table.

Materialization Design Consequence

Do not use one materialized table to serve consumers who require different Casabase Cube security scopes.

For example:

Scheduled Query Runs as Full-Scope User
                 │
                 ▼
          Full-Scope Table
                 │
        ┌────────┴────────┐
        ▼                 ▼
 Restricted User      Full User

Both users would be reading the same table contents.

If per-user cube security is required, either:

Query Casabase Cube directly

or:

Materialize separate appropriately scoped tables

for the intended audiences.

Security Is Evaluated Live

Security configuration is read at query time.

A security-rule change therefore takes effect on the next query.

There is no security cache or cube rebuild required simply because a rule changed.

Conceptually:

Change Security Rule
       │
       ▼
Next Query
       │
       ▼
New Scope Applied

This allows access changes to take effect immediately within normal Snowflake query execution.

Security vs. Application Access

Removing row-level rules is not the same as removing application access.

Consider:

User
├── CUBE_PUBLIC
└── No Security Rules

That user can query Casabase Cube and is unrestricted by Casabase Cube row-level security.

To remove access:

Revoke Snowflake/Application Role

rather than:

Delete Security Rules

Deleting the user’s final security rule while leaving CUBE_PUBLIC access in place can increase that user’s effective cube scope.

Security Review Requirement

Because absence of a rule means unrestricted access, administrators should explicitly review users who are querying secured cubes without active rules.

The authoritative Architecture guide provides this example control query:

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 returned user is querying that cube without active row-level restrictions.

That can be intentional, but it should be understood and reviewed.

Security Architecture Tradeoffs

The opt-in model has deliberate benefits and consequences.

Architectural Decision	Benefit	Consequence
Security is opt-in per user	Security can be rolled out incrementally without breaking every existing user	Users without rules must be actively reviewed
Hierarchy grants include descendants	Security can be managed at meaningful business branches	Hierarchy placement affects effective scope
Ancestors remain visible	Restricted users can still navigate meaningful reporting structures	Ancestor values can be partial totals
Security applies before formulas	Formulas cannot expose denied data	Ratios and other formulas can use partial operands
Filtering is silent	Restricted member existence is not revealed through errors	Users may not know a result represents only their permitted scope
Security is evaluated live	Rule changes take effect immediately	Access changes can alter results without rebuilds
Materialization resolves security at execution time	Calculated output can be reused efficiently	Result-table access must be governed separately in Snowflake

These are not implementation accidents. They are part of the security contract consumers and administrators should understand.

Security Reviewer Summary

For security and architecture reviews, the key properties are:

• Casabase Cube executes within the customer’s Snowflake account.
• It uses Snowflake identity rather than maintaining separate user credentials.
• Source data is read through grants provided by the customer.
• Row-level security is opt-in per user.
• A user with no active security rules is unrestricted by Casabase Cube row-level security.
• Security rules are assigned per user rather than inherited from account roles.
• Member grants include descendants.
• Ancestors can remain visible with partial rollups.
• Security is applied consistently across supported cube read paths.
• Security is established before aggregation and formula evaluation.
• Formulas cannot retrieve denied values.
• Calculations can legitimately differ between users because their permitted operands differ.
• Security-rule changes take effect on the next query.
• Materialized Saved Query results become ordinary Snowflake tables after execution.
• READ SESSION is required so the application can evaluate the executing Snowflake user.
• Application roles control functionality; security rules control cube-data scope.

Together, these properties define the security boundary that security reviewers should evaluate.

Key Principle

The Casabase Cube row-level security model can be summarized in one sentence:

A user is filtered only when security is enabled on the cube and that user has an active security rule. A user with no active rules is unrestricted by Casabase Cube row-level security.

From there, the rest of the model follows:

Determine User
      │
      ▼
Does Security Apply?
      │
      ├── No ──► Full Cube Scope
      │
      └── Yes
             │
             ▼
      Resolve Granted Members
             │
             ▼
       Include Descendants
             │
             ▼
       Permitted Leaf Scope
             │
             ▼
       Aggregate / Calculate
             │
             ▼
          User Result

Related Topics

• High-Level Architecture
• Query Architecture
• Hierarchy Capabilities
• Formula Capabilities
• Data Storage & Boundaries
• Roles and Privileges
• Access Control
• Audit Log