accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John Vines (JIRA)" <>
Subject [jira] [Commented] (ACCUMULO-1024) Deprecate built-in user management utilities
Date Tue, 26 Feb 2013 20:46:14 GMT


John Vines commented on ACCUMULO-1024:

I implemented the three components with a validation check to make sure all of the components
could play nice with eachother. The ZK ones are well tested and function standalone, so there
was no issue there. It's really up to the developer of the plugin to determine if it doesn't
work well, and their plugin should identify that in the implementation.

The authenticator should have no direct interaction with any of the other components. The
SecurityOperations dictates how Accumulo behaves. Once a user is authenticated, they are authenticated
and the other interfaces just deal with answering questions about a principal. Period. And
there already are methods for resetting user's permissions and authorizations. Look at Authorizor.dropUser(String)
and PermissionHandler.cleanUser(String) [however, these should probably have the same nomenclature,
now that I'm looking at them both]. All three methods are called in SecurityOperation in a
consistent order. I feel strongly that these should remain 3 distinct components, or else
any user who wants to harness an existing permission handler, lets say, needs to rewrite the
whole class because they want to use a custom ldap system for authorization, etc. etc. Modularity
here is the critical feature here, and merging to a single interface would work against it.
> Deprecate built-in user management utilities
> --------------------------------------------
>                 Key: ACCUMULO-1024
>                 URL:
>             Project: Accumulo
>          Issue Type: Sub-task
>          Components: master, tserver
>            Reporter: Christopher Tubbs
>            Assignee: Christopher Tubbs
>             Fix For: 1.5.0
> The built-in user management functionality should be phased out, in favor of the pluggable
authentication model. Any user-management functions that apply to a particular implementation
of an authentication should be handled within that implementation, and not within Accumulo's
> This should reduce the complexity of the overall user model.
> A transition plan should be established for the prior ZKAuthenticator implementation
for usernames and passwords. The former APIs for user management should continue to work as
is, and pass through to the former implementation, but any new APIs for user management should
not be introduced to the core (like in SecurityOperations, the shell, and 'accumulo init'),
because that introduces complexity and essentially establishes a guarantee that Accumulo will
handle user management for arbitrary authentication systems... which I don't think we can
do generically.

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:

View raw message