[
https://issues.apache.org/jira/browse/HADOOP-9421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13658221#comment-13658221
]
Kai Zheng commented on HADOOP-9421:
-----------------------------------
Luke good point. It’s great to resolve this issue if “we have a mechanism to
evolve SASL mechanisms/protocols negotiation without breaking general RPC
backward compatibility” with the RPC cleanup. With this support new
authentication mechanisms can continue to be implemented in current way as
Daryn might be doing. And based on the mentioned mechanism hopefully an opaque
token can also be employed or at least supported without breaking RPC backward
compatibility as this JIRA desires. Such opaque token is needed by token
authentication and single sign on in (HADOOP-9392) where new authentication
mechanism can be implemented and plugin-ed via the token without involving to
change this RPC work again. So my question would be:
1. Do we have any limit for the optional token field and what properties it
must be of? Variable of bytes would be great;
2. Do we have a flag field or something like that to mark the token type in
client side, and in server side it can interpret the token accordingly to the
type?
3. Hopefully we can add token authentication handler with relevant callbacks in
elegant way.
Thanks for your consideration.
> Generalize SASL Support with Protocol Buffer
> --------------------------------------------
>
> Key: HADOOP-9421
> URL: https://issues.apache.org/jira/browse/HADOOP-9421
> Project: Hadoop Common
> Issue Type: Sub-task
> Affects Versions: 2.0.3-alpha
> Reporter: Sanjay Radia
> Assignee: Junping Du
> Attachments: HADOOP-9421.patch
>
>
--
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
