accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Josh Elser (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (ACCUMULO-1632) Create security policy interface for user-initiated operations
Date Mon, 06 Apr 2015 03:01:13 GMT

     [ https://issues.apache.org/jira/browse/ACCUMULO-1632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Josh Elser updated ACCUMULO-1632:
---------------------------------
    Fix Version/s:     (was: 1.7.0)
                   1.8.0

> 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.8.0
>
>   Original Estimate: 504h
>  Remaining Estimate: 504h
>
> 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 user.hasAttribute("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 was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message