Login usecase

Tue Jul 19 06:08:03 EDT 2016

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 <tgrayson at 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 <aneela at 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 <tgrayson at cloudera.com> wrote:
>>
>>> (and I realize kerberos doesn't do groups)
>>>
>>> On Mon, Jul 18, 2016 at 12:05 PM, Todd Grayson <tgrayson at 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 <
>>>> ballbery at 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 <aneela at platalytics.com>
>>>>> Date: Monday, July 18, 2016 at 11:13
>>>>> To: Brandon Allbery <ballbery at sinenomine.net>
>>>>> Cc: "kerberos at mit.edu" <kerberos at 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 <
>>>>> ballbery at sinenomine.net<mailto:ballbery at 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-bounces at mit.edu<mailto:
>>>>> kerberos-bounces at mit.edu> on behalf of Aneela Saleem" <
>>>>> kerberos-bounces at mit.edu<mailto:kerberos-bounces at mit.edu> on behalf
>>>>> of aneela at platalytics.com<mailto:aneela at 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 at mit.edu<mailto:
>>>>> Kerberos at mit.edu>
>>>>>     https://mailman.mit.edu/mailman/listinfo/kerberos
>>>>>
>>>>>
>>>>> ________________________________________________
>>>>> Kerberos mailing list           Kerberos at 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
>
>