Thanks for the explanation Todd, Yes i float the email some days ago, on Hadoop mailing list as well with subject Hadoop-Kerberos aunthentication flow but did not get any response there.
I followed all the links you referred me to. I want to know when the program runs for user authentication from KDC, where the credential cache is stored? Because i explored all the default paths for credential caches on Linux as well as on Windows but did not find any krbcc_uid file. On Tue, Jul 19, 2016 at 2:26 AM, Todd Grayson <tgray...@cloudera.com> wrote: > 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