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
The following JIRA was filed to provide a token and basic authority implementation for this effort:

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:
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.
> Project Scope
> The scope of this effort is a subset of the features covered by the overviews of HADOOP-9392 and HADOOP-9533. This effort concentrates on enabling Hadoop to issue, accept/validate SSO tokens of its own. The pluggable authentication mechanism within SASL/RPC layer and the authentication filter pluggability for REST and UI components will be leveraged and extended to support the results of this effort.
> Out of Scope
> In order to scope the initial deliverable as the minimally viable product, a handful of things have been simplified or left out of scope for this effort. This is not meant to say that these aspects are not useful or not needed but that they are not necessary for this iteration. We do however need to ensure that we don’t do anything to preclude adding them in future iterations.