FW: Hadoop Summit: Security Design Lounge Session

["Mattmann, Chris A (398J)" <ch...@jpl.nasa.gov>]

Fwd'ing to Knox list.

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: chris.a.mattmann@nasa.gov
WWW:  http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++






-----Original Message-----
From: Larry McCay <lm...@hortonworks.com>
Reply-To: "common-dev@hadoop.apache.org" <co...@hadoop.apache.org>
Date: Monday, July 1, 2013 2:40 PM
To: "common-dev@hadoop.apache.org" <co...@hadoop.apache.org>
Subject: Hadoop Summit: Security Design Lounge Session

>All -
>
>Last week at Hadoop Summit there was a room dedicated as the summit
>Design Lounge.
>This was a place where like folks could get together and talk about
>design issues with other contributors with a simple flip board and some
>beanbag chairs.
>We used this as an opportunity to bootstrap some discussions within
>common-dev for security related topics. I'd like to summarize the
>security session and takeaways here for everyone.
>
>This summary and set of takeaways are largely from memory.
>Please - anyone that attended - feel free to correct anything that is
>inaccurate or omitted.
>
>Pretty well attended - companies represented:
>* Yahoo!
>* Microsoft
>* Hortonworks
>* Cloudera
>* Intel
>* eBay
>* Voltage Security
>* Flying Penguins
>* EMC
>* others...
>
>Most folks were pretty engaged throughout the session.
>We set expectations as a meet and greet/project kickoff - project being
>the emerging security development community.
>
>In order to keep the scope of conversations manageable we tried to keep
>focused on authentication and the ideas around SSO and tokens.
>
>We discussed kerberos as:
>1. major pain point and barrier to entry for some
>2. seemingly perfect for others
>	a. obviously requiring backward compatibility
>
>It seemed to be consensus that:
>1. user authentication should be easily integrated with alternative
>enterprise identity solutions
>2. that service identity issues should not require thousands of service
>identities added to enterprise user repositories
>3. that customers should not be forced to install/deploy and manage a KDC
>for services - this implies a couple options:
>	a. alternatives to kerberos for service identities
>	b. hadoop KDC implementation - ie. ApacheDS?
>
>There was active discussion around:
>1. Hadoop SSO server
>	a. acknowledgement of Hadoop SSO tokens as something that can be
>standardized for representing both the identity and authentication event
>data as well and access tokens representing a verifiable means for the
>authenticated identity to access resources or services
>	b. a general understanding of Hadoop SSO as being an analogue and
>alternative for the kerberos KDC and the related tokens being analogous
>to TGTs and service tickets
>	c. an agreement that there are interesting attributes about the
>authentication event that may be useful in cross cluster trust for SSO -
>such as a rating of authentication strength and number of factors, etc
>	d. that existing Hadoop tokens - ie. delegation, job, block access -
>will all continue to work and that we are initially looking at
>alternatives to the KDC, TGTs and service tickets
>2. authentication mechanism discovery by clients - Daryn Sharp has done a
>bunch of work around this and our SSO solution may want to consider a
>similar mechanism for discovering trusted IDPs and service endpoints
>3. backward compatibility - kerberos shops need to just continue to work
>4. some insight into where/how folks believe that token based
>authentication can be accomplished within existing contracts -
>SASL/GSSAPI, REST, web ui
>5. what the establishment of a cross cutting concern community around
>security and what that means in terms of the Apache way - email lists,
>wiki, Jiras across projects, etc
>6. dependencies, rolling updates, patching and how it related to hadoop
>projects versus packaging
>7. collaboration road ahead
>
>A number of breakout discussions were had outside of the designated
>design lounge session as well.
>
>Takeaways for the immediate road ahead:
>1. common-dev may be sufficient to discuss security related topics
>	a. many developers are already subscribed to it
>	b. there is not that much traffic there anyway
>	c. we can discuss a more security focused list if we like
>2. we will discuss the establishment of a wiki space for a holistic view
>of security model, patterns, approaches, etc
>3. we will begin discussion on common-dev in near-term for the following:
>	a. discuss and agree on the high level moving parts required for our
>goals for authentication: SSO service, tokens, token validation handlers,
>credential management tools, etc
>	b. discuss and agree on the natural seams across these moving parts and
>agree on collaboration by tackling various pieces in a divide and conquer
>approach
>	c. more than likely - the first piece that will need some immediate
>discussion will be the shape and form of the tokens
>	d. we will follow up or supplement discussions with POC code patches
>and/or specs attached to jiras
>
>Overall, design lounge was rather effective for what we wanted to do -
>which was to bootstrap discussions and collaboration within the community
>at large. As always, no specific decisions have been made during this
>session and we can discuss any or all of this within common-dev and on
>related jiras.
>
>Jiras related to the security development group and these discussions:
>
>Centralized SSO/Token Server
>https://issues.apache.org/jira/browse/HADOOP-9533
>Token based authentication and SSO
>https://issues.apache.org/jira/browse/HADOOP-9392
>Document/analyze current Hadoop security model
>https://issues.apache.org/jira/browse/HADOOP-9621
>Improve Hadoop security - Use cases
>https://issues.apache.org/jira/browse/HADOOP-9671
>
>thanks,
>
>--larry
>