[
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)
