Protecting Web resources using a custom voter

[dhainlin]

I needed to protect access to web resources (project information in this case) to only projects a user was assigned to. I created a voter that looks something like:

  public int vote(Authentication authentication, Object object, ConfigAttributeDefinition config)
  {
    if ((object == null) || !this.supports(object.getClass()))
    {
      throw new IllegalArgumentException("Does not support the presented Object type");
    }

    FilterInvocation invocation = (FilterInvocation) object;
    HttpServletRequest request = invocation.getHttpRequest();
    String username = authentication.getPrincipal().toString();

    int result = ACCESS_ABSTAIN;

    Iterator iter = config.getConfigAttributes();

    while (iter.hasNext())
    {
      ConfigAttribute attribute = (ConfigAttribute) iter.next();
      if (this.supports(attribute))
      {
        String projectId = null;
        projectId = request.getParameter(PROJECT_ID_PARAM);
        if (projectId != null)
        {
          result = ACCESS_DENIED;
          if (getAdminService().isProjectAssigned(username, projectId))
          {
            return ACCESS_GRANTED;
          }
        }
      }
    }
    return result;
  }

I wired this in front of the role based voter in a UnanimousBased approach. This works great but I was wondering if ACL's would be better. FWIW, I used the above to replace a method intercept based approach I used earlier.

[Ben Alex]

Your voter seems a good approach, although I would probably have done it at a method level. Whether an AccessDeniedException is generated because of a web filter authorisation failure or a services layer authorisation failure typically is of little importance - they're both handled by Acegi Security the same way. Doing it at a method level allows better assurance your authorisations will take place, as it tolerates web application restructures etc (renames of classes on your services methods on the other hand are detected as missing classes at MethodSecurityInterceptor startup time).

The Acegi Security ACL services might prove a better fit if you want to also control (or may want to control in the future) other aspects of domain object security, such as managing creation, edit, delete permissions etc. If the ACL securiity was limited to just access granted or access denied for a single domain object, and that could be accommodated solely through your voter, the ACL security is probably overkill as you also need to maintain the two separate ACL tables. When in doubt I'd probably use the ACL security, as it's better OO to not have the security information within the project and it accommodates future needs without any difficulty.

[dhainlin]

Thanks for your inputs Ben (and your amazing framework).
I'll ponder the ACL stuff and play around with it some. I agree on the method interceptor approach but felt like I was mixing approaches. I am using the stock role voter via filter interceptor and wanted to keep everything in the filter intercept family. Pretty easy to switch around (IOC + Acegi's flex) regardless. This stuff is amazing 'cus there are so many ways to succeed. How often do you hear that today...

[Ben Alex]

Pretty easy to switch around (IOC + Acegi's flex) regardless. This stuff is amazing 'cus there are so many ways to succeed. How often do you hear that today...

Very often in anything to do with Spring! People using stock-standard J2EE don't know what they're missing.... :-)