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 -

I missed your #4 in my summary and takeaways of the session in another thread on this list.

I believe that the points of discussion were along the lines of:

* put common security libraries into common much the same way as hadoop-auth is today making each available as separate maven modules to be used across the ecosystem
* the was a concern raised that we need to be cognizant of not using common as a "dumping grounds"
- I believe this to mean that we need to ensure that the libraries that are added there are truly cross cutting and can be used by the other projects across Hadoop
- I think that security related things will largely be of that nature but we need to keep it in mind

I'm not sure whether #3 is represented in the other summary or not…

There was certainly discussions around the emerging work from Daryn related to pluggable authentication mechanisms within that layer and we will immediately have the options of kerberos, simple and plain. There was also talk of how this can be leveraged to introduce a Hadoop token mechanism as well.

At the same time, there was talk of the possibility of simply making kerberos easy and a non-issue for intra-cluster use. Certainly we need both of these approaches.
I believe someone used ApacheDS' KDC support as an example - if we could standup an ApacheDS based KDC and configure it and related keytabs easily than the end-to-end story is more palatable to a broader user base. That story being the choice of authentication mechanisms for user authentication and easy provisioning and management of kerberos for intra-cluster service authentication.

If you agree with this extended summary then I can update the other thread with that recollection.
Thanks for providing it!


On Jul 4, 2013, at 4:09 PM, Alejandro Abdelnur <[EMAIL PROTECTED]> wrote:

> 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.
> Thanks.
> 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