[
https://issues.apache.org/jira/browse/HADOOP-2184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12544023
]
Doug Cutting commented on HADOOP-2184:
--------------------------------------
> It is a separate issue.. the reason I mentioned now because if we want to fix
> it anytime, we might need to something pretty close what my patch does. So
> thought we might as well do it now.
But not as a part of this issue, since we I don't think we need such
functionality here. Here I think we're better served by passing the ticket in
the Invocation, even if we did have that functionality, since we don't want to
make the Server implementation have to set the ticket, but rather want the RPC
framework to store the ticket on the server for us.
> I didn't quite follow the above. But on client side, do you think we need to
> something close to 'calling one RPC inside another'?
No, I don't see why (in fixing that other issue) we won't be able to call
another RPC method at the end of Server#getConnection() without changing much
else. Perhaps there will be problems, and perhaps we'll have to resort to
something like what you proposed in this issue. And perhaps even that will be
usable in this issue. I don't yet see that. If you believe it strongly, then
perhaps you should fix that other issue first. But, for this issue, I think
adding the ticket to the Invocation is sufficient for now.
> 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.
