[ https://issues.apache.org/jira/browse/ACCUMULO-1041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Christopher Tubbs updated ACCUMULO-1041: ---------------------------------------- Description: [~ctubbsii], [~kturner] and I hashed out details for best approach for generic tokens which should work both for our API and the proxy. # Client requests the Authenticator class name # Client creates instance of Authenticator, calls login(Properties) # Properties are used to create the appropriate Token, which implements Writable, and return it to user. # Client uses principal + Token with getConnector call # Token is immediately serialized to be used within client api and packaged into a Credential object # Credential gets sent to server via thrift # 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) # 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. was: [~ctubbsii|Christopher], [~kturner] and I hashed out details for best approach for generic tokens which should work both for our API and the proxy. # Client requests the Authenticator class name # Client creates instance of Authenticator, calls login(Properties) # Properties are used to create the appropriate Token, which implements Writable, and return it to user. # Client uses principal + Token with getConnector call # Token is immediately serialized to be used within client api and packaged into a Credential object # Credential gets sent to server via thrift # 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) # 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. > 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: John Vines > Fix For: 1.5.0 > > > [~ctubbsii], [~kturner] and I hashed out details for best approach for > generic tokens which should work both for our API and the proxy. > # Client requests the Authenticator class name > # Client creates instance of Authenticator, calls login(Properties) > # Properties are used to create the appropriate Token, which implements > Writable, and return it to user. > # Client uses principal + Token with getConnector call > # Token is immediately serialized to be used within client api and packaged > into a Credential object > # Credential gets sent to server via thrift > # 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) > # 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