Yes, an additional benefit of using Hadoop proprietary "delegation tokens" for delegation as described in HADOOP-4343, as opposed to using Kerberos TGT/Service tickets, is that Kerberos is only used at the "edge" of Hadoop. Delegation tokens don't depend on Kerberos and can be coupled with non-Kerberos authentication mechanisms (such as SSL) used at the edge.
Kan On 3/24/09 4:37 PM, "Brian Bockelman" <bbock...@cse.unl.edu> wrote: > A related meta comment. > > Our community uses X509 for a single-sign-on solution for a few > thousand physicists. There's been increased interest in HDFS lately, > and it would be very attractive to this community if Hadoop used a > lightweight, but secure solution based upon Kerberos as in HADOOP-4343 > (something like kerberos to initialize a session token and use that > with the service). > > This would be especially useful because the likely implementation > would use JSSE - we'd be able to replace the kerberos implementation > and, with a little work, drop the Globus implementation into place. > We'd be able to use our single-sign-on and make the organization very > happy. > > Brian > > On Mar 24, 2009, at 11:29 PM, Raghu Angadi wrote: > >> >> I haven't looked into the proposal, but a meta comment: >> >> I don't think there is a real reason for Hadoop to favor this design >> or only stay with HADOOP-4343 or another proposal at this state. It >> is healthy if we have different designs and implementation proceed >> independently. If you are willing to, I think you should proceed >> with a prototype so that others interested can play with. This is >> true not just for this feature, but many others as well. >> >> This of course should not discourage others from reviewing your >> design. >> >> Raghu. >> >> Amandeep Khurana wrote: >>> Bouncing the thread... Waiting to hear from people about the >>> proposal. >>> Amandeep Khurana >>> Computer Science Graduate Student >>> University of California, Santa Cruz >>> On Fri, Mar 20, 2009 at 2:47 PM, Amandeep Khurana >>> <ama...@gmail.com> wrote: >>>> 1. The Jira covers only authentication using Kerberos. I dont think >>>> Kerberos is the best way to do it since I feel the scalability is >>>> limited. >>>> All keys have to be negotiated by the Kerberos server. The design >>>> in the >>>> paper has a little different protocol for authentication. >>>> >>>> 2. The Jira doesnt have cover the access control aspect of things. >>>> As a >>>> client, I can skip talking to the NN and get blocks from the DN >>>> straight >>>> away. There is no way to prevent it. This paper takes care of that >>>> aspect as >>>> well. >>>> >>>> >>>> Amandeep Khurana >>>> Computer Science Graduate Student >>>> University of California, Santa Cruz >>>> >>>> >>>> On Fri, Mar 20, 2009 at 12:54 PM, Doug Cutting >>>> <cutt...@apache.org> wrote: >>>> >>>>> Amandeep Khurana wrote: >>>>> >>>>>> http://www.soe.ucsc.edu/~akhurana/Hadoop_Security.pdf<http://www.soe.ucsc >>>>>> .edu/%7Eakhurana/Hadoop_Security.pdf >>>>>>> >>>>>> >>>>> How does this relate to the current proposal in Jira? >>>>> >>>>> https://issues.apache.org/jira/browse/HADOOP-4343 >>>>> >>>>> Doug >>>>> >>>> >
