Neela, depending on distribution in use, much of the discussion is here
https://hadoop.apache.org/docs/r2.6.0/hadoop-auth/Configuration.html The service (in this case Hadoop core across a subset of the services) gets its ticket granting ticket as it starts up. The user or client application as well. Each one independently gets its own service ticket to act with the service. They do not over-write each other, each client maintains its context, the one that directly interacts with the hadoop sevice must be presenting its own credentials, not the end users (in most cases, but there are variances for older/simpler components). When you are using a structure like the one you are presenting, generally the authentication starts with the user having kerberos authentication into "my application" via SPNEGO if http, or otherwise if CLI context your using tools such as the hadoop security client classes. When front ending the application interaction with a web application that is java based, you extend your implementation through the jaas layer to handle web based kerberos authentication "SPNEGO" be the interface to your app. The app on the backend then would be authenticating as a service against hadoop, and depending on the components, present their session as "doing as" a realm authenticated user. I would suggest reviewing this blog for context and what to consider as you attempt to use whats called "kerberos impersonation" to have the chain of authentication you are indicating in your diagram. http://dewoods.com/blog/hadoop-kerberos-guide The better mail list to continue on would probably be based on the component you are using as you are getting into application development through a specific toolkit (hadoop) over kerberos... as the MIT kerberos core list team might not appreciate us going down the Hadoop path so specifically within the list. A great content set to start with so you get a deeper understanding of the underlying kerberos concepts you need to understand in general is here: http://web.mit.edu/kerberos/krb5-latest/doc/ with some handy considerations to keep in mind here when creating apps based on kerberos. http://web.mit.edu/kerberos/krb5-latest/doc/admin/appl_servers.html On Mon, Jul 18, 2016 at 2:46 PM, Aneela Saleem <ane...@platalytics.com> wrote: > Thanks Brandon and Todd, > > I still have some confusions. Please guide me I'm just a beginner. > > At the current stage I'm not implementing single-sign on. Here is the flow > of our application > > Screenshotfrom2016-07-12171018.jpg > > <https://drive.google.com/a/platalytics.com/file/d/0BytQ11DT_A8HUjhIcUU2bm1PSlU/view?usp=drivesdk> > > > User1 logged into our application through password based authentication. > After that when the user tries to access the Kerberized Hadoop cluster > it gets the authentication token from KDC, and the credential cache for > this user is stored on the client machine where the application is > running and user1 accesses the cluster. Meanwhile another user (I.e., > user2 ) logs into the application and tries to accesses the kerberized > cluster. Now when it gets the token from KDC, will the credentials of user1 > be override by the user2's credentials? If so, then how to solve this > particular scenario? I'm not getting the clear idea > > Thanks > > On Monday, 18 July 2016, Todd Grayson <tgray...@cloudera.com> wrote: > >> (and I realize kerberos doesn't do groups) >> >> On Mon, Jul 18, 2016 at 12:05 PM, Todd Grayson <tgray...@cloudera.com> >> wrote: >> >>> Aneela, >>> >>> HDFS supports the use of the \L lowercase "macro". This is implemented >>> through the HDFS auth_to_local rules, it can be applied using the >>> additional rules if within the CDH. The relationship for kebreros from >>> hadoop (for a major portion of the platform) traverses the java JGSS >>> implementation + hadoop security core classes. (Might be the better thread >>> to shift to if you need deeper discussion?) >>> >>> This is described in the apache hadoop upstream Jira HADOOP-10556 >>> >>> But I agree discussion the approach on getting agreement on the >>> structure of username, uppercase/lowercase and group name in general is >>> something to be having. >>> >>> >>> On Mon, Jul 18, 2016 at 9:41 AM, Brandon Allbery < >>> ballb...@sinenomine.net> wrote: >>> >>>> While I can’t give you details, it sounds like you want to change the >>>> web application to use SPNEGO to do Kerberos authentication with a user; >>>> this gives you a credential that you can then use to authenticate to >>>> Hadoop. >>>> >>>> From: Aneela Saleem <ane...@platalytics.com> >>>> Date: Monday, July 18, 2016 at 11:13 >>>> To: Brandon Allbery <ballb...@sinenomine.net> >>>> Cc: "kerberos@mit.edu" <kerberos@mit.edu> >>>> Subject: Re: Login usecase >>>> >>>> Thanks Brandon for your response. >>>> >>>> Actually, My use-case is that I have a web application that >>>> authenticates a user. Then user calls my backend services written in java >>>> to interact with hadoop cluster. My hadoop cluster is kerberos-enabled. I >>>> need to authenticate this user using my java code. I am able to login using >>>> keytab files, but i did not get someway to login using password. For >>>> logging in using keytab files, we need to place keytab files for all the >>>> system users on all the hosts from where we can access our hadoop cluster. >>>> So this is the main drawback. And as you say logging using keytab files is >>>> not appropriate then how can we achieve this objective? >>>> >>>> Thanks >>>> >>>> On Mon, Jul 18, 2016 at 7:45 PM, Brandon Allbery < >>>> ballb...@sinenomine.net<mailto:ballb...@sinenomine.net>> wrote: >>>> You are going to have to describe what you are trying to do in more >>>> detail. Keytabs are not normally used for this purpose, except in the case >>>> of automated procedures (e.g. cron) that need to log in to a service as if >>>> they are a user. Perhaps you have confused keytabs (“passwords” on disk) >>>> with ccaches (ephemeral service credentials, which may or may not be on >>>> disk and typically expire in a relatively short time)? >>>> >>>> On 7/17/16, 16:04, "kerberos-boun...@mit.edu<mailto: >>>> kerberos-boun...@mit.edu> on behalf of Aneela Saleem" < >>>> kerberos-boun...@mit.edu<mailto:kerberos-boun...@mit.edu> on behalf of >>>> ane...@platalytics.com<mailto:ane...@platalytics.com>> wrote: >>>> >>>> Hi all, >>>> >>>> If a user logs into any kerberized Application, using >>>> Krb5LoginModule, >>>> there is a function loginFromKeyTab. Client should have the key tab >>>> file to >>>> login to application. But I think this is very insecure way of >>>> login. >>>> Anyone who cloud access your key tab file then login to >>>> application. Is >>>> there any appropriate way to login to system. I don't understand >>>> How to do >>>> this. I'm stuck >>>> >>>> Thanks >>>> ________________________________________________ >>>> Kerberos mailing list Kerberos@mit.edu<mailto: >>>> Kerberos@mit.edu> >>>> https://mailman.mit.edu/mailman/listinfo/kerberos >>>> >>>> >>>> ________________________________________________ >>>> Kerberos mailing list Kerberos@mit.edu >>>> https://mailman.mit.edu/mailman/listinfo/kerberos >>>> >>> >>> >>> >>> -- >>> Todd Grayson >>> Business Operations Manager >>> Customer Operations Engineering >>> Security SME >>> >>> >> >> >> -- >> Todd Grayson >> Business Operations Manager >> Customer Operations Engineering >> Security SME >> >> -- Todd Grayson Business Operations Manager Customer Operations Engineering Security SME
________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos