Data Security

Mondrian uses a role-based security model to restrict access to data. Users are assigned to roles, and each role defines what data they can see within the OLAP cube. This allows a single analytics database to serve multiple user types while showing each user only their authorized data.

Roles

Mondrian uses a role-based security model to restrict access to data. Users are assigned to roles, and each role defines what data they can see within the ROLAP cube. Consider a sales manager role:

individuals in this position need visibility into their team's performance metrics, product-specific sales figures, and key customer accounts. To fulfill these responsibilities, the sales manager requires access to data spanning products, sales transactions, customer information, and related dimensions.

Within Mondrian, roles must be explicitly defined in the schema where they will be enforced. Creating a role is straightforward—simply declare a Role element and specify its name attribute to identify it.

<!-- Inventory manager role -->
<Role name="Inventory Manager">
  <grants>...</grants>
</Role>

<!-- Product manager role -->
<Role name="Product Manager">
  <grants>...</grants>
</Role>

<!-- US sales manager role -->
<Role name="US Sales Manager">
  <grants>...</grants>
</Role>

<!-- WA state sales manager role -->
<Role name="WA Sales Manager">
  <grants>...</grants>
</Role>

<!-- OR state sales manager role -->
<Role name="OR Sales Manager">
  <grants>...</grants>
</Role>

<!-- ID state sales manager role -->
<Role name="ID Sales Manager">
  <grants>...</grants>
</Role>

<!-- Union role combining General Sales Manager and Product Manager -->
<Role name="Product and Sales Manager">
  <Union>
    <RoleUsage roleName="General Sales Manager"/>
    <RoleUsage roleName="Product Manager"/>
  </Union>
</Role>

Role configuration in Pentaho Mondrian requires establishing a connection between Pentaho's authentication system and Mondrian's security layer. This is achieved through a role mapper component.

Configuration Location:

File: pentahoObjects.spring.xml
Path: pentaho-solutions/system directory
Bean ID: Mondrian-UserRoleMapper

The role mapper translates Pentaho user roles into corresponding Mondrian roles, enabling Mondrian to enforce the appropriate security grants defined in your schema.

Security Warning: Without a configured role mapper, Mondrian defaults to unrestricted access - all users can view all data regardless of their Pentaho roles. Always configure a role mapper to ensure proper data security.

Pentaho includes three built-in role mapper types to accommodate different security requirements and organizational structures:

One-to-One Role Mapper

The one-to-one role mapper is the most straightforward mapping approach. It directly passes Pentaho user roles to Mondrian without any transformation. For example, if a user has a "Sales Manager" role in Pentaho, Mondrian receives that exact same "Sales Manager" role.

This mapper is widely used because it works seamlessly with existing organizational role structures—there's no need to create separate role names or maintain complex mapping logic between Pentaho and Mondrian.

Security Parameter: failOnEmptyRoleList

This mapper includes an important security parameter that controls behavior when a user has no matching Mondrian roles:

Default (Recommended): The mapper throws an exception if no role mapping is found, preventing unauthorized access. This is the secure configuration.
Alternative Setting: If set to false, users without matching roles will be granted full permissions to all data—effectively the same as having no security configured at all. This setting should be avoided in production environments.

Best Practice: Leave the default behavior enabled to ensure that only users with explicitly defined roles can access your Mondrian data.

<bean id="Mondrian-UserRoleMapper"
name="Mondrian-One-To-One-UserRoleMapper"
class="org.pentaho.platform.plugin.action.mondrian.mapper.MondrianOneToOneUserRoleListMapper"
scope="singleton" />
...

Lookup

The lookup-map role mapper provides a translation layer between Pentaho's role namespace and Mondrian's role definitions. This mapper is essential when role nomenclature differs between systems or when consolidating multiple organizations with distinct role naming conventions onto a unified Mondrian schema.

Configuration: Define mappings as key-value pairs where the key represents the Pentaho role identifier and the value represents the target Mondrian role. During connection establishment, Pentaho resolves the user's roles through this lookup table and transmits the mapped role names to Mondrian's security engine.

This approach allows you to maintain separate role naming conventions in Pentaho while standardizing role definitions within your Mondrian schemas.

<!-- This sample mapper assumes that a translator is needed (in the form of a Map) to map a platform role to a Mondrian role.
Note- Key = platform role, value = Mondrian role -->

<bean id="Mondrian-UserRoleMapper"
name="Mondrian-SampleLookupMap-UserRoleMapper"
class="org.pentaho.platform.plugin.action.mondrian.mapper.MondrianLookupMapUserRoleListMapper"
scope="singleton">
<property name="lookupMap">
     <map>
       <entry key="Power User" value="Power user" />
     </map>
   </property>
 </bean>
