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 Tianyou -

As was discussed on the pre-summit calls, we were approaching the summit from a clean slate.
Perhaps, that wasn't articulated in the summary of those calls very well - I thought that it was.

In any case, the agreed upon approach to move forward was to agree on the moving parts that needed to be worked on, prioritize them and start creating subtasks for them.
Using one of the existing jiras would work for this but using both doesn't make a lot of sense to me.

My wording regarding the alignment of 9392 and 9533 is regrettable.
The point is that the SSO server instance/s based approach that is now apparent in 9392 is very much the same thing that 9533 attempted to introduce.

Yes, there are a number of differences that exist in details that are in the documents. If we are starting from a clean slate then it is too early to talk about many of those details.
Part of the difficulty in reconciling the two jiras has been related to having to consume the whole thing at once and try and agree on all the details of all the components - much like trying to boil the ocean all at once.
Starting anew allows us to:
1. establish and agree on the components and broad stroke interaction patterns.
2. identify individual pieces to work on and agree on their finer details - this is where the differences will be rationalized
3. break up the workload and deliver the overall vision

This approach allows us to boil the ocean one pot at a time.

If you would like to keep the jiras separate - which I would see as unfortunate - then the server instance aspects should be in 9533.
This would include the endpoints used for the flows, the hosting of the pluggable authentication mechanisms created in 9392, trust relationship management required across instances, etc.
9533 is a jira for a Hadoop SSO Server.

Unfortunately, I believe this approach would leave us exactly where where we started.

So, again the discussion points were not really addressed.
It seems that you and Kai have provided your preference for the jira question - though you have really added another option which is keep things the same - which we can make work.

We still need an opinion on the list of components in this thread.
My suggestion is that you take your document and make sure that from a high level all the major components are represented here.
If not, describe anything else that is needed and why.

We also need to determine the first component to drill down into. Brain and I both see the HSSO Tokens as central to the implementations of other components and should probably be tackled first.
By the way, this drilling down into the details of each of the components is where we will rationalize the differences in implementations/approaches.

> Our updated design doc clearly addresses the authorization and proxy flow which are important for users.
Yes - this is goodness. I don't see the fact that more flows are described as a difference.
Those use cases that are needed by our users will need to be implemented.
Once we get to the components that need to provide for these flows we will need to define them for that component/s.

> HSSO can continue to be layered on top of TAS via federation.

I don't know what this actually means.
HSSO was to be a SSO server instance that hosts the endpoints for the required flows in acquiring the necessary tokens.
You would have to explain to me what layering on top of TAS via federation means.
In fact, I don't even want to reference HSSO in this thread anymore - its aspects are represented in the components list of this thread as the SSO Server Instance.

> Please review the design doc we have uploaded to understand the differences. I am sure Kai will also add more details about the differences between these JIRAs.

At this point, it is important that you make sure the components represented in this thread are sufficient for your ideas.
We will not be well served by continuing to compare and contrast.
This thread and those to follow are part of the collaboration process - once the work items are identified through this thread the collaboration on individual components can certainly happen in jiras.
If we want a new jira to host this higher level discussion that is fine too.
You should use your work on 9392 within this process to help drive the discussion and definition of the components identified here.


At this point, I think that we should commit to moving this thread forward and not backward by pointing to silo'd jiras.
This highest level pass of identifying the components should have been the easy part.
We need close down on this list and move on to the more challenging discussions of the component details.

Can we do this?
Is there another approach that folks would like to take here?

On Jul 4, 2013, at 12:19 AM, "Li, Tianyou" <[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