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:

package com.pentaho.security.acls.voter;

import org.springframework.security.Authentication;
import org.pentaho.core.session.IPentahoSession;

import com.pentaho.security.SecurityUtils;

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.