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

I'm not sure how I am failing to communicate this but will try to briefly do it again…

I never asked for differences between the two silo'd jiras and am attempting to not speak to them within this thread as that is causing thrashing that we can't really afford.

There have been a number of folks working on security features within the community across projects. Many of these things have been rather isolated things that needed to be done and not much community involvement was needed. As we look into these larger endeavors working in silos without a cohesive community is a problem. We are trying to introduce a community for security as a cross cutting concern throughout the Hadoop ecosystem.

In order to do this, we need to step back and approach the whole effort as a community. We identified a couple ways to start this:
1. using common-dev as the security community email list - at least for the time being
2. finding a wiki space to articulate a holistic view of the security model and drive changes from that common understanding
3. begin the community work by focusing on this authentication alternative to kerberos

Here is what was agreed upon to be discussed by the community for #3 above:
1. restart with a clean slate - define and meet the goals of the community with a single design/vision
2. scope the effort to authentication while keeping in mind not to preclude other related aspects of the Hadoop security roadmap - authorization, auditing, etc
3. we are looking for an alternative to kerberos authentication for users - not for services - for at least for the first phase services would continue to authenticate using kerberos - though it needs to be made easier
4. we would enumerate the high level components needed for this kerberos alternative
5. we would then drill down into the details of the components
5. finally identify the seams of separation that allow for parallel work and get the vision delivered

This email was intended to facilitate the discussion of those things.
To compare and contrast the two silo'd jiras sets this community work back instead of moving it forward.

We have a need with a very manageable scope and could use your help in defining from the context of your current work.

As Aaron stated, the community discussions around this topic have been encouraging and I also hope that they and the security community continue and grow.

Regarding the discussion points that still have not been addressed, I can see one possible additional component - though perhaps it is an aspect of the authentication providers - that you list below as a one of the "differences". That would be your thinking around the use of domains for multi-tenancy. I have trouble separating user domains from the IdPs deployed in the enterprise or cloud environment. Can you elaborate on how these domains relate to those that may be found within a particular IdP offering and how they work together or complement each other? We should be able to determine whether it is an aspect of the pluggable authentication providers or something that should be considered a separate component from that description.

I will be less available for the rest of the day - 4th of July stuff.

On Jul 4, 2013, at 7:21 AM, "Zheng, Kai" <[EMAIL PROTECTED]> wrote:

> Hi Larry,
> Our design from its first revision focuses on and provides comprehensive support to allow pluggable authentication mechanisms based on a common token, trying to address single sign on issues across the ecosystem to support access to Hadoop services via RPC, REST, and web browser SSO flow. The updated design doc adds even more texts and flows to explain or illustrate these existing items in details as requested by some on the JIRA.
> Additional to the identity token we had proposed, we adopted access token and adapted the approach not only for sake of making TokenAuth compatible with HSSO, but also for better support of fine grained access control, and seamless integration with our authorization framework and even 3rd party authorization service like OAuth Authorization Server. We regard these as important because Hadoop is evolving into an enterprise and cloud platform that needs a complete authN and authZ solution and without this support we would need future rework to complete the solution.