You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@accumulo.apache.org by "John Vines (JIRA)" <ji...@apache.org> on 2013/02/26 21:50:13 UTC
[jira] [Comment Edited] (ACCUMULO-1041) Generic interface for
arbitrary token handling
[ https://issues.apache.org/jira/browse/ACCUMULO-1041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13582450#comment-13582450 ]
John Vines edited comment on ACCUMULO-1041 at 2/26/13 8:48 PM:
---------------------------------------------------------------
[~ctubbsii] and I were looking at these changes today. We are thinking of making the following changes in the near future :
# add "Connector getConnector(String p, Props)" AND "SecurityToken getSecurityToken(Props)" to Instance
# remove Instance.getConnector(Creds)
# remove Instance.getAuthenticatorClassName()
# would be nice to have a way to automatically get possible prop keys
# rename SecurityToken to AuthenticationToken
# split SecurityOperations into UserManager and AuthorizationManager
# use specific token type for system user, users can use !SYSTEM prinicipal
# review javadocs
# test, docs, & examples for InsecureAuthenticator
# examples should use new way of doing things
# move anything end users would use from o.a.a.core.security to o.a.a.core.client (maybe a security subpackage of client)
was (Author: kturner):
[~ctubbsii] and I were looking at these changes today. We are thinking of making the following changes in the near future :
* add "Connector getConnector(String p, Props)" AND "SecurityToken getSecurityToken(Props)" to Instance
* remove Instance.getConnector(Creds)
* remove Instance.getAuthenticatorClassName()
* would be nice to have a way to automatically get possible prop keys
* rename SecurityToken to AuthenticationToken
* split SecurityOperations into UserManager and AuthorizationManager
* use specific token type for system user, users can use !SYSTEM prinicipal
* review javadocs
* test, docs, & examples for InsecureAuthenticator
* examples should use new way of doing things
* move anything end users would use from o.a.a.core.security to o.a.a.core.client (maybe a security subpackage of client)
> 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