hadoop-common-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Raghu Angadi (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HADOOP-6419) Change RPC layer to support SASL/token based mutual authentication
Date Fri, 15 Jan 2010 20:32:54 GMT

    [ 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.

View raw message