[
https://issues.apache.org/jira/browse/ACCUMULO-1024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13585521#comment-13585521
]
Christopher Tubbs commented on ACCUMULO-1024:
---------------------------------------------
[~medined] - In what way? I don't know a lot about Tomcat's authentication. The
model I'm working from is that of the basic Windows/Linux/Mac users, as far as
behavior, keeping as much of John Vines' stuff in place, while minimizing the
changes from 1.4 and earlier. If there's something specific we can borrow from
Tomcat to make the API more intuitive, I'd love to, and am open to
recommendations.
[~vines] - I'm thinking that whatever component handles the "local" or
"internal" users for authentication, it will be baked in by devs, not by
configuration. Any configured authentication plugin would be for "remote" or
"external" users. The built-in should behave just like the configured one for
external users (makes it easier on us developers), but given priority by the
ClientServiceHandler and checked first. As for the Authorizor/PermHandler...
I'm thinking those are entirely pluggable, as you have them now, with a default
configuration. For the default Authenticator, it'd basically be an AlwaysReject
sort of thing (so only local users are allowed).
A few more thoughts on the Authorizor/PermHandler: these are essentially dumb
storage, pluggable. They don't really need to do logic, so much as store
attributes for a user (at least, from their respective APIs, that's how we can
safely think of them). I think some things may need to be done make that more
obvious (rename the interface to UserAuthorizationStorage/UserPermissionStorage
or similar... though not really a fan of that idea, as it's not as "elegant" as
the current naming scheme).
> 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
