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, all-

There seems to be agreement on the broad stroke description of the components needed to achieve pluggable token authentication (I'm sure I'll be corrected if that isn't the case). However, discussion of the details of those components doesn't seem to be moving forward. I think this is because the details are really best understood through code. I also see *a* (i.e. one of many possible) token format and pluggable authentication mechanisms within the RPC layer as components that can have immediate benefit to Hadoop users AND still allow flexibility in the larger design. So, I think the best way to move the conversation of "what we are aiming for" forward is to start looking at code for these components. I am especially interested in moving forward with pluggable authentication mechanisms within the RPC layer and would love to see what others have done in this area (if anything).



-----Original Message-----
From: Alejandro Abdelnur [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, July 10, 2013 8:15 AM
To: Larry McCay
Subject: Re: [DISCUSS] Hadoop SSO/Token Server Components

Larry, all,

Still is not clear to me what is the end state we are aiming for, or that we even agree on that.

IMO, Instead trying to agree what to do, we should first  agree on the final state, then we see what should be changed to there there, then we see how we change things to get there.

The different documents out there focus more on how.

We not try to say how before we know what.

On Wed, Jul 10, 2013 at 6:42 AM, Larry McCay <[EMAIL PROTECTED]> wrote:

> All -
> After combing through this thread - as well as the summit session
> summary thread, I think that we have the following two items that we
> can probably move forward with:
> 1. TokenAuth method - assuming this means the pluggable authentication
> mechanisms within the RPC layer (2 votes: Kai and Kyle) 2. An actual
> Hadoop Token format (2 votes: Brian and myself)
> I propose that we attack both of these aspects as one. Let's provide
> the structure and interfaces of the pluggable framework for use in the
> RPC layer through leveraging Daryn's pluggability work and POC it with
> a particular token format (not necessarily the only format ever
> supported - we just need one to start). If there has already been work
> done in this area by anyone then please speak up and commit to
> providing a patch - so that we don't duplicate effort.
> @Daryn - is there a particular Jira or set of Jiras that we can look
> at to discern the pluggability mechanism details? Documentation of it
> would be great as well.
> @Kai - do you have existing code for the pluggable token
> authentication mechanism - if not, we can take a stab at representing
> it with interfaces and/or POC code.
> I can standup and say that we have a token format that we have been
> working with already and can provide a patch that represents it as a
> contribution to test out the pluggable tokenAuth.
> These patches will provide progress toward code being the central
> discussion vehicle. As a community, we can then incrementally build on
> that foundation in order to collaboratively deliver the common vision.
> In the absence of any other home for posting such patches, let's
> assume that they will be attached to HADOOP-9392 - or a dedicated
> subtask for this particular aspect/s - I will leave that detail to Kai.
> @Alejandro, being the only voice on this thread that isn't represented
> in the votes above, please feel free to agree or disagree with this direction.
> thanks,
> --larry
> On Jul 5, 2013, at 3:24 PM, Larry McCay <[EMAIL PROTECTED]> wrote:
> > Hi Andy -
> >
> >> Happy Fourth of July to you and yours.
> >
> > Same to you and yours. :-)
> > We had some fun in the sun for a change - we've had nothing but rain
> > on
> the east coast lately.
> >
> >> My concern here is there may have been a misinterpretation or lack