[
https://issues.apache.org/jira/browse/HADOOP-2184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12545541
]
Doug Cutting commented on HADOOP-2184:
--------------------------------------
So if we elect not to yet implement this with a socket factory interface, then
I think we're back to passing it in the invocation. Owen, do you have
objections to this as a short-term technique? My concern is that the APIs for
RPC clients and servers not change incompatibly when we move to a
socket-factory. That rules out getProtocolVersion(). Call invocations are
invisible to the application, so they seem a fine place to pass tickets for now.
The API changes should be:
- on the client, the proxy constructor should take a ticket parameter;
- on a server, within a method implementation, one should be able to call a
static getTicket() to retrieve the ticket from a thread local.
In the future, we may add a socket-factory API for RPC, but that shouldn't
require changes to the above. Perhaps we'll name RPC servers with a URI
instead of an InetSocketAddress. Then we can use the URI scheme to identify a
socket factory. We can leave the existing InetSocketAddress API for
back-compatibility for a release or two, using a default socket factory. Would
that be sufficient?
But I'm okay leaving that for later. Owen?
> 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.
