[
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
