Mailing-List: contact common-issues-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: common-issues@hadoop.apache.org
Message-ID: <2116527355.273941263587574578.JavaMail.jira@brutus.apache.org>
Date: Fri, 15 Jan 2010 20:32:54 +0000 (UTC)
From: "Raghu Angadi (JIRA)" <jira@apache.org>
To: common-issues@hadoop.apache.org
Subject: [jira] Commented: (HADOOP-6419) Change RPC layer to support
 SASL/token based mutual authentication
In-Reply-To: <1162452186.1260301038197.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Raghu Angadi commented on HADOOP-6419:
--------------------------------------

+1 for client side to start with.

It is fairly straight fwd to extend a java.net.Socket through a SocketFactory. 

But to achieve the same for nio channels transparently requires "SocketChannelFactory" (and "ServerSocketChannelFactory", etc).  I don't know of any working examples of such factories that create a custom socket channel that works transparently.

I suspect, the reason is that the whole channel interface and implementation in Java is pretty complicated involves multiple classes interacting together. We might have to implement not just our own SocketChannel, but SelectorProvider, Select etc. 

Many frameworks handle these issues by providing their own i/o api and by adding support for pluggable protocols in a 'chain of control' pattern *above* the socket io layer. 

In our context, short term we could start with a simple i/o interface (connect, read, write, getChannelForSelect()) that would support pluggable protocol for client and server sides of RPC.. Ideally we would  move to NIO framework like netty, but that would much larger effort.

In summary, I don't think we can easily implement SocketChannel factories or is the recommended direction to proceed.


> Change RPC layer to support SASL/token based mutual authentication
> ------------------------------------------------------------------
>
>                 Key: HADOOP-6419
>                 URL: https://issues.apache.org/jira/browse/HADOOP-6419
>             Project: Hadoop Common
>          Issue Type: New Feature
>          Components: security
>            Reporter: Kan Zhang
>            Assignee: Kan Zhang
>         Attachments: c6419-26.patch
>
>
> The authentication mechanism to use will be SASL DIGEST-MD5 (see RFC-2222 and RFC-2831). Since J2SE 5, Sun provides a SASL implementation by default. Both our delegation token and job token can be used as credentials for SASL DIGEST-MD5 authentication.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.