accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christopher Tubbs (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (ACCUMULO-1024) Deprecate built-in user management utilities
Date Sun, 24 Feb 2013 22:50:13 GMT

    [ 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

Mime
View raw message