accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John Vines (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (ACCUMULO-1041) Generic interface for arbitrary token handling
Date Mon, 04 Mar 2013 23:53:12 GMT

    [ https://issues.apache.org/jira/browse/ACCUMULO-1041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13592813#comment-13592813
] 

John Vines commented on ACCUMULO-1041:
--------------------------------------

Since this seems to be the place for discussion on this-

I did 2, purged getConnector(Credential). However, I left getAuthenticatorClass and also added
getAuthenticator which are used internally in the Instance. I'm not sure if this is something
we want to keep exposed to users or to privatize to streamline the getConnector(String,  Properties)
approach. We need to keep the getConnector(String, AuthenticationToken) for a lot of the code,
which is the biggest reason I can think of for keeping those methods public.
                
> 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

Mime
View raw message