hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Doug Cutting (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HADOOP-2184) RPC Support for user permissions and authentication.
Date Mon, 26 Nov 2007 21:46:43 GMT

    [ https://issues.apache.org/jira/browse/HADOOP-2184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12545615
] 

Doug Cutting commented on HADOOP-2184:
--------------------------------------

> btw, these are exactly the API changes in the attached patch.

The current patch also includes a public setTicket() method which I don't think this is required.
 And the static ticket methods might better reside on RPC than Server, since they're RPC-specific.

The implementation in the current patch adds RPC-specifics to Server.java and Client.java,
where previously RPC was layered cleanly on top of these classes.  The logic to detect when
the ticket has been transmitted could instead by implemented by adding a package-private responseRecieved(Writable
param, Writable response) method to Client that does nothing by default, and have RPC use
a Client subclass that overrides this method to maintain the ticketSent flag.  That would
better localize this ticket mechanism, which is desirable, since we intend to replace it long-term.


> 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.


Mime
View raw message