[
https://issues.apache.org/jira/browse/ACCUMULO-1041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13587529#comment-13587529
]
John Vines commented on ACCUMULO-1041:
--------------------------------------
1. Looks good
2. This is primarily a convenience method for a lot of the testing frameworks.
It's possible to work around, but would make a lot of the code more ugly.
3/4. Really like this idea, replace it with get property info or something
which spits back sets of properties which can be used and descriptions.
5. Sounds good
6. I'm okay with spinning out the User Management stuff, as per other
discussions. However, this is a bit of authorization work, but mostly
Permission management. And I have an illogical liking of the name
SecurityOperations, but I can't identify why.
7. Do you mean use a special token type so user's can't spoof the !SYSTEM
principal? I'm okay with this too.
8. yup
9. yup
10. I thought I had migrated them over. Though I may have done it in one of the
other iterations and gotten fed up and did things poorly until we were well
cemented.
11. what items do you have in mind?
> 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
