Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
Hadoop >> mail # dev >> [DISCUSS] Hadoop SSO/Token Server Components

Copy link to this message
RE: [DISCUSS] Hadoop SSO/Token Server Components
Hi Alejandro,

Thanks for our summary and points. No correction I'm having and just some updates from our side for further discussion.

> we should make sure that UserGroupInformation and RPC security logic work with a pluggable GSS implementation.
Right. I'm working on implementing a token authn method in current Hadoop RPC and SASL framework, and changing the UGI class.

> Create a common security component ie 'hadoop-security' to be 'the' security lib for all projects to use.
Sure we will put our codes for the new AuthN & AuthZ frameworks into the 'hadoop-security' component for the ecosystem. I guess this component should be a collection of related projects and it's in line with hadoop-common right?

As we might agree that the key to all of these is to implement the token authentication method for client to service to start with. Hopefully I can finish and provide my working codes as a patch for the discussion.

Thanks & regards,

-----Original Message-----
From: Alejandro Abdelnur [mailto:[EMAIL PROTECTED]]
Sent: Friday, July 05, 2013 4:09 AM
Subject: Re: [DISCUSS] Hadoop SSO/Token Server Components

Leaving JIRAs and design docs aside, my recollection from the f2f lounge discussion could be summarized as:

1* Decouple users-services authentication from (intra) services-services authentication.

The main motivation for this is to get pluggable authentication and integrated SSO experience for users.

(we never discussed if this is needed for external-apps talking with Hadoop)

2* We should leave the Hadoop delegation tokens alone

No need to make this pluggable as this is an internal authentication mechanism after the 'real' authentication happened.

(this is independent from factoring out all classes we currently have into a common implementation for Hadoop and other projects to use)

3* Being able to replace kerberos with something else for (intra) services-services authentication.

It was suggested that to support deployments where stock Kerberos may not be an option (i.e. cloud) we should make sure that UserGroupInformation and RPC security logic work with a pluggable GSS implementation.

4* Create a common security component ie 'hadoop-security' to be 'the'
security lib for all projects to use.

Create a component/project that would provide the common security pieces for all projects to use.


If we agree with this, after any necessary corrections, I think we could distill clear goals from it and start from there.


Tucu & Alejandro

On Thu, Jul 4, 2013 at 11:40 AM, Andrew Purtell <[EMAIL PROTECTED]> wrote:

> Hi Larry (and all),
> Happy Fourth of July to you and yours.
> In our shop Kai and Tianyou are already doing the coding, so I'd defer
> to them on the detailed points.
> My concern here is there may have been a misinterpretation or lack of
> consensus on what is meant by "clean slate". Hopefully that can be
> quickly cleared up. Certainly we did not mean ignore all that came
> before. The idea was to reset discussions to find common ground and
> new direction where we are working together, not in conflict, on an
> agreed upon set of design points and tasks. There's been a lot of good
> discussion and design preceeding that we should figure out how to port
> over. Nowhere in this picture are self appointed "master JIRAs" and
> such, which have been disappointing to see crop up, we should be
> collaboratively coding not planting flags.
> I read Kai's latest document as something approaching today's
> consensus (or at least a common point of view?) rather than a historical document.
> Perhaps he and it can be given equal share of the consideration.
> On Wednesday, July 3, 2013, Larry McCay wrote:
> > Hey Andrew -
> >
> > I largely agree with that statement.
> > My intention was to let the differences be worked out within the
> > individual components once they were identified and subtasks created.
> >
> > My reference to HSSO was really referring to a SSO *server* based