...

User Session

The user-session role mapper retrieves Mondrian role assignments dynamically from a user's session attribute. This approach allows role definitions to be determined at runtime rather than through static configuration.

How It Works:

When Pentaho establishes a connection to Mondrian, the mapper performs the following sequence:

Accesses the user's active session
Retrieves the specified session attribute
Extracts the role value(s) from that attribute
Passes those roles to Mondrian for security enforcement

This dynamic approach is particularly useful when roles need to be calculated or retrieved from external systems during the login process.

Configuration:

The only required configuration is specifying which session attribute contains the role information. For example, if your session attribute is named MondrianUserRoles, you would configure the mapper to read from that attribute. The mapper will then automatically extract and apply whatever role values are stored there.

<!-- This sample mapper assumes that every user has their mondrian roles in their session under then named session variable. -->
<bean id="Mondrian-UserRoleMapper" 
name="Mondrian-SampleUserSession-UserRoleMapper" 
class="org.pentaho.platform.plugin.action.mondrian.mapper.MondrianUserSessionUserRoleListMapper" 
scope="singleton">
<property name="sessionProperty" value="MondrianUserRoles" />
  </bean>
...

Security Grants

Suppose you only want the product manager to see the state, item, and quantity purchased. Next, you want the state sales manager to see all of the same data as the US sales manager, but only for the one state. Mondrian security grants can be thought of as a set of filters on the data, and the role can only see what their filters let through. At each level in the schema, the user can have data explicitly restricted or shown.

Level

Scope

Purpose

SchemaGrant

Entire schema

Top-level access control

CubeGrant

Individual cubes

Cube-specific restrictions

DimensionGrant / HierarchyGrant

Dimensions & hierarchies

Dimensional filtering

MemberGrant

Specific members

Fine-grained member access

Note: that when a role is granted access to something, it’s implicitly given access to the parent. This means that if you use an access type of none for a schema and then grant access to a cube, the role now has access to the schema as well. In this case, an access type of none is a shortcut to taking away access from all other cubes except the one(s) specified.

SchemaGrant

The SchemaGrant is the first and highest level of security control in Mondrian. It has a single attribute called access that determines whether users can see the schema at all.

Three access options are available: all, none, and all_dimensions. However, only all and none are commonly used in practice. The all_dimensions option behaves identically to none and is scheduled for removal in future versions, so it can be safely ignored.

SchemaGrant all

It gives the role access to all of the cubes and dimensions in the schema, but you can later limit access to all or parts of the data using finer detailed grants. Other grants are nested within the schema grant.

<Role name="Product Manager">
  <SchemaGrant access="all">
    <!-- Additional grants can restrict further -->
  </SchemaGrant>
</Role>

SchemaGrant none

This option is used when you want to restrict a user from seeing the schema completely. For example, maybe you have a schema completely dedicated to Human Resources and want to limit it from everyone except HR.

<Role name="Product Manager">
  <SchemaGrant access="none">
  </SchemaGrant>
</Role>

CubeGrant

The CubeGrant takes two attributes: the name of the cube that the grant applies to and the access control for the grant. There are only two options for cube grant access: all or none. Both work similarly to the schema grant, but at the cube level.

CubeGrant all

The all option gives the role access to the cube. If a user has no access to the schema, this gives access to the particular cube but no others.

<Role name="Product Manager">
  <SchemaGrant access="none">
    <CubeGrant cube="Product Sales" access="all">
      <!-- User sees Product Sales Cube but no others -->
    </CubeGrant>"/>
  </SchemaGrant>
</Role>

CubeGrant none

A CubeGrant of none means that a user who is in the given role is not given access to the cube. Unlike with the schema grant, once access to the cube has been taken away, the user can’t see any of the cube data.

<Role name="Product Manager">
  <SchemaGrant access="all">
  <!-- User sees all the schemas -->
    <CubeGrant cube="Human Resources" access="none">
      <!-- User does not have access to HR Cube -->
    </CubeGrant>
  </SchemaGrant>
</Role>

DimensionGrant

The Dimension Grant has two required attributes: dimension, the name of the dimension, and access, which can be either all or none. An access of all doesn’t usually add a lot of value, because it’s the default, so you’ll typically only use none. Dimension grants also can’t have any children. If you want finer-grained control over the contents of a dimension, you’ll need to use a hierarchy grant.

