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 Sun, 24 Feb 2013 23:04:12 GMT


Christopher Tubbs commented on ACCUMULO-1024:

I'm also a bit concerned about the interaction between these 3 independently configurable
components when it comes to synchronizing their storage of user attributes.

Before, when everything was a single interface (even though it wasn't yet configurable by
users), it was obvious how to deal with stored permissions/authorizations when a user was
created/deleted, but now... it's not so obvious, and could result in elevated access if user
principals are re-used or authentication systems are swapped, but authorizations/permissions
storage stays the same without resetting its storage.

One argument is that it is the responsibility of the admin configuring the system to choose
components that work well together. Another is to delegate this responsibility to a developer
responsible for developing a single plugin that leverages the 3 functions of user access into
a cohesive plugin (I prefer this, because it's easier to configure, and puts less burden on
system admins for proper configuration to get expected security guarantees).

I'm not sure this should be changed at this time... I think the existing, independently configurable
components is fine for now, but the concern of stale user principals should be addressed as
a part of the user-management changes that have already been done and those that are done
as part of this ticket.

This was brought up a little bit on the ACCUMULO-259 ticket, and I see that a "compatibleWith"
concept was implemented to address resetting user permissions (probably as a result of that
conversation), so I want to comment on that, too: I'm not sure I like that idea as much as
a single configurable plugin instead of 3, because it creates interleaved dependencies on
components that should really be independent. However, we can add a resetPermissions(user)
and resetAuthorizations(user) to their respective components, so that at least authenticator
plugins have the ability to reset these things when users are deleted if they want to.
> 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