From the feedback I received so far, the new Mondrian role feeding system seems to work pretty well.
There was only one tiny bit missing: Mondrian reacts absolutely unhappy, if it encounters roles it cannot understand. If your roles come from a external source, like LDAP, you usually have more roles there as are defined in Mondrian. Even in a standalone, all in-memory solution, the platform roles very likely form a super-set of the defined Mondrian roles.
To make Mondrian happy without too much manual work (or heaven forbid: work on every report-definition), we now have a role-filtering system for both the OLAP4J and Mondrian datasources. The filter is a classical deny-then-accept filter usually found in firewalls. You can remove known bad roles and you can have a known good roles list.
All the filter-rules are enabled via the global config stored in the famous “classic-engine.properties” file. For the BI-Server, this file can be found in the “pentaho/WEB-INF/classes” directory. For the Pentaho Report Designer, the file is in the “resources” directory.
# Enables or disables the filter code. Is disabled by default.
org.pentaho.reporting.engine.classic.extensions.datasources.mondrian.role-filter.enable=true
Filtering is controlled via 4 sets of properties. Deny wins over accept. You can either filter by static comparison or via reg-exp matching. There can be multiple keys per category, just make the “name” at the end unique. This greatly helps with long-term maintenance as a 10.000 chars regexp is no fun to edit each time someone adds or removes a role.
In case there is no accept rule in your configuration, a default accept-all rule gets active.
org.pentaho.reporting.engine.classic.extensions.datasources.mondrian.role-filter.reg-exp.accept.=*rolename*
org.pentaho.reporting.engine.classic.extensions.datasources.mondrian.role-filter.reg-exp.deny.=*regexp suitable for String.matches(..)*
org.pentaho.reporting.engine.classic.extensions.datasources.mondrian.role-filter.static.accept.=*rolename*
org.pentaho.reporting.engine.classic.extensions.datasources.mondrian.role-filter.static.deny.=*regexp suitable for String.matches(..)*
Filtering is only active, if the role is read from a field, and if the value read is an array. You can use the “env::roles-array” safely to read the roles from the server and the filter rules will make sure that Mondrian is happy too.
The mapping between environment names and data-row names (and as side-effect, the definition whether a environment property can be interpreted as array) can also be defined in the global configuration.
The following code snipplet shows the default configuration.
#
# Defines, which environment properties are published as fields in a report. The mapping is a
# environment-name to data-row column name mapping.
#
# Any environment property name that ends with "-array" will be read without the "-array" suffix
# and will be interpreted as CSV string that can be parsed into an array of strings.
org.pentaho.reporting.engine.classic.core.env-mapping.serverBaseURL=env\:\:serverBaseURL
org.pentaho.reporting.engine.classic.core.env-mapping.pentahoBaseURL=env\:\:pentahoBaseURL
org.pentaho.reporting.engine.classic.core.env-mapping.solutionRoot=env\:\:solutionRoot
org.pentaho.reporting.engine.classic.core.env-mapping.hostColonPort=env\:\:hostColonPort
org.pentaho.reporting.engine.classic.core.env-mapping.username=env\:\:username
org.pentaho.reporting.engine.classic.core.env-mapping.roles=env\:\:roles
#
# The roles-array env-key is a virtual key. This returns the roles as parsed string-array.
org.pentaho.reporting.engine.classic.core.env-mapping.roles-array=env\:\:roles-array
Properties from the Server’s session can be accessed via session::attribute-name. The value stored in the HTTP-Session must be a String.
Example: if you have a string stored by the name magic-attribute, then you can access that string via the environment property name session::magic-attribute.
This issue has come up a few times while integrating Mondrian with other tools, including Pentaho’s role system. Sounds like you’ve come up with a reasonable workaround, but I’d like to make Mondrian more usable.
One proposed solution, which I don’t like, is to make Mondrian ignore roles that it hasn’t heard of. I don’t like that solution because it would be easy to mis-type a role name and end up running without access control.
But how about if Mondrian (or olap4j) could tell you which roles you are allowed to run under? Then you could filter your list of roles and only send those that are known to Mondrian.
Please let me know whether this would help, either now or at some point in the future, and I will log a jira case.
I would also like to hear what folks on the Pentaho Biserver team think of this proposed feature.
Julian