[Mondrian] UnionRole and explicit / implicit rules

[Julian Hyde]

I did my best to come up with a set of rules for combining roles. My goal was that they were simple, reasonably efficient to implement, commutative and associative (just like plus on integers and union on sets).

If the current implementation doesn't implement those rules, log a bug.

We had to have union roles for cases where a user is, well, in two roles. But union roles are not the best way of building custom roles in all circumstances. As you say, DSP is the way to go. (Or http://jira.pentaho.com/browse/MONDRIAN-1281 -- as powerful as DSP but without the caching issues.)

Julian


On Nov 26, 2012, at 9:24 AM, Paul Stoellberger <p.stoellberger at gmail.com<mailto:p.stoellberger at gmail.com>> wrote:

But the overall result of what I'm seeing is still confusing/incosistent:

So the 2 roles:
"No HR Cube"
- Schema grant "all"
- Cube grant "HR" "none"

California manager
- Schema grant none
  Cube grant Sales all
  Hierarchy grant store
  - topLevel="[Store].[Store Country]",
- member grant "Los Angeles" NONE

1) SchemaGrant : all and none => "all" is applied
2) Cube grant: HR none + "all" from schema are applied => between  "just showing Sales" and "all but HR" we see "all but HR" since both roles dont see this cube on its own
3) Hierarchy grant
topLevel = Store Country => we see this as toplevel, although the other role would see all levels, not consistent with your described approach
4) MemberGrant "Los Angeles" NONE => we see this member, because "No HR Cube" role can see this member, consistent with your described approach again

So especially 3 is at least "wrong" from my POV.

If we really "union" all => least restrictive, it is quite hard to define fine-grained data access without having a lot of roles that all include every detail of the cube (each role would have to include all grant objects).
Is the only way to have this a programmatic role that knows about all that? (Well I guess a DSP would work too)

I think it should either a) use the most permissive b) the most restrictive c) overrule implicit with explicit rules

The people I talked to about this today had a similar views. No matter which one of the above it should do.. it should at least be consistent.

I guess I can always create my own role that delivers what I need, but I think it makes sense to discuss the current implementation first.

-Paul






On Nov 26, 2012, at 6:03 PM, Julian Hyde wrote:

That's mostly right.

The philosophy is a bit different than you describe. It's irrelevant whether a role has explicit or implicit access to a particular object (cube, dimension, etc.) If role A can see X, and role B cannot, then the union role can see it. For example, even if A explicitly cannot see cube X (because of a <CubeGrant name='X' access='none'/>) and B implicitly can see cube X (because of a <SchemaGrant access='all'/>), the result is still that the A-union-B role can see cube X.

Julian


On Nov 26, 2012, at 3:47 AM, Paul Stoellberger <p.stoellberger at gmail.com<mailto:p.stoellberger at gmail.com>> wrote:

So I was just playing with roles and I configured my foodmart to use both roles "No HR Cube" and "California Manager" for my dummy user.

Now the result is rather interesting:
1) I don't see a HR cube, but all other (although california manager has only access to sales), so the union works as i expect it
2) the customer / store hierarchy in Sales are restricted (top / bottom level) => see http://jira.pentaho.com/browse/MONDRIAN-1168
3) i can see the city  "Los Angeles" in the results, althoug I was expecting not to see them.

If the level restriction (access none) worked, so should the member access.
While there is now a Math.min() for levels, its a max() for members etc.

The "No HR Cube" doesn't set explicit access restriction on the customer / store hierarchy, so the one from california manager should overrule it.
If both had access set explicitly on that hierarchy / member it should use max() of both, but not if only 1 sets it.


Before I propose any changes to RoleUnionImpl I wanted to know if you agree with that?

-Paul






_______________________________________________
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<mailto:Mondrian at pentaho.org>
http://lists.pentaho.org/mailman/listinfo/mondrian

_______________________________________________
Mondrian mailing list
Mondrian at pentaho.org<mailto: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/20121129/1c2e3a9b/attachment.html