[Mondrian] XMLA Security

[Pedro Casals]

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

Pedro


----- 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


Hello:
 
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.
 
Julian
_______________________________________________
Mondrian mailing list
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.pentaho.org/pipermail/mondrian/attachments/20070320/1244c3dc/attachment.html