[
https://issues.apache.org/jira/browse/ACCUMULO-1024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13585215#comment-13585215
]
Christopher Tubbs commented on ACCUMULO-1024:
---------------------------------------------
After thinking about this some more, I think that the most intuitive transition
to supporting alternate authentication schemes is to support "local" users
first, and then remote users (through pluggable authentication) second. By
"local" users, I mean local to the instance, using our built-in user management
that existed in 1.4 and earlier. This is similar to how local users in Linux
are authenticated prior to remote (NIS, LDAP, etc.) users are.
The reason I think this is the best way to go is for several reasons. The first
is because it is the most intuitive transition, in terms of the API, because
the existing user management in SecurityOperations does not need to change
much. At the most, it might change to say something like "createLocalUser"
instead of "createUser". I strongly think this is the least intrusive change we
can do to support external authentication.
The second reason I think this is better is the upgrade process is smooth,
because the existing "local" users transition seamlessly, without any change in
behavior.
A third reason I think this is better, is because those users who do not wish
to use an external authentication system, are hardly affected at all, but we
can still satisfy all the use cases of an external authentication system.
This is also better for initialization, because the init system would exactly
as it had in previous versions... setting the root password (for the local root
user) only.
The way this would work is that on the server side, credentials are checked
against the local authentication system first, before checking them against the
external authentication system that is configured. (I realize that in Linux,
the order of these are configurable, but I think it's fine to make the order
always local first, as that's the most common configuration in Linux; if we
need the feature to change the order, it can be added as a feature later; right
now, we just need to polish up and solidify the behavior and API of the new
pluggable authentication stuff that was added for the 1.5.0 release).
> 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
> 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
