accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christopher Tubbs (JIRA)" <>
Subject [jira] [Commented] (ACCUMULO-1024) Deprecate built-in user management utilities
Date Sat, 23 Feb 2013 21:36:12 GMT


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:
>             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
> 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