[
https://issues.apache.org/jira/browse/HADOOP-2184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12544556
]
Doug Cutting commented on HADOOP-2184:
--------------------------------------
> I think it makes the most sense to have the socket factory pass the ticket
> across, because the socket factory will need the ticket to set up the
> encryption. The next best place is in getProtocolVersion [...]
getProtocolVersion() doesn't work, for reasons I cited above: it makes the
server implementation implement things that should be implemented by the
framework. The ticket should be passed transparently by the framework.
> In either case, I don't see any justification for putting it on each method.
> If different methods have different tickets they must have different
> connections anyways.
Why? On the server side each request is handled independently, there's no
session associated with a connection. So, in theory, there's no reason we
couldn't have a different ticket passed with each call. Of course, once we
start using the ticket for connection encryption this would be impractical.
Also, we don't expect to use tickets this way. I think we mostly expect each
JVM to consistently use the same ticket. (The jobtracker and tasktracker will
merely pass the users ticket down to the task process, but should never pose as
the user.)
So, in the end, to support per-ticket encryption, it seems that tickets must be
handled as a part of a connection factory interface, and Client and Server
should be re-structured to support that. Any other approach is short-term, no?
The interface might looks something like:
{noformat}
public interface IpcSockets {
SocketFactory getClientSocketFactory(Ticket ticket);
ServerSocketFactory getServerSocketFactory();
}
public class IpcSocket extends Socket{
public Ticket getTicket();
}
{noformat}
Does that look right? Any reason not to do this now, if we need to eventually?
> RPC Support for user permissions and authentication.
> ----------------------------------------------------
>
> Key: HADOOP-2184
> URL: https://issues.apache.org/jira/browse/HADOOP-2184
> Project: Hadoop
> Issue Type: New Feature
> Components: ipc
> Affects Versions: 0.15.0
> Reporter: Tsz Wo (Nicholas), SZE
> Assignee: Raghu Angadi
> Fix For: 0.16.0
>
> Attachments: HADOOP-2184-demo.patch, HADOOP-2184-demo.patch,
> HADOOP-2184-demo.patch
>
>
> Update 11/13/2007: What is proposed for 0.16.0 :
> The client can set a user ticket (as defined in HADOOP-1701) for each
> connection and that ticket is made available to RPC calls at the server. The
> client can replace the ticket at any time. The main advantage is that rest of
> the the client RPCs don't need to be aware of the user tickets.
> What RPC would ideally support in future :
> In the current version of RPC, there is no authentication or data protection.
> We propose to change the RPC framework, so that secure communication is
> possible.
> The new RPC should:
> - Compatible with current RPC
> - Allow a pluggable security implementations (see HADOOP-1701)
> - Support both secure and non-secure modes.
> Here is a rough idea:
> - Store security information (e.g. username, keys) in a ticket
> - Use the ticket to establish a RPC connection
> - Create secure sockets by the (subclass of) SocketFactory corresponding to
> the selected security implementations
> - Send the data and RPC parameters with the secure sockets
> When authentication is supported, the RPC callee should also initialize
> caller information during RPC setup and execute the RPC on the caller's
> behalf.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
