[
https://issues.apache.org/jira/browse/HADOOP-9421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13630548#comment-13630548
]
Daryn Sharp commented on HADOOP-9421:
-------------------------------------
The main problem we have is clients cannot work with a heterogenous mix of
secure & non-secure servers.
The current protocol exchange is: Upon connection, the client sends a
connection header which includes the auth method it intends to use, and then
immediately the client follows with an initial SASL response. If the server
supports the auth method, the client and server exchange SASL tokens until
either side's SASL client or server decides negotiation is complete, else the
server sends switch to simple.
This is a very rigid implementation. It was designed with an assumption the
SASL mechanism is kerberos or nothing (simple). The design needs to be
extended to support multiple SASL mechanisms that the client and server can
mutually agree upon. Some of the current problems are:
# The client is dictating the auth method to the server. The server cannot
tell the client its supported mechanisms. It can only reject the client or
switch to simple auth.
# If the client's SASL client doesn't support an initial SASL response, none is
sent and the server hangs waiting for the client.
# The client & server don't handle non-sasl exceptions during a sasl exchange
(last I knew anyway).
# The client and server don't have a definitive way to know that authentication
is complete. Each side assumes auth is done if it's SASL object thinks it's
done. I had to hack a positive acknowledgement into the server for the SASL
PLAIN mechanism.
What I'd propose at a high-level is the following. Note I didn't fill in all
the cracks for brevity:
# Client sends a connection header (auth method is irrelevant)
# Server responds with (<sasl-challenge>, <mechanism>, <protocol>, <token>)
# Client attempts to instantiate a SaslClient based on the mechanism+protocol
#- Supported: (<sasl-continue>, <evaluated-token>)
#-- (<sasl-continue>, <token>) exchange continues until server responds:
#--# (<sasl-auth-ok>)
#--# (<sasl-error>, <message>)
#- Not supported: (<sasl-next>)
#-- Server responds:
#--# More supported auth methods, goto #2
#--# No remaining auth methods: (<sasl-error>, <message>)
The benefits are:
# The server is now in full control of directing authentication
# Client may work in a heterogenous environment of diverse auth methods
# SASL api's support for multiple mechanisms is leveraged
# SASL mechanism support now becomes pluggable and extensible
# Multiple auth methods may share the same SASL mechanism, ex. DIGEST-MD5, via
SASL api's protocol field
# Simple auth is replaced by SASL PLAIN
# The IPC SASL implementation becomes dramatically simpler
I've already attempted something very similar in the past, but discarded it
because it was completely incompatible. If this is a reasonable design, I can
take a POC stab at it.
> 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
