hadoop-common-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daryn Sharp (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HADOOP-9421) Add full length to SASL response to allow non-blocking readers
Date Fri, 12 Apr 2013 19:50:17 GMT

    [ 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

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

# 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
# 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

View raw message