[Mondrian] XMLA Security

Richard Emberson remberson at edgedynamics.com
Thu Apr 5 09:26:14 EDT 2007


I came upon a OLAP Security survey article (attached),
"Towards OLAP Security Design - Survey and Research Issues"
by Torsten Priebe and Bunther Pernul.
There is no standard. Some systems provide leaf level
data security only (showing full aggregates at non-leaf
levels which is of course a security hole) while others
carry the desired security from leaf level all the
way up to the 'All' level.
If your customers do not care about security, then you've
got lots of options. If they really want data/cell-level
security, choices are more limited.
We've got big customers with sophisticated and
modern OLAP security requirements. The notion that everyone
gets to see everything will not be acceptable.

Richard



Matt Campbell wrote:
> In AS2K you can set whether to use visual totals in the Role 
> definition.  It defaults to show the full aggregate total, but you can 
> change that on a dimension by dimension (and level by level) basis.
> 
> On 4/5/07, *Julian Hyde* <julianhyde at speakeasy.net 
> <mailto:julianhyde at speakeasy.net>> wrote:
> 
>     Can you also contribute a unit test, against the foodmart schema?
>     Code without a unit test is like a really cool Xmas present with no
>     batteries included! See mondrian.test.AccessControlTest and
>     mondrian.test.SchemaTest for some examples.
>      
>     I don't agree that members should be the total of only their
>     /visible /children. For example, if Fred has access to only
>     [USA].[CA].[San Francisco] and [USA].[CA].[Oakland], I think the
>     total for [USA].[CA] should include all cities in California.
>      
>     I don't deny that there are cases where you would only want to see
>     the total of the accessible cities. But in my opinion it shouldn't
>     be the default behavior. I think there is some way to write a
>     calculated member for that - I would be open to extending the
>     language to make that easier to achieve. Anyone know what MSAS does
>     here?
>      
>     Julian
> 
>         ------------------------------------------------------------------------
>         *From:* mondrian-bounces at pentaho.org
>         <mailto:mondrian-bounces at pentaho.org>
>         [mailto:mondrian-bounces at pentaho.org
>         <mailto:mondrian-bounces at pentaho.org>] *On Behalf Of *Pedro Casals
>         *Sent:* Wednesday, April 04, 2007 4:04 AM
>         *To:* Mondrian developer mailing list
>         *Subject:* Re: [Mondrian] XMLA Security
> 
>         Thanks to your hint I realized that code changes were small.
>         Since I have no access to CVS, I post here the changed classes.
>         All changes are marked with this comment: //PCF : role
>         Besides, I attach a default callback implementation and the
>         needed modification in web.xml.
>         I also attach the security role definition, that covers most of
>         the situations:
>         - Grant only some measures
>         - Deny a hole dimension.
>         - Deny part of an hierarchy, both in levels and members
>          
>         Pending:
>         JPivot is not placing the role in the HTTP header. I will ask to
>         Andreas which is his preferred approach, and my proposed solution.
>          
>         Known bug at this moment:
>         - Security role definition is order dependant, more than
>         specified in doc. For example: in my role definition, if the
>         definition of [Estructura Comercial] is placed before Dimension
>         definition, the latter is not taken into account!
>         - look at XMLA Security bug.xls attached file. If a member of a
>         level of an hierarchy is denied, the member is computed for the
>         totals of the ancestors (wich is wrong), but is not computed on
>         its own level (wich is correct).
>          
>         Pedro
>          
>         ----- Mensaje original ----
>         De: Julian Hyde <julianhyde at speakeasy.net
>         <mailto:julianhyde at speakeasy.net>>
>         Para: Mondrian developer mailing list <mondrian at pentaho.org
>         <mailto:mondrian at pentaho.org>>
>         Enviado: martes, 3 de abril, 2007 18:53:55
>         Asunto: RE: [Mondrian] XMLA Security
> 
>          
> 
>             **
>             The problem with this security role is that when I try to
>             retrieve all the children from [Estructura Comercial].[Toda
>             la Estructura].[01] I get none, because the code navigates
>             tries to solve the name one part at a time, but we do not
>             have access to [Estructura Comercial].[Toda la Estructura].
>              
>             Is it that the role definition is wrong or should I adjust
>             the code (which is really complicated!!!!) 
>              
> 
>         The code which looks up the member being granted should
>         definitely do so in a non-access-controlled context. By all
>         means adjust the code (and be sure to add a unit test for the
>         bug). Maybe use the global schema reader?
>          
>         Julian
>         _______________________________________________
>         Mondrian mailing list
>         Mondrian at pentaho.org <mailto:Mondrian at pentaho.org>
>         http://lists.pentaho.org/mailman/listinfo/mondrian
> 
> 
>         ------------------------------------------------------------------------
> 
>         LLama Gratis a cualquier PC del Mundo.
>         Llamadas a fijos y móviles desde 1 céntimo por minuto.
>         http://es.voice.yahoo.com
>         <http://us.rd.yahoo.com/mail/es/tagline/messenger/*http://es.voice.yahoo.com/>
> 
> 
>     _______________________________________________
>     Mondrian mailing list
>     Mondrian at pentaho.org <mailto:Mondrian at pentaho.org>
>     http://lists.pentaho.org/mailman/listinfo/mondrian
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Mondrian mailing list
> Mondrian at pentaho.org
> http://lists.pentaho.org/mailman/listinfo/mondrian


-- 
Quis custodiet ipsos custodes:
This email message is for the sole use of the intended recipient(s) and
may contain confidential information.  Any unauthorized review, use,
disclosure or distribution is prohibited.  If you are not the intended
recipient, please contact the sender by reply email and destroy all
copies of the original message.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: p33-priebe.pdf
Type: application/pdf
Size: 107827 bytes
Desc: not available
Url : http://lists.pentaho.org/pipermail/mondrian/attachments/20070405/6d6256dd/attachment.pdf 


More information about the Mondrian mailing list