[
https://issues.apache.org/jira/browse/HADOOP-9421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13680770#comment-13680770
]
Daryn Sharp commented on HADOOP-9421:
-------------------------------------
bq. As long as the mech is TOKEN (or better CHALLENGE_RESPONSE),
The authMethods are mapping an abstract name (ie. TOKEN) to the SASL mechanism.
With the other security designs being discussed, we might have an ID_TOKEN or
SSO_TOKEN. The abstract name appears in the stringified UGI, so it's not
applicable to call it CHALLENGE_RESPONSE.
bq. why can't you instantiate the sasl client then (after receiving server
challenge) with the info from server challenge? Why would an additional
roundtrip be necessary unless the mech is not supported by server?
That's precisely the convoluted logic I outlined in steps 1-4. It's a lot of
additional complexity to pre-maturely optimize just a reconnect, and introduces
much more complexity. Ex. If the client's INITIATE is invalid, now the server
can't return an fatal error and close the connection. It has to return
NEGOTIATE. However a second bad INITIATE should return a fatal error. The
client has to know to create a SASL client on the first CHALLENGE, but not
subsequent CHALLENGES. Other details rapidly add up.
As opposed to INITIATE means the client and server both instantiate their SASL
objects at that time.
bq. Trying to see why you're not seeing what I'm seeing: perhaps it's not
obvious that SaslClient#hasInitialResponse is always false for new connection
with token (Digest-MD5 at least, cf. rfc-2831)?
Initial response is true for other mechanisms like GSSAPI and PLAIN, which
means kerberos has just been penalized. If we upgrade the digest mechanism for
tokens, that new mechanism may also have an initial response. We can't design
this around an internal detail of one particular mechanism (DIGEST-MD5).
Backing up, I thought we agreed earlier to defer reconnect optimizations to a
future jira?
> Convert SASL to use ProtoBuf and add lengths for non-blocking processing
> ------------------------------------------------------------------------
>
> 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: Daryn Sharp
> Attachments: HADOOP-9421.patch, HADOOP-9421.patch, HADOOP-9421.patch,
> HADOOP-9421.patch, HADOOP-9421-v2-demo.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
