[
https://issues.apache.org/jira/browse/ACCUMULO-1024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13587522#comment-13587522
]
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: https://issues.apache.org/jira/browse/ACCUMULO-1024
> 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 core.
> 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: http://www.atlassian.com/software/jira
