[Mondrian] XMLA Security

Julian Hyde julianhyde at speakeasy.net
Wed Mar 21 05:48:15 EDT 2007

You should extend SchemaReader. It shouldn't be that painful for
existing code - implementations generally extend DelegatingSchemaReader
or RolapSchemaReader, so they wouldn't have to do any extra work.
Note that if you grant access to a member of a hierarchy, you implicitly
see all of its ancestors. E.g. if you give access to San Francsisco, you
see California and USA. Unless, that is, you set top-level to City or
When you've done the code changes, send me a zip file and I'll check
them in. As part of your code change, please document the rules you are
implementing in schema.html, and add tests in AccessControlTest.


From: mondrian-bounces at pentaho.org [mailto:mondrian-bounces at pentaho.org]
On Behalf Of Pedro Casals
Sent: Tuesday, March 20, 2007 12:20 PM
To: Mondrian developer mailing list
Subject: Re: [Mondrian] XMLA Security

I agree, it's easier to manage things through SchemaReader. However,
there are some methods missing: I've seen
schemaReader.getHierarchyLevels(hierarchy) (for Hierarchy.getLevels())
but not getLevelDepth, getDimensions, etc.
How would you feel if I added these methods to the SchemaReader
interface? I kown changing interfaces is hard for all those that have
implemented functionalities based on the interface, but extending the
interface to a new interface like SecuritySchemaReader would make thing
quite confusing, wouldn't it?
Tell me the way you prefer

----- Mensaje original ----
De: Julian Hyde <julianhyde at speakeasy.net>
Para: Mondrian developer mailing list <mondrian at pentaho.org>
Enviado: sábado, 17 de marzo, 2007 1:08:03
Asunto: RE: [Mondrian] XMLA Security



From: mondrian-bounces at pentaho.org [mailto:mondrian-bounces at pentaho.org]
On Behalf Of Pedro Casals
Sent: Friday, March 16, 2007 4:34 AM
To: mondrian at pentaho.org
Subject: [Mondrian] XMLA Security

I'm working on mondrian XMLA security and I have some doubts: The
scenario is that you have a role that restricts the access to the two
upper levels of an hierarchy (this hierarchy has four levels).
1st. I belive that the XMLA client should not be aware that this
hierarchy has 4 levels. Do yo agree? This is the way JPivot is working.


Seems reasonable. How can a restricted client tell that there are 4
levels right now? I'm guessing (a) the Hierarchy.getLevels() method and
(b) the Level.getDepth() method. We could add versions of those methods
to SchemaReader, and make jpivot/xmla call them.

2nd. Provided you agree with the previous point, what do you think would
be the best strategy?: On one hand, upon cube defition load we could
arrange the cube definition to match the role restriction. On the other
hand, we could go on all XMLA request and filter it.
Doing it with the first strategy, it looks like its easier to manage.
However, I see pooled cubes and I do not know if these pooled cubes are
shared among several XMLA clients. Should this be the case, we should
have to go through the second way.
Doing it the second strategy, we have to deal with all different XMLA
requests, which should take more work, but looks safe, since no one
could workaround security writing direct MDX. 

It's laudable to create an entire metadata API which includes
access-control. But it's a lot of work. We took the simpler route, which
is the SchemaReader interface.
So, the client (XMLA or JPivot) is an 'insider'. It is allowed full
access to the catalog, but for things it is displaying to the user, it
uses the SchemaReader facade.

3rd. Is there a way to restrict a measure to a role? 

You can restrict access to any given set of members in a hierarchy. That
includes the Measures hierarchy.
Take a look at the AccessControlTest. That is the spec. Anything you
need but which isn't tested, please add and contribute. If anything
doesn't work, contribute the test and log a bug.
Mondrian mailing list
Mondrian at pentaho.org


LLama Gratis a cualquier PC del Mundo.
Llamadas a fijos y móviles desde 1 céntimo por minuto.

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

More information about the Mondrian mailing list