[
https://issues.apache.org/jira/browse/HADOOP-2184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12545988
]
Doug Cutting commented on HADOOP-2184:
--------------------------------------
> Client sends the ticket as the connection header.
That's another fine stopgap, until we have a socketfactory-based version.
Let's see how much it disrupts the code. Would Client's constructor take a
ticket? And would RPC's Client cache be keyed by <socketfactory,ticket>? That
could work.
Since we already actually support socketfactories in RPC, why not just go all
the way, and add the ticket as a parameter to the socketfactory's construction?
Then we can do something like:
{noformat}
public class UsernameSockets implements IpcSockets {
public SocketFactory getClientSocketFactory(final Ticket ticket) {
return new SocketFactory() {
public createSocket() {
return new Socket(new UsernameSocketImpl(ticket,
SocketFactory.getDefault().createSocket());
}
}
}
private static class UsernameSocketImpl extends FilterSocketImpl {
public UsernameSocketImpl(Ticket ticket, Socket socket) {
super(socket);
}
public void connect(SocketAddress address, int timeout) {
super.connect(address, timeout);
getOutputStream().write(ticket);
}
}
public ServerSocketFactory getServerSocketFactory() {
return new ServerSocketFactory() {
public ServerSocket createServerSocket(int port, int backlog, InetAddress
if) {
return new
UsernameServerSocket(ServerSocketFactory.getDefault().createServerSocket(port,backlog,if));
}
}
}
private static class UsernameServerSocket extends FilterServerSocket
implements Ticketable {
private Ticket ticket;
public UsernameServerSocket(ServerSocket ss) {
super(ss);
}
public Socket accept() {
Socket result = super.accept();
ticket = Ticket.read(result.getInputStream());
return result;
}
public Ticket getTicket() { return ticket; }
}
}
{noformat}
There's a lot of boilerplate code required to implement FilterSocketImpl and
FilterServerSocket, but I think this is the direction we want long-term anyway.
It shouldn't change the API we expose publicly.
> 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.
