Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 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 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.
Since you asked about the differences between TokenAuth and HSSO, here are some key ones:
TokenAuth supports TAS federation to allow clients to access multiple clusters without a centralized SSO server while HSSO provides a centralized SSO server for multiple clusters.
TokenAuth integrates authorization framework with auditing support in order to provide a complete solution for enterprise data access security. This allows administrators to administrate security polices centrally and have the polices be enforced consistently across components in the ecosystem in a pluggable way that supports different authorization models like RBAC, ABAC and even XACML standards.
TokenAuth targets support for domain based authN & authZ to allow multi-tenant deployments. Authentication and authorization rules can be configured and enforced per domain, which allows organizations to manage their individual policies separately while sharing a common large pool of resources.
TokenAuth addresses proxy/impersonation case with flow as Tianyou mentioned, where a service can proxy client to access another service in a secured and constrained way.
Regarding token based authentication plus SSO and unified authorization framework, HADOOP-9392 and HADOOP-9466 let's continue to use these as umbrella JIRAs for these efforts. HSSO targets support for centralized SSO server for multiple clusters and as we have pointed out before is a nice subset of the work proposed on HADOOP-9392. Let's align these two JIRAs and address the question Kevin raised multiple times in 9392/9533 JIRAs, "How can HSSO and TAS work together? What is the relationship?". The design update I provided was meant to provide the necessary details so we can nail down that relationship and collaborate on the implementation of these JIRAs.

As you have also confirmed, this design aligns with related community discussions, so let's continue our collaborative effort to contribute code to these JIRAs.


-----Original Message-----
From: Larry McCay [mailto:[EMAIL PROTECTED]]
Sent: Thursday, July 04, 2013 4:10 AM
To: Zheng, Kai
Subject: Re: [DISCUSS] Hadoop SSO/Token Server Components

Hi Kai -

I think that I need to clarify something...

This is not an update for 9533 but a continuation of the discussions that are focused on a fresh look at a SSO for Hadoop.
We've agreed to leave our previous designs behind and therefore we aren't really seeing it as an HSSO layered on top of TAS approach or an HSSO vs TAS discussion.

Your latest design revision actually makes it clear that you are now targeting exactly what was described as HSSO - so comparing and contrasting is not going to add any value.

What we need you to do at this point, is to look at those high-level components described on this thread and comment on whether we need additional components or any that are listed that don't seem necessary to you and why.
In other words, we need to define and agree on the work that has to be done.

We also need to determine those components that need to be done before anything else can be started.
I happen to agree with Brian that #4 Hadoop SSO Tokens are central to all the other components and should probably be defined and POC'd in short order.

Personally, I think that continuing the separation of 9533 and 9392 will do this effort a disservice. There doesn't seem to be enough differences between the two to justify separate jiras anymore. It may be best to file a new one that reflects a single vision without the extra cruft that has built up in either of the existing ones. We would certainly reference the existing ones within the new one. This approach would align with the spirit of the discussions up to this point.

I am prepared to start a discussion around the shape of the two Hadoop SSO tokens: identity and access. If this is what others feel the next topic should be.
If we can identify a jira home for it, we can do it there - otherwise we can create another DISCUSS thread for it.


On Jul 3, 2013, at 2:39 PM, "Zheng, Kai" <[EMAIL PROTECTED]> wrote:

NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB