[jira] [Created] (ACCUMULO-1632) Create security policy interface for user-initiated operations

["Christopher Tubbs (JIRA)" <ji...@apache.org>]

Christopher Tubbs created ACCUMULO-1632:
-------------------------------------------

             Summary: Create security policy interface for user-initiated operations
                 Key: ACCUMULO-1632
                 URL: https://issues.apache.org/jira/browse/ACCUMULO-1632
             Project: Accumulo
          Issue Type: Improvement
            Reporter: Christopher Tubbs
            Assignee: Christopher Tubbs
             Fix For: 1.7.0


This may be a bit ambitious for 1.6.0, but perhaps for 1.7.0.

I think it would be a significant improvement to create a policy-based system for deciding whether users have permissions to perform actions on the server-side, rather than explicitly force one implementation of a security policy based on permissions attributes a user has.

Currently, the "policy" for whether a user can perform certain actions is hard-coded in the ClientServiceHandler on the server-side, and is based on the responses it gets from authenticating a user, and retrieving permissions attributes from a permissions handler.

This code is not centralized, and it makes it difficult to understand not only what permissions a user is required to have in order to perform an action, but also which permissions we intended a user to have in order to perform that action. This makes it very difficult to unit test the security policy and verify correctness (we do manage, with comprehensive integration tests, though).

The basic policy interface might look something like:
{code:java}
public interface ActionPolicy {
  public boolean canPerformAction(User user, Action action);
}
{code}

Our current permissions-based policy might look like:
{code:java}
public class UserAttributePolicy {
  public boolean canPerformAction(User user, Action action) {
    if (!user.isAuthenticated())
      return false;
    if (action instanceof ReadTableAction) {
      return zkAttributeStore.hasUserTablePermissionAttribute(user, TablePermission.READ, ((ReadTableAction) action).getTableId());
    }
    ...
    log.warn("User initiated unrecognized Action type " + action.getClass());
    return false;
  }
} 
{code}

A wrapper for User might be useful, that ties in the different pluggable components introduced in ACCUMULO-259. Something like:

{code:java}
public final class User {

  // constructor
  public User(Authenticator authenticator, Authorizor authorizor, PermissionsHandler permsHandler) {
    authenticator.authenticate(this);
    ...
  }
  public Set<String> getAttributes() {...}
  public boolean isAuthenticated() {...}
}
{code}

My mockup of User indicates I'd rather see Authorizor and PermissionsHandler treated as a single user attribute service. I haven't worked through all the details yet, but I think this would be a lot better for testing, maintenance, modular configurability, and interoperability.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira