Return-Path: X-Original-To: apmail-accumulo-notifications-archive@minotaur.apache.org Delivered-To: apmail-accumulo-notifications-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id B6956EC50 for ; Wed, 27 Feb 2013 01:19:13 +0000 (UTC) Received: (qmail 88597 invoked by uid 500); 27 Feb 2013 01:19:13 -0000 Delivered-To: apmail-accumulo-notifications-archive@accumulo.apache.org Received: (qmail 88571 invoked by uid 500); 27 Feb 2013 01:19:13 -0000 Mailing-List: contact notifications-help@accumulo.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: jira@apache.org Delivered-To: mailing list notifications@accumulo.apache.org Received: (qmail 88340 invoked by uid 99); 27 Feb 2013 01:19:13 -0000 Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 27 Feb 2013 01:19:13 +0000 Date: Wed, 27 Feb 2013 01:19:13 +0000 (UTC) From: "Christopher Tubbs (JIRA)" To: notifications@accumulo.apache.org Message-ID: In-Reply-To: References: 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 X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/ACCUMULO-1024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13587833#comment-13587833 ] Christopher Tubbs commented on ACCUMULO-1024: --------------------------------------------- Oh, I see. That might be a useful Authenticator implementation, because it's easy to use. However, it's not very secure (it'd probably have to be stored in HDFS or some other shared location), and I wouldn't want to provide an implementation I wouldn't recommend. However, I would be interested in looking at how they do authentication in their code (I think they use JAAS LoginContext, with a PasswordCallback that reads this file), because that might be useful for us to adopt in the future, on the server side. However, it doesn't resolve the issues with the client side, because even LoginContext has the issue of how to get the credentials to the CallbackHandler's respective Callbacks on the server side. With the generic token handling, we're essentially supporting single sign-on (SSO)... however the SSO tokens are authenticated, we need to pass them to the server. > 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