Mailing-List: contact common-issues-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: common-issues@hadoop.apache.org
Date: Wed, 1 May 2013 18:36:17 +0000 (UTC)
From: "Andrew Purtell (JIRA)" <jira@apache.org>
To: common-issues@hadoop.apache.org
Message-ID: <JIRA.12645641.1367423610946.255981.1367433377038@arcas>
In-Reply-To: <JIRA.12645641.1367423610946@arcas>
References: <JIRA.12645641.1367423610946@arcas>
Subject: [jira] [Commented] (HADOOP-9533) Hadoop SSO/Token Service
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


    [ https://issues.apache.org/jira/browse/HADOOP-9533?page=3Dcom.atlassia=
n.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D136=
46802#comment-13646802 ]=20

Andrew Purtell commented on HADOOP-9533:
----------------------------------------

Having a central master service for SSO is a design choice. HADOOP-9392 pro=
poses a pluggable design exactly because a central master service for SSO i=
s not a solution for all environments. This JIRA is a nice clearly defined =
subset of the work for HADOOP-9392, however. Isn't this work appropriately =
a subtask of HADOOP-9392? I think you are describing it as such, please cor=
rect me if I am mistaken. The title of this JIRA and that of HADOOP-9392 ar=
e almost exactly the same, and largely the goals for this JIRA are already =
captured under HADOOP-9392 i.e. token based authentication and SSO. We shou=
ld endeavor to resolve the duplication as shared community effort.
               =20
> Hadoop SSO/Token Service
> ------------------------
>
>                 Key: HADOOP-9533
>                 URL: https://issues.apache.org/jira/browse/HADOOP-9533
>             Project: Hadoop Common
>          Issue Type: New Feature
>          Components: security
>            Reporter: Larry McCay
>
> This is an umbrella Jira filing to oversee a set of proposals for introdu=
cing a new master service for Hadoop Single Sign On (HSSO).
> There is an increasing need for pluggable authentication providers that a=
uthenticate both users and services as well as validate tokens in order to =
federate identities authenticated by trusted IDPs. These IDPs may be deploy=
ed within the enterprise or third-party IDPs that are external to the enter=
prise.
> These needs speak to a specific pain point: which is a narrow integration=
 path into the enterprise identity infrastructure. Kerberos is a fine solut=
ion for those that already have it in place or are willing to adopt its use=
 but there remains a class of user that finds this unacceptable and needs t=
o integrate with a wider variety of identity management solutions.
> Another specific pain point is that of rolling and distributing keys. A r=
elated and integral part of the HSSO server is library called the Credentia=
l Management Framework (CMF), which will be a common library for easing the=
 management of secrets, keys and credentials.
> Initially, the existing delegation, block access and job tokens will cont=
inue to be utilized. There may be some changes required to leverage a PKI b=
ased signature facility rather than shared secrets. This is a means to simp=
lify the solution for the pain point of distributing shared secrets.
> This project will primarily centralize the responsibility of authenticati=
on and federation into a single service that is trusted across the Hadoop c=
luster and optionally across multiple clusters. This greatly simplifies a n=
umber of things in the Hadoop ecosystem:
> 1.=09a single token format that is used across all of Hadoop regardless o=
f authentication method
> 2.=09a single service to have pluggable providers instead of all services
> 3.=09a single token authority that would be trusted across the cluster/s =
and through PKI encryption be able to easily issue cryptographically verifi=
able tokens
> 4.=09automatic rolling of the token authority=E2=80=99s keys and publishi=
ng of the public key for easy access by those parties that need to verify i=
ncoming tokens
> 5.=09use of PKI for signatures eliminates the need for securely sharing a=
nd distributing shared secrets
> In addition to serving as the internal Hadoop SSO service this service wi=
ll be leveraged by the Knox Gateway from the cluster perimeter in order to =
acquire the Hadoop cluster tokens. The same token mechanism that is used fo=
r internal services will be used to represent user identities. Providing fo=
r interesting scenarios such as SSO across Hadoop clusters within an enterp=
rise and/or into the cloud.
> The HSSO service will be comprised of three major components and capabili=
ties:
> 1.=09Federating IDP =E2=80=93 authenticates users/services and issues the=
 common Hadoop token
> 2.=09Federating SP =E2=80=93 validates the token of trusted external IDPs=
 and issues the common Hadoop token
> 3.=09Token Authority =E2=80=93 management of the common Hadoop tokens =E2=
=80=93 including:=20
>     a.=09Issuance=20
>     b.=09Renewal
>     c.=09Revocation
> As this is a meta Jira for tracking this overall effort, the details of t=
he individual efforts will be submitted along with the child Jira filings.
> Hadoop-Common would seem to be the most appropriate home for such a servi=
ce and its related common facilities. We will also leverage and extend exis=
ting common mechanisms as appropriate.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrato=
rs
For more information on JIRA, see: http://www.atlassian.com/software/jira