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.
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.deny.=*regexp suitable for String.matches(..)*
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.
# The roles-array env-key is a virtual key. This returns the roles as parsed string-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