[
https://issues.apache.org/jira/browse/ACCUMULO-1024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13587635#comment-13587635
]
Christopher Tubbs commented on ACCUMULO-1024:
---------------------------------------------
[~vines]:
I referenced the validation check above. The reason I'm not a fan of that way
of doing things is that without knowing anything about those other components,
a developer of one has to enumerate all the possible implementations of the
other components that it knows are compatible. This means that a developer
would have to re-release new versions of his component every time other,
compatible components of the other types are created/released, or make it
configurable in their code, or most likely, just always return true.
Re-releasing is not feasible, and it creates a configuration management
nightmare for system admins, and it makes them less independent, and less
modular. Configuration is a lateral move, and always returning true is
something we should probably just do anyways by eliminating this check and
deferring to system admins/configuration management people to ensure they
choose components that are compatible.
I agree the components shouldn't directly interact, and I also like the
centralized "SecurityOperation" on the server side that brings them together.
All I've suggested is that this "SecurityOperation" be configurable, instead of
the 3 components... though I'd strongly support an implementation of a
pluggable "SecurityOperation" or "UserSecurityPlugin" (as I'd probably call
it), that is comprised of 3 distinct, modular components. (Example:
"configuration.getUserSecurityPlugin().getAuthenticator();" vs.
"configuration.getAuthenticator()") In this way, if there are any interactions
necessary, they occur in a coherent way, within the configured
SecurityOperation (or equivalent).
The short answer is that one interface does not work against modularity,
especially if that one interface is a factory for the 3 modular components. You
don't necessarily need to "rewrite the whole class", either. In the typical
case, a rewrite is trivial anyway... just change the return type in a factory.
The alternative (and I think this is preferable...) is to simply assume
compatibility, and by convention, if one implements user-management features in
their Authenticator, then give the Authenticator access to call
cleanUser/dropUser as appropriate.
In any case, I just wanted to document the issue of interoperability... I'm not
necessarily suggesting we change it at this point (it's kind of too late for
1.5.0, anyway). My focus on this ticket is about dealing with the "local user"
concept above the comment which you replied to.
> 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
