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