Hitachi Vantara Pentaho Community Wiki
Child pages
  • Customizing ACL Decisions
Skip to end of metadata
Go to start of metadata

Creating an IAclVoter

IAclVoter Hierarchy

Before proceeding, be sure that you have read about domain object authorization in the platform. The section on domain object authorization introduces access control lists (ACLs) and the IAclVoter interface. The Pentaho BI Platform provides an abstract class called AbstractPentahoAclVoter that implements IAclVoter as well as a concrete subclass called PentahoBasicAclVoter. If you want to provide your own implementation of the IAclVoter interface, it is recommended that you consider starting with the PentahoBasicAclVoter. Use this class as your superclass, and override behaviors as desired.

Voter Example

Assume that you want to build your own ACL voter. The requirements are as follows:

  • Allow content to be accessed by anonymous users.
  • However, if a user is specified in the access control list for an object, those access controls should override anything else in the access control list.

This is essentially merging the functionality of the PentahoUserOverridesVoter and PentahoAllowAnonymousAclVoter, both classes provided by the platform. So, where should one begin?

Consider the following implementation options:

  1. Subclass AbstractPentahoAclVoter. This would require the most work because one would have to duplicate the logic in PentahoBasicAclVoter, PentahoUserOverridesVoter and PentahoAllowAnonymousAclVoter.
  2. Subclass PentahoBasicAclVoter. This would be the second most difficult because this would require one to implement all the work currently being done by PentahoUserOverridesVoter and PentahoAllowAnonymousAclVoter.
  3. Subclass either PentahoAllowAnonymousAclVoter or PentahoUserOverridesVoter and add the functionality from the non-subclassed into the new one.

Option #3 seems like the best way to go. But should one subclass PentahoUserOverridesVoter or PentahoAllowAnonymousAclVoter? The javadoc for PentahoAllowAnonymousAclVoter states that it simply overrides the getAuthentication(IPentahoSession) method to allow anonymous sessions. And, since getting the authentication from the IPentahoSession object is actually a SecurityHelper call, this is the easiest functionality to add to any voter. However, the logic in the PentahoUserOverridesVoter is a bit more involved, and not something that one would like to duplicate. Given this information, the decision is made to subclass PentahoUserOverridesVoter and simply add the getAuthentication(IPentahoSession) method that allows anonymous access. The final class ends up looking like:


import org.pentaho.core.session.IPentahoSession;


public class PentahoUserOverridesAllowAnonymousAclVoter 
   extends PentahoUserOverridesVoter {
  // Allow anonymous users to have possible acls on an entry.
  public Authentication getAuthentication(IPentahoSession session) {
    return SecurityUtils.getAuthentication(session, true);

This solution turns out to be the best of both worlds, and it meets the requirements without being too arduous to implement.

Your options are unlimited with respect to implementing your own ACL voters. For example, consider the case of a user (Sally) going on vacation, and delegating her responsibilities to someone else (Joe). Often this means a difficult change request going through the IT department that temporarily assigns Joe all of the roles of which Sally is a member. This would allow Joe access to all the solutions and action sequences to which Sally has access. Then, when Sally comes back, you'd have to process another change request through the IT department that would set Joe's access back the way it was before Sally went on vacation.

Or, you could create an ACL voter that, in addition to looking at Joe's roles, also looks in a relational database or an XML file for role overrides based on the date. In this way, instead of having to go through the IT department to make these changes, you could have time-based voter overrides.

1 Comment

  1. user-fe4bb

    I created a customized ACL voter. Everything works fine except that ACL voter can only be invoked when user login first time. Without restarting BA server, the subsequent login won't be able to invoke ACL voter.

    Here is tests I went through:

    1. In ACL voter, I added rule so that user A can only access Folder A (in solution repository), and user B can only access Folder B

    2. Start BA server
    3. Login as user A. The folder A is visible. From log file, I can see acl voter is invoked. It works fine so far
    4. Logout and then re-login as user B
    5. What visible is still folder A (NOT folder B). From log file, I can't find acl voter invoked this time. This is not right. Apparently, the result from step 3 was being "cached" somehow and is being reused in this step
    6. Restart BA server
    7. Still login as user B
    8. This time folder B is visible which is correct.

    Any idea how to correct the wrong behavior?