Mailing-List: contact notifications-help@accumulo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: jira@apache.org
Date: Mon, 4 Feb 2013 22:06:12 +0000 (UTC)
From: "John Vines (JIRA)" <jira@apache.org>
To: notifications@accumulo.apache.org
Message-ID: <JIRA.12630763.1360015515013.241920.1360015572397@arcas>
In-Reply-To: <JIRA.12630763.1360015515013@arcas>
References: <JIRA.12630763.1360015515013@arcas>
Subject: [jira] [Created] (ACCUMULO-1041) Generic interface for arbitrary
 token handling
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

John Vines created ACCUMULO-1041:
------------------------------------

             Summary: Generic interface for arbitrary token handling
                 Key: ACCUMULO-1041
                 URL: https://issues.apache.org/jira/browse/ACCUMULO-1041
             Project: Accumulo
          Issue Type: Bug
          Components: client
            Reporter: John Vines
            Assignee: Billie Rinaldi
             Fix For: 1.5.0


Chris, Keith, and I hashed out details for best approach for generic tokens which should work both for our API and the proxy.
1. Client requests the Authenticator class name
2. Client creates instance of Authenticator, calls login(Properties)
3. Properties are used to create the appropriate Token, which implements Writable, and return it to user.
4. Client uses principal + Token with getConnector call
5. Token is immediately serialized to be used within client api and packaged into a Credential object
6. Credential gets sent to server via thrift
7. Principal is checked, if !SYSTEM treated as a PasswordToken, otherwise deserialized as a class defined by the Authenticator (Writable's readFields method called on said class)
8. Token us then passed through the SecurityOperations impl as well as the authenticator api.

This allows the authenticator API to use their requested tokens without confusion/code injection issues with deserialization happening for unknown token classes.

The exact same process for token creation can also be used by the Proxy, with a Map of properties being passed it to create a token on the proxy.


For backward support, the ZKAuthenticator will expect a PasswordToken, which is simply a byte array.

--
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