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
Alejandro Abdelnur 2013-08-06, 20:04
Larry,

Sorry for the delay answering. Thanks for laying down things, yes, it makes
sense.

Given the large scope of the changes, number of JIRAs and number of
developers involved, wouldn't make sense to create a feature branch for all
this work not to destabilize (more ;) trunk?

Thanks again.
On Tue, Jul 30, 2013 at 9:43 AM, Larry McCay <[EMAIL PROTECTED]> wrote:

> The following JIRA was filed to provide a token and basic authority
> implementation for this effort:
> https://issues.apache.org/jira/browse/HADOOP-9781
>
> I have attached an initial patch though have yet to submit it as one since
> it is dependent on the patch for CMF that was posted to:
> https://issues.apache.org/jira/browse/HADOOP-9534
> and this patch still has a couple outstanding issues - javac warnings for
> com.sun classes for certification generation and 11 javadoc warnings.
>
> Please feel free to review the patches and raise any questions or concerns
> related to them.
>
> On Jul 26, 2013, at 8:59 PM, Larry McCay <[EMAIL PROTECTED]> wrote:
>
> > Hello All -
> >
> > In an effort to scope an initial iteration that provides value to the
> community while focusing on the pluggable authentication aspects, I've
> written a description for "Iteration 1". It identifies the goal of the
> iteration, the endstate and a set of initial usecases. It also enumerates
> the components that are required for each usecase. There is a scope section
> that details specific things that should be kept out of the first
> iteration. This is certainly up for discussion. There may be some of these
> things that can be contributed in short order. If we can add some things in
> without unnecessary complexity for the identified usecases then we should.
> >
> > @Alejandro - please review this and see whether it satisfies your point
> for a definition of what we are building.
> >
> > In addition to the document that I will paste here as text and attach a
> pdf version, we have a couple patches for components that are identified in
> the document.
> > Specifically, COMP-7 and COMP-8.
> >
> > I will be posting COMP-8 patch to the HADOOP-9534 JIRA which was filed
> specifically for that functionality.
> > COMP-7 is a small set of classes to introduce JsonWebToken as the token
> format and a basic JsonWebTokenAuthority that can issue and verify these
> tokens.
> >
> > Since there is no JIRA for this yet, I will likely file a new JIRA for a
> SSO token implementation.
> >
> > Both of these patches assume to be modules within
> hadoop-common/hadoop-common-project.
> > While they are relatively small, I think that they will be pulled in by
> other modules such as hadoop-auth which would likely not want a dependency
> on something larger like hadoop-common/hadoop-common-project/hadoop-common.
> >
> > This is certainly something that we should discuss within the community
> for this effort though - that being, exactly how to add these libraries so
> that they are most easily consumed by existing projects.
> >
> > Anyway, the following is the Iteration-1 document - it is also attached
> as a pdf:
> >
> > Iteration 1: Pluggable User Authentication and Federation
> >
> > Introduction
> > The intent of this effort is to bootstrap the development of pluggable
> token-based authentication mechanisms to support certain goals of
> enterprise authentication integrations. By restricting the scope of this
> effort, we hope to provide immediate benefit to the community while keeping
> the initial contribution to a manageable size that can be easily reviewed,
> understood and extended with further development through follow up JIRAs
> and related iterations.
> >
> > Iteration Endstate
> > Once complete, this effort will have extended the authentication
> mechanisms - for all client types - from the existing: Simple, Kerberos and
> Plain (for RPC) to include LDAP authentication and SAML based federation.
> In addition, the ability to provide additional/custom authentication
> mechanisms will be enabled for users to plug in their preferred mechanisms.
Alejandro