Login usecase

Todd Grayson tgrayson at cloudera.com
Mon Jul 18 17:26:43 EDT 2016 

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

More information about the Kerberos mailing list