[Mondrian] Custom role injection

Brandon Jackson usbrandon at gmail.com
Sun Jan 6 18:11:36 EST 2013


Nice work Julian!  Really looking forward to trying this out.


Sent from my iPhone

On Jan 6, 2013, at 8:13 AM, William Back <wback at pentaho.com> wrote:

> This is great, Julian.  It will really simplify the way we do custom roles.  
> 
> I note that you specify 'session.state' when making the connection.  Does that mean that if the 'state' is set in the session it will also be automatically picked up?  Just trying to determine the right place to set that value.
> 
> Of course, now I need to rewrite the latter ½ of chapter 8.  But it's much cleaner and easier to explain.
> 
> Thanks,
> 
> Bill.
> 
> On Jan 5, 2013, at 8:22 PM, Julian Hyde <jhyde at pentaho.com> wrote:
> 
>> Mondrian developers,
>> 
>> So, this is what happens when my son takes a longer than usual nap on a Saturday....
>> 
>> I've just committed to the lagunitas branch (mondrian 4) an initial stab at custom role injection.
>> 
>> https://github.com/pentaho/mondrian/commit/e8a1ed9f518cfa68af5ae6893cb749950391c8f8
>> 
>> This change is designed to solve some of the problems with multi-tenancy. Previously people would use a dynamic schema processor or programmatic roles, sometimes both. Both of these have performance problems. Dynamic schema processor causes every tenant to have its own cache; programmatic roles are a black box to Mondrian, so Mondrian cannot see that it could just generate a simple WHERE clause to implement the access control constraint.
>> 
>> The ideas are described in http://jira.pentaho.com/browse/MONDRIAN-1281. The implementation isn't complete, but there's enough to do something useful.
>> 
>> Create a class that implements mondrian.spi.RoleGenerator, like this:
>> 
>>     package com.acme;
>> 
>>     import mondrian.spi.RoleGenerator;
>> 
>>     public class MyRoleGenerator implements RoleGenerator {
>>         public String asXml(Map<String, Object> context) {
>>             String state = (String) context.get("state");
>>             return "<Role name='role_" + state + "'>\n"
>>                 + " <SchemaGrant access='none'>\n"
>>                 + "  <CubeGrant cube='Sales' access='all'>\n"
>>                 + "   <HierarchyGrant hierarchy='[Store].[Stores]' access='custom' rollupPolicy='partial'>\n"
>>                 + "    <MemberGrant member='[Store].[Stores].[USA]' access='none'/>\n"
>>                 + (state != null
>>                    ? "    <MemberGrant member='[Store].[Stores].[USA].["
>>                    + state
>>                    + "]' access='all'/>\n"
>>                    : "")
>>                 + "   </HierarchyGrant>\n"
>>                 + "  </CubeGrant>\n"
>>                 + " </SchemaGrant>\n"
>>                 + "</Role>\n";
>>         }
>>     }
>> 
>> In your schema, define a role that uses that role generator:
>> 
>>                 <Role name='StateManager' className='com.acme.MyRoleGenerator'/>
>> 
>> Create a connection with 'Role=StateManager; session.state=CA' as part of the connect string. At the start of the connection, Mondrian calls the asXml method with the map {("state", "CA")}, and then converts the resulting XML into a role that will be used by that connection.
>> 
>> With custom role injection, you can now do access control for multi-tenancy without dynamic schema processor or programmatic roles. Include "tenant-id" (and any other pertinent information about the tenant) as part of the connect string parameters, and generate a role that can see only the members visible to that tenant. Every tenant will be working off the same schema (albeit with their own generated roles) and therefore they will share a cache. It doesn't happen yet, but Mondrian will be able to look inside any Role that contains MemberGrants can convert them into conditions in a WHERE clause.
>> 
>> Also, because it uses inversion of control (Mondrian makes its own roles, rather than the container making them and pushing them in) it is less error-prone.
>> 
>> This feature isn't complete (see the jira case for the full list), but it is functional. If you're using Mondrian 4 beta and are having performance issues with multi-tenancy, give it a try.
>> 
>> It's not too late to change the API. Give us feedback about that.
>> 
>> Julian
>> _______________________________________________
>> Mondrian mailing list
>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.pentaho.org/pipermail/mondrian/attachments/20130106/4fb8c480/attachment.html 


More information about the Mondrian mailing list