[Mondrian] Re: Role based security and calculated members

Matt Campbell mkambol at gmail.com
Thu Aug 16 12:26:27 EDT 2007

Thanks for the detailed reply, Julian.  In our case we are simply trying to
hide information; this is not a security issue for us.  I wasn't aware that
there was a way to tag dimensions as hidden in the current implementation of
Mondrian.  There is an XMLA tag that can be set--DIMENSION_IS_VISIBLE, but
as far as I know there would be enhancement work necessary for Mondrian to
do anything with that tag.  Even if that were available, however, the UI we
are using does not appear to honor the DIMENSION_IS_VISIBLE property.  We'll
be leaning on the vendor to add support for this feature, but if that falls
through we may still need something like role based access to support

The particular test we ran was with a calculated member defined in a cube,
we have not tried defining the member in a query.  If we find that also is
allowed we'll log a bug.

On 8/15/07, Julian Hyde <julianhyde at speakeasy.net> wrote:
>  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
> members.
> 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
> access-controlled:
> <Cube name="Sales">
>    ...
>    <CalculatedMember name="Foo" accessControlled="false">
>       <Formula>Aggregate([Product].CurrentMember.Children)</Formula>
>    </CalculatedMember>
>     <CalculatedMember name="Bar" accessControlled="true">
>       <Formula>Aggregate([Product].CurrentMember.Children)</Formula>
>    </CalculatedMember>
> </Cube>
> 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.
> Julian
>  ------------------------------
> *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.
> _______________________________________________
> Mondrian mailing list
> Mondrian at pentaho.org
> http://lists.pentaho.org/mailman/listinfo/mondrian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.pentaho.org/pipermail/mondrian/attachments/20070816/6a51175b/attachment.html 

More information about the Mondrian mailing list