hadoop-common-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kevin Minder (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HADOOP-9533) Centralized Hadoop SSO/Token Server
Date Thu, 20 Jun 2013 16:09:23 GMT

    [ https://issues.apache.org/jira/browse/HADOOP-9533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13689363#comment-13689363
] 

Kevin Minder commented on HADOOP-9533:
--------------------------------------

This is a summary of the discussion that occurred during the above meeting.  

-- Attendees --
Andrew Purtell, Brian Swan, Benoy Antong, Avik Dey, Kai Zheng, Kyle Leckie, LarryMcCay, Kevin
Minder, Tianyou Li

-- Goals & Perspective --

Hortonworks
* Plug into any enterprise Idp infrastructure
* Enhance Hadoop security model to better support perimeter security
* Align client programming model for different Hadoop deployment models

Microsoft
* Support pluggable identity providers: ActiveDirectory, cloud and beyond
* Enhance user isolation within Hadoop cluster

Intel
* Support token based authentication
* Support fine grained authorization
* Seamless identity delegation at every layer
* Support single sign on: from user's desktop, between Hadoop cluster
* Pluggable at every level
* Provide a security "toolkit" that would be integrated across the ecosystem
* Must be backward compatible
* Must take both RPC and HTTP into account and should follow common model

eBay
* Integrate better with eBay SSO
* Provide SSO integration at RPC layer

-- Summit Planning --

* Think of Summit session as a "meet and greet" and "Kickoff" of cross cutting security community
* Create a new Jira to collect high-level use cases, goals and usability
* Use time at summit to approach design at a whiteboard from a "clean slate" perspective against
those use cases and goals
* Get a sense of how we can divide and conqueror problem space
* Figure out how best to collaborate
* Figure out how we can all get "hacking" on this ASAP

-- Ideas --

* Foster a security community within the Hadoop community
  * Suggest creating a focused security-dev type community mailing list
  * Suggest creating a wiki area devoted to overall security efforts

* Ideally Current independent designs will inform a collaborative design, pull in best of
existing code to accelerate

* Link the security doc Jira HADOOP-9621 to other related security Jiras

-- Questions --

* What would central token authority (i.e. HSSO) provide beyond what the work that is already
being done?
HADOOP-9479 (Benoy Antony)
HADOOP-8779 (Daryn Sharp)

* How can HSSO and TAS work together?  What is the relationship? 
                
> Centralized Hadoop SSO/Token Server
> -----------------------------------
>
>                 Key: HADOOP-9533
>                 URL: https://issues.apache.org/jira/browse/HADOOP-9533
>             Project: Hadoop Common
>          Issue Type: New Feature
>          Components: security
>            Reporter: Larry McCay
>         Attachments: HSSO-Interaction-Overview-rev-1.docx, HSSO-Interaction-Overview-rev-1.pdf
>
>
> This is an umbrella Jira filing to oversee a set of proposals for introducing a new master
service for Hadoop Single Sign On (HSSO).
> There is an increasing need for pluggable authentication providers that authenticate
both users and services as well as validate tokens in order to federate identities authenticated
by trusted IDPs. These IDPs may be deployed within the enterprise or third-party IDPs that
are external to the enterprise.
> These needs speak to a specific pain point: which is a narrow integration path into the
enterprise identity infrastructure. Kerberos is a fine solution 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 to integrate with a wider variety of identity management solutions.
> Another specific pain point is that of rolling and distributing keys. A related and integral
part of the HSSO server is library called the Credential 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 continue to be utilized.
There may be some changes required to leverage a PKI based signature facility rather than
shared secrets. This is a means to simplify the solution for the pain point of distributing
shared secrets.
> This project will primarily centralize the responsibility of authentication and federation
into a single service that is trusted across the Hadoop cluster and optionally across multiple
clusters. This greatly simplifies a number of things in the Hadoop ecosystem:
> 1.	a single token format that is used across all of Hadoop regardless of authentication
method
> 2.	a single service to have pluggable providers instead of all services
> 3.	a single token authority that would be trusted across the cluster/s and through PKI
encryption be able to easily issue cryptographically verifiable tokens
> 4.	automatic rolling of the token authority’s keys and publishing of the public key
for easy access by those parties that need to verify incoming tokens
> 5.	use of PKI for signatures eliminates the need for securely sharing and distributing
shared secrets
> In addition to serving as the internal Hadoop SSO service this service will 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 for internal services will be used to represent user
identities. Providing for interesting scenarios such as SSO across Hadoop clusters within
an enterprise and/or into the cloud.
> The HSSO service will be comprised of three major components and capabilities:
> 1.	Federating IDP – authenticates users/services and issues the common Hadoop token
> 2.	Federating SP – validates the token of trusted external IDPs and issues the common
Hadoop token
> 3.	Token Authority – management of the common Hadoop tokens – including: 
>     a.	Issuance 
>     b.	Renewal
>     c.	Revocation
> As this is a meta Jira for tracking this overall effort, the details of the individual
efforts will be submitted along with the child Jira filings.
> Hadoop-Common would seem to be the most appropriate home for such a service and its related
common facilities. We will also leverage and extend existing common mechanisms as appropriate.

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

Mime
View raw message