[
https://issues.apache.org/jira/browse/HADOOP-2184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12543757
]
Raghu Angadi commented on HADOOP-2184:
--------------------------------------
bq. If we want to send only for the fist call, then we need to make sure no
other RPCs are sent till the first one completes. If first call fails (times
out), it should send the ticket with the second call. I think this can be done
and not more complicated than current patch. Should I?
bq. I will check how to distinguish a "ghost parameter" on the server side.
I like this approach. Ticket is a property of Invoker (thus property of an RPC
proxy). This increases each RPC with serialization of an extra boolean, which
is fine (more than offset by not requiring extra rpc).
Any objections?
As it is implemented now, this is independent of SocketFactory. Please propose
a structure if you think it should be part of some new SocketFactory and how
this SocketFactory works with other SocketFactories (say for SOCKS proxy). Also
how it affects the server side. Note that current proposal is transparent to
the user and later if a much better SocketFactory interface is proposed, we can
change to that.
> 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
>
>
> 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.
