Mailing-List: contact common-issues-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: common-issues@hadoop.apache.org
Date: Fri, 21 Jun 2013 08:44:21 +0000 (UTC)
From: "Luke Lu (JIRA)" <jira@apache.org>
To: common-issues@hadoop.apache.org
Message-ID: <JIRA.12638070.1363810059559.154164.1371804261990@arcas>
In-Reply-To: <JIRA.12638070.1363810059559@arcas>
References: <JIRA.12638070.1363810059559@arcas>
Subject: [jira] [Commented] (HADOOP-9421) Convert SASL to use ProtoBuf and
 add lengths for non-blocking processing
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/HADOOP-9421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13690136#comment-13690136 ] 

Luke Lu commented on HADOOP-9421:
---------------------------------

bq. There is nothing in the protocol that would prevent SCRAM being supported.

I meant you'll be SOL to make the token optimization work. Your protocol *requires* an extra round trip to support SCRAM.

bq. Guessing a supported auth/mechanism

For most common hadoop auth work load: distributed containers/tasks, you don't need to guess, it's the delegation token with digest-md5/scram, as it's a framework internal token bootstrapped by other public facing mechanisms. For other use cases, you can use cached values. For the remaining use cases, the client can send an empty INITIATE and use NEGOTIATE and REINITIATE with the same total round-trip cost as yours in all cases. With the optional client initiate, my protocol gives the choices to the practicing system designers instead of the original protocol designers.

bq. Dealing with the mishaps when the client blows itself up trying an auth the server doesn't even support

INITIATE contains the same extra info like protocol and serverId for preferred auth. Server can simply send a NEGOTIATE if it decides that it cannot support the preferred auth choice, the client can then decide to REINITIATE or abort.

bq. if it even attempts kerberos with a non-kerberos server. It won't even succeed far enough to send the INITIATE

For this contrived case, the client can catch exceptions for the preferred auth when generating the initial token, which would apply to fetching service ticket for non-kerberos server, and send an empty INITIATE to NEGOTIATE and REINITIATE. Again for integration clients that need to talk to multiple servers with different auths it can simply use empty INITIATE to NEGOTIATE and cache the server auth/mechs for later use to save a round-trip later.

Imagine a busy interactive web console that talk to multiple back-end Hadoop servers, it's not feasible to keep a connection per user open to all these servers, you often need to constantly creating new connections to the back-end servers (a connection pool helps), my protocol allows the web console to save a mandatory round-trip from yours, which can make the interactive user experience much better due to lowered latencies.

In summary, my protocol gives that choice to real system designers. Your protocol takes away that choice because you could not possibly think of all use cases, where auth latency matters.
                
> 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
>            Priority: Blocker
>         Attachments: HADOOP-9421.patch, HADOOP-9421.patch, HADOOP-9421.patch, HADOOP-9421.patch, 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