Mailing-List: contact notifications-help@accumulo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: jira@apache.org
Date: Tue, 26 Feb 2013 20:46:14 +0000 (UTC)
From: "John Vines (JIRA)" <jira@apache.org>
To: notifications@accumulo.apache.org
Message-ID: <JIRA.12630555.1359853574432.344712.1361911574062@arcas>
In-Reply-To: <JIRA.12630555.1359853574432@arcas>
References: <JIRA.12630555.1359853574432@arcas>
Subject: [jira] [Commented] (ACCUMULO-1024) Deprecate built-in user
 management utilities
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/ACCUMULO-1024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13587522#comment-13587522 ] 

John Vines commented on ACCUMULO-1024:
--------------------------------------

I implemented the three components with a validation check to make sure all of the components could play nice with eachother. The ZK ones are well tested and function standalone, so there was no issue there. It's really up to the developer of the plugin to determine if it doesn't work well, and their plugin should identify that in the implementation.

The authenticator should have no direct interaction with any of the other components. The SecurityOperations dictates how Accumulo behaves. Once a user is authenticated, they are authenticated and the other interfaces just deal with answering questions about a principal. Period. And there already are methods for resetting user's permissions and authorizations. Look at Authorizor.dropUser(String) and PermissionHandler.cleanUser(String) [however, these should probably have the same nomenclature, now that I'm looking at them both]. All three methods are called in SecurityOperation in a consistent order. I feel strongly that these should remain 3 distinct components, or else any user who wants to harness an existing permission handler, lets say, needs to rewrite the whole class because they want to use a custom ldap system for authorization, etc. etc. Modularity here is the critical feature here, and merging to a single interface would work against it.
                
> 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