<Role name="Product Manager">
  <SchemaGrant access="none">
  <!-- Deny access to all schemas -->
    
    <CubeGrant cube="Product Sales" access="all">
    <!-- User now has access to Product Sales Cube -->
          
       <DimensionGrant dimension="[Location]" access="all">
       <!-- Allow access to Location Dimension -->
       <DimensionGrant dimension="[Customer]" access="none">
       <!-- Deny access to Customer Dimension -->
       
    </CubeGrant>    
  </SchemaGrant>
</Role>

HierarchyGrant

The HierarchyGrant has two required attributes: hierarchy, the name of the hierarchy, and access. The name of the hierarchy can be either the full name of the hierarchy or, if the hierarchy name follows the conventions of Mondrian and there is only one, just the dimension name.

For example, if the dimension is named [Product] and the hierarchy is named [Products], it is enough to set the hierarchy name to [Product]. But if you have multiple hierarchies, such as [Org Structure.Financial] and [Org Structure.Reporting], you’d need to specify the full name for the hierarchy you want to use.

HierarchyGrant all

All is used when you want to grant access to the entire hierarchy and all its members. All is the default for hierarchies, so it’s rarely explicitly set.

<Role name="Product Manager">
  <SchemaGrant access="none">
  <!-- Deny access to all schemas -->
    
    <CubeGrant cube="Product Sales" access="all">
    <!-- User now has access to Product Sales Cube -->
          
       <HierarchyGrant hierarchy = "[Product].[Products]" access="all">
       <!-- Allow access to Product Hierarchy -->
       
    </CubeGrant>    
  </SchemaGrant>
</Role>

HierarchyGrant none

The hierarchy access of none restricts a user from seeing a hierarchy, including any of the levels or members in the hierarchy.

<Role name="Product Manager">
  <SchemaGrant access="none">
  <!-- Deny access to all schemas -->
    
    <CubeGrant cube="Product Sales" access="all">
    <!-- User now has access to Product Sales Cube -->
          
       <HierarchyGrant hierarchy="[Product].[Products]" access="none">
       <!-- Deny access to Product Hierarchy -->
       
    </CubeGrant>    
  </SchemaGrant>
</Role>

Optional Attributes - Top & Bottom

HierarchyGrant includes two optional attributes - topLevel and bottomLevel - that create access boundaries within a hierarchy. Both require access="custom" to function.

topLevel: Hide Upper Levels

Prevents users from viewing data above a specified level.

Purpose: Block access to overly aggregated or organization-wide summaries

Example: Restrict managers to Business Unit level, hiding enterprise-level totals

bottomLevel: Hide Lower Levels

Prevents users from viewing data below a specified level.

Purpose: Show trends and summaries while hiding granular details

Example: Let sales people see regional performance but hide individual salesperson metrics

Result: Controlled Viewing Range

Together, these attributes define which hierarchy levels are visible—everything above topLevel and below bottomLevel remains hidden.

<HierarchyGrant hierarchy="[Location]" 
                access="custom"
                topLevel="[Location].[Country]"
                bottomLevel="[Location].[City]">
  <!-- User can only see Country to City levels -->
</HierarchyGrant>

MemberGrant

Member grants provide finer-grained control to dimensions than hierarchy grants. The role has access to the dimension but can only see the specific members that it is given access to.

<Role name="Sales Manager - WA">
  <SchemaGrant access="none">
  <!-- Deny access to all schemas -->
    
    <CubeGrant cube="Product Sales" access="all">
    <!-- User now has access to Product Sales Cube -->
       <HierarchyGrant hierarchy="[Location]" access="custom">
          
         <MemberGrant member="[Location].[Country].[USA]" access="none">1((mg_no_usa_access))>
         <!-- Deny access to USA -->
         <MemberGrant member="[Location].[State].[WA]" access="all">
         <!-- Grant access to Sate WA -->
       
    </CubeGrant>    
  </SchemaGrant>
</Role>

Member Grant Rules (Order Matters!)

Grants are order-dependent: If you grant access to a child, then deny the parent, the child becomes inaccessible. For example, if you create a member access that can see [USA].[CA] and then deny access to [USA], the role will no longer be able to see [USA].[CA].
Grants inherit: Denying [USA] also denies all states within USA. For example, if you deny access to [USA], all of the child members are also denied access because access to the children requires access to the parent. But access to children can be granted later. This allows you to block access to a set of members and then only give access back to a limited few.
Parents are implicitly granted access: Granting [WA] also grants access to [USA] parent. This follows the rule on inheritance. In order to reach [USA].[WA], for example, you need to first access [USA].
Member grants don’t override topLevel and bottomLevel attributes: at the hierarchy grant level. This means that even if you grant access to an individual store in a state, but you set a bottom level of the city that the store is in, you’ll still only see down to the city level.
Result of example above: User can see USA and WA, but no other states

