[Mondrian] Re: Role based security and calculated members

Julian Hyde julianhyde at speakeasy.net
Wed Aug 15 18:57:06 EDT 2007

First of all, make sure that this really is a security issue, not
information hiding. Often people want to hide things to reduce information
overload, not because of any security concern. If this is the case, the best
solution is to tag dimensions and members as 'hidden', and make the UI
comply with those tags -- don't use access-control at all.
It's alarming that you can use a restricted dimension from within a
calculated member, but I can see that it is also powerful in some
situations. It is analogous to the access control in databases such as
Oracle, where you can create a view on a table and give a user access to
that view even though they cannot see the table. It is an effective way of
giving fine-grained access control.
Access-control should apply to calculated members. If it doesn't please log
a bug. It should be possible to explicitly grant access to calculated
It should definitely be a bug if you can use a restricted dimension from
within a calc member defined in a query. That's a big security loophole. Can
you log a bug if that is the case.
If you can use a restricted dimension within a calc member defined as part
of the cube (i.e. in the schema file) the security aspects are much less
worrying, because presumably the cube designers know what they are doing.
But sometimes you would want to apply access control (say to only sum the
visible children of a member) and sometimes you would want to ignore it (so
you could see dimensions which are invisible to the end user). So ideally
you would need to be able to specify whether a calc member in a cube is
<Cube name="Sales">
   <CalculatedMember name="Foo" accessControlled="false">
   <CalculatedMember name="Bar" accessControlled="true">
In the above "Foo" and "Bar" would give different results if you are running
in a role which has restricted access to the Product dimension.
Given these bugs and missing features, your strategy is the right one to use
today. If we fix the bugs, I will be sure to add the features to make your
use case work; you will have to change your app a bit, but not too much. I'd
appreciate if you could log a bug for the missing/broken functionality. Also
create testcases to capture the current behavior you are relying on (even if
it is broken!) so we will be aware of the impact of any future change.


From: mondrian-bounces at pentaho.org [mailto:mondrian-bounces at pentaho.org] On
Behalf Of Matt Campbell
Sent: Wednesday, August 15, 2007 1:52 PM
To: Mondrian at pentaho.org
Subject: [Mondrian] Re: Role based security and calculated members

Sorry-- I sent that last email accidentally before completing it.

We have a need to hide dimensions which are used only in the definitions of
calculated measures.  That is, end users want to be able to use certain
measures on reports, but not the dimensions that are used to define those
measures.  To do this we were thinking about using role based security and
set <HierarchyGrant access='none' ... >.  

Currently in Mondrian you can use a calculated member which is defined with
a dimension member, even if your role doesn't have access to that dimension.
That's actually good for us if we use this approach, but seems like it could
be considered a bug.  I don't want use this approach if the behavior is
changed to prevent access in this case. 

BTW-- it doesn't appear you can use a restricted dim in a calc mem in
Analysis Services 2K.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.pentaho.org/pipermail/mondrian/attachments/20070815/f01914e7/attachment.html 

More information about the Mondrian mailing list