accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christopher Tubbs (JIRA)" <>
Subject [jira] [Commented] (ACCUMULO-1041) Generic interface for arbitrary token handling
Date Tue, 26 Feb 2013 21:32:14 GMT


Christopher Tubbs commented on ACCUMULO-1041:

1, 3, 4: I'm still working out how to do this, exactly. I still have questions about the need
for these, and their behavior (vs. putting the token-construction methods entirely outside
our API).
5: done in "polishing" branch.
6: this obsoleted by the suggestions posed on ACCUMULO-1024 for minimizing and making more
intuitive the API changes from 1.4, which is done for the API in the "polishing" branch, but
still needs a tiny bit of work on the back end.
7: Yes, that's exactly the motivation.
8, 9: - 
10: I think most, if not all, have migrated. The only ones that might not be are those that
occur in comments, vs. code, and I don't know of any instances of that... maybe in the documentation.
11: I think some of this remains to be seen. Authorizations is down there, after all... never
realized that.
> Generic interface for arbitrary token handling
> ----------------------------------------------
>                 Key: ACCUMULO-1041
>                 URL:
>             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
> # 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
> 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:

View raw message