[
https://issues.apache.org/jira/browse/HADOOP-9421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13640938#comment-13640938
]
Luke Lu commented on HADOOP-9421:
---------------------------------
bq. I'm interested in your vision/use-case for multiple tokens? Could this be
hidden behind the secret manager?
I'm thinking about capability based tokens, the current DT is too powerful,
which if compromised, all capabilities of the user is compromised. Yes, the
SecretManager abstraction still holds. Though the API needs to be enhanced to
support capability tokens.
bq. How is "do you do this mech?", "no?", "how about this mech?", "yes? ok,
let's do it!" being complex?
The mechanism negotiation itself is not complex. It's the way it's coupled with
sasl challenge/response itself.
bq. The client can't make a determination until he knows the server id for a
mechanism.
Again, client can cache the server mechanisms and associated info, which almost
never change across connections.
bq. IMHO, dumb clients are always good.
Simple but not simpler :) My point is that using sasl-next as part of protocol
is too pessimistic and precludes reasonable client optimizations.
> Add full length to SASL response to allow non-blocking readers
> --------------------------------------------------------------
>
> 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