Below is a table that outlines the possible combination access rights which determine the dataset displayed in the report.

[USA] access

[WA] Access

State members

none

Not Specified

{}

all

Not Specified

{[CA],[ID],[OR],[WA]}

none

all

{[WA]}

none

{}

all

none

{}

all

{[WA]}

Rollup Policy

The Problem: What happens to parent totals when a role can only see some of the children?

A rollup policy controls how Mondrian calculates aggregate values when a user's role restricts access to certain child members. This becomes critical when you want to prevent users from deducing hidden data through mathematical inference.

Real-World Scenario

Setup:

Hugo's role allows him to see California and Oregon sales data
Hugo cannot see Washington sales data
Hugo queries USA total sales and its states

The Question: Should the USA total include Washington's sales (which Hugo cannot see)?

To remedy this, a role can apply a different rollup policy to a hierarchy. The policy describes how a total is calculated for a particular member if the current role can only see some of that member's children:

Policy

Parent Total Includes

Can Deduce Hidden Values?

Best For

full

All children (visible + hidden)

Yes

Low-security scenarios with many children

partial

Only visible children

Most common use case; intuitive for users

hidden

Nothing (total hidden)

High-security scenarios; sensitive aggregates

Full Policy - Default

The total for that member includes all children. This is the default policy if you don't specify the rollupPolicy attribute.

Store                Unit Sales
[USA]                266,773      ← Includes hidden WA sales (124,366)
  [USA].[CA]         74,748       ← Visible
  [USA].[OR]         67,659       ← Visible
  [USA].[WA]         (hidden)     ← Not displayed

Hugo's Query Results:

Issue: Hugo can calculate the hidden value: 266,773 - 74,748 - 67,659 = 124,366

When to use: When hiding data isn't critical, or when there are too many children to deduce hidden values.

Partial Policy

The parent total includes ONLY the children the user can access.

Store                Unit Sales
[USA]                142,407      ← Only CA + OR (74,748 + 67,659)
  [USA].[CA]         74,748       ← Visible
  [USA].[OR]         67,659       ← Visible
  [USA].[WA]         (hidden)     ← Not displayed

Hugo's Query Results:

Benefit: Hugo cannot deduce Washington's sales. The USA total accurately reflects only what he can see.

When to use: When users should only see aggregates of their authorized data. Most intuitive for end users.

Hidden

The parent total is completely hidden if ANY children are inaccessible.

Store                Unit Sales
[USA]                -            ← Hidden because WA is inaccessible
  [USA].[CA]         74,748       ← Visible
  [USA].[OR]         67,659       ← Visible
  [USA].[WA]         (hidden)     ← Not displayed

Hugo's Query Results:

Benefit: Maximum security—Fred cannot deduce anything about hidden data.

When to use: When aggregate values themselves are sensitive, or when you want to completely obscure the existence of restricted data.

Rollup Policy - Example

Rollup policies are set per hierarchy within each role. Different hierarchies can have different policies.

<Role name="Regional Sales Manager">
  <SchemaGrant access="none">
    <CubeGrant cube="Sales" access="all">
      
      <!-- Store hierarchy: partial rollup policy -->
      <HierarchyGrant hierarchy="[Store]" 
                      access="custom" 
                      rollupPolicy="partial"
                      topLevel="[Store].[Store Country]">
        <MemberGrant member="[Store].[USA].[CA]" access="all"/>
        <MemberGrant member="[Store].[USA].[CA].[Los Angeles]" access="none"/>
      </HierarchyGrant>
      
      <!-- Customers hierarchy: full rollup policy -->
      <HierarchyGrant hierarchy="[Customers]" 
                      access="custom" 
                      rollupPolicy="full"
                      topLevel="[Customers].[State Province]"
                      bottomLevel="[Customers].[City]">
        <MemberGrant member="[Customers].[USA].[CA]" access="all"/>
        <MemberGrant member="[Customers].[USA].[CA].[Los Angeles]" access="none"/>
      </HierarchyGrant>
      
      <!-- Gender hierarchy: completely hidden -->
      <HierarchyGrant hierarchy="[Gender]" access="none"/>
      
    </CubeGrant>
  </SchemaGrant>
</Role>

Result:

Store totals show only accessible children (partial)
Customer totals include all children (full)
Gender dimension is completely invisible
Both hierarchies respect topLevel/bottomLevel restrictions

PreviousNamed Sets NextMondrian Security

Was this helpful?