[ https://issues.apache.org/jira/browse/ACCUMULO-1041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
John Vines updated ACCUMULO-1041: --------------------------------- Issue Type: Sub-task (was: Bug) Parent: ACCUMULO-259 > Generic interface for arbitrary token handling > ---------------------------------------------- > > Key: ACCUMULO-1041 > URL: https://issues.apache.org/jira/browse/ACCUMULO-1041 > Project: Accumulo > Issue Type: Sub-task > 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