Chris - I am curious whether there are any guidelines for feature branch use.
The general goals should be to: * keep branches as small and as easily reviewable as possible for a given feature * decouple the pluggable framework from any specific central server implementation * scope specific content into iterations that can be merged into trunk on their own and then development continued in new branches for the next iteration So, I guess the questions that immediately come to mind are: 1. Is there a document that describes the best way to do this? 2. How best do we leverage code being done in one feature branch within another? Thanks! --larry On Tue, Sep 3, 2013 at 10:00 PM, Zheng, Kai <kai.zh...@intel.com> wrote: > This looks good and reasonable to me. Thanks Chris. > > -----Original Message----- > From: Chris Douglas [mailto:cdoug...@apache.org] > Sent: Wednesday, September 04, 2013 6:45 AM > To: common-dev@hadoop.apache.org > Subject: Re: [DISCUSS] Hadoop SSO/Token Server Components > > On Tue, Sep 3, 2013 at 5:20 AM, Larry McCay <lmc...@hortonworks.com> > wrote: > > One outstanding question for me - how do we go about getting the > > branches created? > > Once a group has converged on a purpose- ideally with some initial code > from JIRA- please go ahead and create the feature branch in svn. > There's no ceremony. -C > > > On Tue, Aug 6, 2013 at 6:22 PM, Chris Nauroth <cnaur...@hortonworks.com > >wrote: > > > >> Near the bottom of the bylaws, it states that addition of a "New > >> Branch Committer" requires "Lazy consensus of active PMC members." I > >> think this means that you'll need to get a PMC member to sponsor the > vote for you. > >> Regular committer votes happen on the private PMC mailing list, and > >> I assume it would be the same for a branch committer vote. > >> > >> http://hadoop.apache.org/bylaws.html > >> > >> Chris Nauroth > >> Hortonworks > >> http://hortonworks.com/ > >> > >> > >> > >> On Tue, Aug 6, 2013 at 2:48 PM, Larry McCay <lmc...@hortonworks.com> > >> wrote: > >> > >> > That sounds perfect! > >> > I have been thinking of late that we would maybe need an incubator > >> project > >> > or something for this - which would be unfortunate. > >> > > >> > This would allow us to move much more quickly with a set of patches > >> broken > >> > up into consumable/understandable chunks that are made functional > >> > more easily within the branch. > >> > I assume that we need to start a separate thread for DISCUSS or > >> > VOTE to start that process - correct? > >> > > >> > On Aug 6, 2013, at 4:15 PM, Alejandro Abdelnur <t...@cloudera.com> > >> wrote: > >> > > >> > > yep, that is what I meant. Thanks Chris > >> > > > >> > > > >> > > On Tue, Aug 6, 2013 at 1:12 PM, Chris Nauroth < > >> cnaur...@hortonworks.com > >> > >wrote: > >> > > > >> > >> Perhaps this is also a good opportunity to try out the new > >> > >> "branch committers" clause in the bylaws, enabling > >> > >> non-committers who are > >> > working > >> > >> on this to commit to the feature branch. > >> > >> > >> > >> > >> > >> > >> > > >> http://mail-archives.apache.org/mod_mbox/hadoop-general/201308.mbox/% > >> 3CCACO5Y4we4d8knB_xU3a=hr2gbeqo5m3vau+inba0li1i9e2...@mail.gmail.com% > >> 3E > >> > >> > >> > >> Chris Nauroth > >> > >> Hortonworks > >> > >> http://hortonworks.com/ > >> > >> > >> > >> > >> > >> > >> > >> On Tue, Aug 6, 2013 at 1:04 PM, Alejandro Abdelnur > >> > >> <t...@cloudera.com > >> > >>> wrote: > >> > >> > >> > >>> Larry, > >> > >>> > >> > >>> Sorry for the delay answering. Thanks for laying down things, > >> > >>> yes, it > >> > >> makes > >> > >>> sense. > >> > >>> > >> > >>> Given the large scope of the changes, number of JIRAs and > >> > >>> number of developers involved, wouldn't make sense to create a > >> > >>> feature branch > >> for > >> > >> all > >> > >>> this work not to destabilize (more ;) trunk? > >> > >>> > >> > >>> Thanks again. > >> > >>> > >> > >>> > >> > >>> On Tue, Jul 30, 2013 at 9:43 AM, Larry McCay > >> > >>> <lmc...@hortonworks.com > >> > > >> > >>> wrote: > >> > >>> > >> > >>>> The following JIRA was filed to provide a token and basic > >> > >>>> authority implementation for this effort: > >> > >>>> https://issues.apache.org/jira/browse/HADOOP-9781 > >> > >>>> > >> > >>>> 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: > >> > >>>> https://issues.apache.org/jira/browse/HADOOP-9534 > >> > >>>> 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 > >> > >>>> <lmc...@hortonworks.com> > >> > >> 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. > >> > >>>>> 1. Additional Attributes - the result of authentication will > >> continue > >> > >>> to > >> > >>>> use the existing hadoop tokens and identity representations. > >> > Additional > >> > >>>> attributes used for finer grained authorization decisions will > >> > >>>> be > >> > added > >> > >>>> through follow-up efforts. > >> > >>>>> 2. Token revocation - the ability to revoke issued identity > >> > >>>>> tokens > >> > >> will > >> > >>>> be added later > >> > >>>>> 3. Multi-factor authentication - this will likely require > >> additional > >> > >>>> attributes and is not necessary for this iteration. > >> > >>>>> 4. Authorization changes - we will require additional > >> > >>>>> attributes > >> for > >> > >>> the > >> > >>>> fine-grained access control plans. This is not needed for this > >> > >> iteration. > >> > >>>>> 5. Domains - we assume a single flat domain for all users 6. > >> > >>>>> Kinit alternative - we can leverage existing REST clients > >> > >>>>> such > >> as > >> > >>>> cURL to retrieve tokens through authentication and federation > >> > >>>> for > >> the > >> > >>> time > >> > >>>> being > >> > >>>>> 7. A specific authentication framework isn't really necessary > >> within > >> > >>> the > >> > >>>> REST endpoints for this iteration. If one is available then we > >> > >>>> can > >> use > >> > >> it > >> > >>>> otherwise we can leverage existing things like Apache Shiro > >> > >>>> within a servlet filter. > >> > >>>>> > >> > >>>>> In Scope > >> > >>>>> What is in scope for this effort is defined by the usecases > >> described > >> > >>>> below. Components required for supporting the usecases are > >> summarized > >> > >> for > >> > >>>> each client type. Each component is a candidate for a JIRA > >> > >>>> subtask - > >> > >>> though > >> > >>>> multiple components are likely to be included in a JIRA to > >> represent a > >> > >>> set > >> > >>>> of functionality rather than individual JIRAs per component. > >> > >>>>> > >> > >>>>> Terminology and Naming > >> > >>>>> The terms and names of components within this document are > >> > >>>>> merely > >> > >>>> descriptive of the functionality that they represent. Any > >> > >>>> similarity > >> > or > >> > >>>> difference in names or terms from those that are found in > >> > >>>> other > >> > >> documents > >> > >>>> are not intended to make any statement about those other > >> > >>>> documents > >> or > >> > >> the > >> > >>>> descriptions within. This document represents the pluggable > >> > >>> authentication > >> > >>>> mechanisms and server functionality required to replace Kerberos. > >> > >>>>> > >> > >>>>> Ultimately, the naming of the implementation classes will be > >> > >>>>> a > >> > >> product > >> > >>>> of the patches accepted by the community. > >> > >>>>> > >> > >>>>> Usecases: > >> > >>>>> client types: REST, CLI, UI > >> > >>>>> authentication types: Simple, Kerberos, authentication/LDAP, > >> > >>>> federation/SAML > >> > >>>>> > >> > >>>>> Simple and Kerberos > >> > >>>>> Simple and Kerberos usecases continue to work as they do > >> > >>>>> today. The > >> > >>>> addition of Authentication/LDAP and Federation/SAML are added > >> through > >> > >> the > >> > >>>> existing pluggability points either as they are or with > >> > >>>> required > >> > >>> extension. > >> > >>>> Either way, continued support for Simple and Kerberos must not > >> require > >> > >>>> changes to existing deployments in the field as a result of > >> > >>>> this > >> > >> effort. > >> > >>>>> > >> > >>>>> REST > >> > >>>>> USECASE REST-1 Authentication/LDAP: > >> > >>>>> For REST clients, we will provide the ability to: > >> > >>>>> 1. use cURL to Authenticate via LDAP through an IdP endpoint > >> exposed > >> > >> by > >> > >>>> an AuthenticationServer instance via REST calls to: > >> > >>>>> a. authenticate - passing username/password returning a > >> > >>>>> hadoop > >> > >>>> id_token > >> > >>>>> b. get-access-token - from the TokenGrantingService by > >> > >>>>> passing > >> the > >> > >>>> hadoop id_token as an Authorization: Bearer token along with > >> > >>>> the > >> > >> desired > >> > >>>> service name (master service name) returning a hadoop access > >> > >>>> token > >> > >>>>> 2. Successfully invoke a hadoop service REST API passing the > >> > >>>>> hadoop > >> > >>>> access token through an HTTP header as an Authorization Bearer > >> > >>>> token > >> > >>>>> a. validation of the incoming token on the service endpoint > >> > >>>>> is > >> > >>>> accomplished by an SSOAuthenticationHandler > >> > >>>>> 3. Successfully block access to a REST resource when > >> > >>>>> presenting a > >> > >>> hadoop > >> > >>>> access token intended for a different service > >> > >>>>> a. validation of the incoming token on the service endpoint > >> > >>>>> is > >> > >>>> accomplished by an SSOAuthenticationHandler > >> > >>>>> > >> > >>>>> USECASE REST-2 Federation/SAML: > >> > >>>>> We will also provide federation capabilities for REST clients > >> > >>>>> such > >> > >>> that: > >> > >>>>> 1. acquire SAML assertion token from a trusted IdP > >> > >>>>> (shibboleth?) > >> and > >> > >>>> persist in a permissions protected file - ie. > >> > >> ~/.hadoop_tokens/.idp_token > >> > >>>>> 2. use cURL to Federate a token from a trusted IdP through an > >> > >>>>> SP > >> > >>>> endpoint exposed by an AuthenticationServer(FederationServer?) > >> > instance > >> > >>> via > >> > >>>> REST calls to: > >> > >>>>> a. federate - passing a SAML assertion as an Authorization: > >> Bearer > >> > >>>> token returning a hadoop id_token > >> > >>>>> - can copy and paste from commandline or use cat to > >> > >>>>> include > >> > >>>> persisted token through "--Header Authorization: Bearer 'cat > >> > >>>> ~/.hadoop_tokens/.id_token'" > >> > >>>>> b. get-access-token - from the TokenGrantingService by > >> > >>>>> passing > >> the > >> > >>>> hadoop id_token as an Authorization: Bearer token along with > >> > >>>> the > >> > >> desired > >> > >>>> service name (master service name) to the TokenGrantingService > >> > >> returning > >> > >>> a > >> > >>>> hadoop access token > >> > >>>>> 3. Successfully invoke a hadoop service REST API passing the > >> > >>>>> hadoop > >> > >>>> access token through an HTTP header as an Authorization Bearer > >> > >>>> token > >> > >>>>> a. validation of the incoming token on the service endpoint > >> > >>>>> is > >> > >>>> accomplished by an SSOAuthenticationHandler > >> > >>>>> 4. Successfully block access to a REST resource when > >> > >>>>> presenting a > >> > >>> hadoop > >> > >>>> access token intended for a different service > >> > >>>>> a. validation of the incoming token on the service endpoint > >> > >>>>> is > >> > >>>> accomplished by an SSOAuthenticationHandler > >> > >>>>> > >> > >>>>> REQUIRED COMPONENTS for REST USECASES: > >> > >>>>> COMP-1. REST client - cURL or similar COMP-2. REST endpoint > >> > >>>>> for BASIC authentication to LDAP - IdP > >> endpoint > >> > >>>> example - returning hadoop id_token > >> > >>>>> COMP-3. REST endpoint for federation with SAML Bearer token - > >> > >>> shibboleth > >> > >>>> SP?|OpenSAML? - returning hadoop id_token > >> > >>>>> COMP-4. REST TokenGrantingServer endpoint for acquiring > >> > >>>>> hadoop > >> access > >> > >>>> tokens from hadoop id_tokens > >> > >>>>> COMP-5. SSOAuthenticationHandler to validate incoming hadoop > >> > >>>>> access > >> > >>>> tokens > >> > >>>>> COMP-6. some source of a SAML assertion - shibboleth IdP? > >> > >>>>> COMP-7. hadoop token and authority implementations COMP-8. > >> > >>>>> core services for crypto support for signing, verifying and > >> > >> PKI > >> > >>>> management > >> > >>>>> > >> > >>>>> CLI > >> > >>>>> USECASE CLI-1 Authentication/LDAP: > >> > >>>>> For CLI/RPC clients, we will provide the ability to: > >> > >>>>> 1. use cURL to Authenticate via LDAP through an IdP endpoint > >> exposed > >> > >> by > >> > >>>> an AuthenticationServer instance via REST calls to: > >> > >>>>> a. authenticate - passing username/password returning a > >> > >>>>> hadoop > >> > >>>> id_token > >> > >>>>> - for RPC clients we need to persist the returned hadoop > >> > >> identity > >> > >>>> token in a file protected by fs permissions so that it may be > >> > leveraged > >> > >>>> until expiry > >> > >>>>> - directing the returned response to a file may suffice > >> > >>>>> for > >> now > >> > >>>> something like ">~/.hadoop_tokens/.id_token" > >> > >>>>> 2. use hadoop CLI to invoke RPC API on a specific hadoop service > >> > >>>>> a. RPC client negotiates a TokenAuth method through SASL > >> > >>>>> layer, > >> > >>>> hadoop id_token is retrieved from ~/.hadoop_tokens/.id_token > >> > >>>> is > >> passed > >> > >> as > >> > >>>> Authorization: Bearer token to the get-access-token REST > >> > >>>> endpoint > >> > >> exposed > >> > >>>> by TokenGrantingService returning a hadoop access token > >> > >>>>> b. RPC server side validates the presented hadoop access > >> > >>>>> token > >> and > >> > >>>> continues to serve request > >> > >>>>> c. Successfully invoke a hadoop service RPC API > >> > >>>>> > >> > >>>>> USECASE CLI-2 Federation/SAML: > >> > >>>>> For CLI/RPC clients, we will provide the ability to: > >> > >>>>> 1. acquire SAML assertion token from a trusted IdP > >> > >>>>> (shibboleth?) > >> and > >> > >>>> persist in a permissions protected file - ie. > >> > >> ~/.hadoop_tokens/.idp_token > >> > >>>>> 2. use cURL to Federate a token from a trusted IdP through an > >> > >>>>> SP > >> > >>>> endpoint exposed by an AuthenticationServer(FederationServer?) > >> > instance > >> > >>> via > >> > >>>> REST calls to: > >> > >>>>> a. federate - passing a SAML assertion as an Authorization: > >> Bearer > >> > >>>> token returning a hadoop id_token > >> > >>>>> - can copy and paste from commandline or use cat to > >> > >>>>> include > >> > >>>> previously persisted token through "--Header Authorization: > >> > >>>> Bearer > >> > 'cat > >> > >>>> ~/.hadoop_tokens/.id_token'" > >> > >>>>> 3. use hadoop CLI to invoke RPC API on a specific hadoop service > >> > >>>>> a. RPC client negotiates a TokenAuth method through SASL > >> > >>>>> layer, > >> > >>>> hadoop id_token is retrieved from ~/.hadoop_tokens/.id_token > >> > >>>> is > >> passed > >> > >> as > >> > >>>> Authorization: Bearer token to the get-access-token REST > >> > >>>> endpoint > >> > >> exposed > >> > >>>> by TokenGrantingService returning a hadoop access token > >> > >>>>> b. RPC server side validates the presented hadoop access > >> > >>>>> token > >> and > >> > >>>> continues to serve request > >> > >>>>> c. Successfully invoke a hadoop service RPC API > >> > >>>>> > >> > >>>>> REQUIRED COMPONENTS for CLI USECASES - (beyond those required > >> > >>>>> for > >> > >>> REST): > >> > >>>>> COMP-9. TokenAuth Method negotiation, etc COMP-10. Client > >> > >>>>> side implementation to leverage REST endpoint for > >> > >>>> acquiring hadoop access tokens given a hadoop id_token > >> > >>>>> COMP-11. Server side implementation to validate incoming > >> > >>>>> hadoop > >> > >> access > >> > >>>> tokens > >> > >>>>> > >> > >>>>> UI > >> > >>>>> Various Hadoop services have their own web UI consoles for > >> > >>>> administration and end user interactions. These consoles need > >> > >>>> to > >> also > >> > >>>> benefit from the pluggability of authentication mechansims to > >> > >>>> be on > >> > par > >> > >>>> with the access control of the cluster REST and RPC APIs. > >> > >>>>> Web consoles are protected with an > >> > >>>>> WebSSOAuthenticationHandler > >> which > >> > >>>> will be configured for either authentication or federation. > >> > >>>>> > >> > >>>>> USECASE UI-1 Authentication/LDAP: > >> > >>>>> For the authentication usecase: > >> > >>>>> 1. User's browser requests access to a UI console page 2. > >> > >>>>> WebSSOAuthenticationHandler intercepts the request and > >> > >>>>> redirects > >> > >> the > >> > >>>> browser to an IdP web endpoint exposed by the > >> > >>>> AuthenticationServer > >> > >>> passing > >> > >>>> the requested url as the redirect_url > >> > >>>>> 3. IdP web endpoint presents the user with a FORM over https > >> > >>>>> a. user provides username/password and submits the FORM 4. > >> > >>>>> AuthenticationServer authenticates the user with provided > >> > >>> credentials > >> > >>>> against the configured LDAP server and: > >> > >>>>> a. leverages a servlet filter or other authentication > >> > >>>>> mechanism > >> > >> for > >> > >>>> the endpoint and authenticates the user with a simple LDAP > >> > >>>> bind with username and password > >> > >>>>> b. acquires a hadoop id_token and uses it to acquire the > >> > >>>>> required > >> > >>>> hadoop access token which is added as a cookie > >> > >>>>> c. redirects the browser to the original service UI > >> > >>>>> resource via > >> > >> the > >> > >>>> provided redirect_url > >> > >>>>> 5. WebSSOAuthenticationHandler for the original UI resource > >> > >>> interrogates > >> > >>>> the incoming request again for an authcookie that contains an > >> > >>>> access > >> > >>> token > >> > >>>> upon finding one: > >> > >>>>> a. validates the incoming token > >> > >>>>> b. returns the AuthenticationToken as per > >> > >>>>> AuthenticationHandler > >> > >>>> contract > >> > >>>>> c. AuthenticationFilter adds the hadoop auth cookie with > >> > >>>>> the > >> > >>> expected > >> > >>>> token > >> > >>>>> d. serves requested resource for valid tokens > >> > >>>>> e. subsequent requests are handled by the > >> > >>>>> AuthenticationFilter > >> > >>>> recognition of the hadoop auth cookie > >> > >>>>> > >> > >>>>> USECASE UI-2 Federation/SAML: > >> > >>>>> For the federation usecase: > >> > >>>>> 1. User's browser requests access to a UI console page 2. > >> > >>>>> WebSSOAuthenticationHandler intercepts the request and > >> > >>>>> redirects > >> > >> the > >> > >>>> browser to an SP web endpoint exposed by the > >> > >>>> AuthenticationServer > >> > >> passing > >> > >>>> the requested url as the redirect_url. This endpoint: > >> > >>>>> a. is dedicated to redirecting to the external IdP passing > >> > >>>>> the > >> > >>>> required parameters which may include a redirect_url back to > >> > >>>> itself > >> as > >> > >>> well > >> > >>>> as encoding the original redirect_url so that it can determine > >> > >>>> it on > >> > >> the > >> > >>>> way back to the client > >> > >>>>> 3. the IdP: > >> > >>>>> a. challenges the user for credentials and authenticates the > user > >> > >>>>> b. creates appropriate token/cookie and redirects back to > >> > >>>>> the > >> > >>>> AuthenticationServer endpoint > >> > >>>>> 4. AuthenticationServer endpoint: > >> > >>>>> a. extracts the expected token/cookie from the incoming > >> > >>>>> request > >> > >> and > >> > >>>> validates it > >> > >>>>> b. creates a hadoop id_token > >> > >>>>> c. acquires a hadoop access token for the id_token > >> > >>>>> d. creates appropriate cookie and redirects back to the > >> > >>>>> original > >> > >>>> redirect_url - being the requested resource > >> > >>>>> 5. WebSSOAuthenticationHandler for the original UI resource > >> > >>> interrogates > >> > >>>> the incoming request again for an authcookie that contains an > >> > >>>> access > >> > >>> token > >> > >>>> upon finding one: > >> > >>>>> a. validates the incoming token > >> > >>>>> b. returns the AuthenticationToken as per > >> > >>>>> AuthenticationHandler > >> > >>>> contrac > >> > >>>>> c. AuthenticationFilter adds the hadoop auth cookie with > >> > >>>>> the > >> > >>> expected > >> > >>>> token > >> > >>>>> d. serves requested resource for valid tokens > >> > >>>>> e. subsequent requests are handled by the > >> > >>>>> AuthenticationFilter > >> > >>>> recognition of the hadoop auth cookie > >> > >>>>> REQUIRED COMPONENTS for UI USECASES: > >> > >>>>> COMP-12. WebSSOAuthenticationHandler COMP-13. IdP Web > >> > >>>>> Endpoint within AuthenticationServer for FORM > >> based > >> > >>>> login > >> > >>>>> COMP-14. SP Web Endpoint within AuthenticationServer for 3rd > >> > >>>>> party > >> > >>> token > >> > >>>> federation > >> > >>>>> > >> > >>>>> > >> > >>>>> > >> > >>>>> On Wed, Jul 10, 2013 at 1:59 PM, Brian Swan < > >> > >> brian.s...@microsoft.com> > >> > >>>> wrote: > >> > >>>>> Thanks, Larry. That is what I was trying to say, but you've > >> > >>>>> said it > >> > >>>> better and in more detail. :-) To extract from what you are > saying: > >> > "If > >> > >>> we > >> > >>>> were to reframe the immediate scope to the lowest common > >> > >>>> denominator > >> > of > >> > >>>> what is needed for accepting tokens in authentication plugins > >> > >>>> then > >> we > >> > >>>> gain... an end-state for the lowest common denominator that > >> > >>>> enables > >> > >> code > >> > >>>> patches in the near-term is the best of both worlds." > >> > >>>>> > >> > >>>>> -Brian > >> > >>>>> > >> > >>>>> -----Original Message----- > >> > >>>>> From: Larry McCay [mailto:lmc...@hortonworks.com] > >> > >>>>> Sent: Wednesday, July 10, 2013 10:40 AM > >> > >>>>> To: common-dev@hadoop.apache.org > >> > >>>>> Cc: da...@yahoo-inc.com; Kai Zheng; Alejandro Abdelnur > >> > >>>>> Subject: Re: [DISCUSS] Hadoop SSO/Token Server Components > >> > >>>>> > >> > >>>>> It seems to me that we can have the best of both worlds > >> > >>>>> here...it's > >> > >> all > >> > >>>> about the scoping. > >> > >>>>> > >> > >>>>> If we were to reframe the immediate scope to the lowest > >> > >>>>> common > >> > >>>> denominator of what is needed for accepting tokens in > >> > >>>> authentication plugins then we gain: > >> > >>>>> > >> > >>>>> 1. a very manageable scope to define and agree upon 2. a > >> deliverable > >> > >>>> that should be useful in and of itself 3. a foundation for > >> > >>>> community collaboration that we build on for higher level > >> > >>>> solutions built on > >> > this > >> > >>>> lowest common denominator and experience as a working > >> > >>>> community > >> > >>>>> > >> > >>>>> So, to Alejandro's point, perhaps we need to define what > >> > >>>>> would make > >> > >> #2 > >> > >>>> above true - this could serve as the "what" we are building > >> > >>>> instead > >> of > >> > >>> the > >> > >>>> "how" to build it. > >> > >>>>> Including: > >> > >>>>> a. project structure within > >> > >>>>> hadoop-common-project/common-security > >> or > >> > >>> the > >> > >>>> like b. the usecases that would need to be enabled to make it > >> > >>>> a self contained and useful contribution - without higher > >> > >>>> level solutions > >> c. > >> > >> the > >> > >>>> JIRA/s for contributing patches d. what specific patches will > >> > >>>> be > >> > needed > >> > >>> to > >> > >>>> accomplished the usecases in #b > >> > >>>>> > >> > >>>>> In other words, an end-state for the lowest common > >> > >>>>> denominator that > >> > >>>> enables code patches in the near-term is the best of both worlds. > >> > >>>>> > >> > >>>>> I think this may be a good way to bootstrap the collaboration > >> process > >> > >>>> for our emerging security community rather than trying to > >> > >>>> tackle a > >> > huge > >> > >>>> vision all at once. > >> > >>>>> > >> > >>>>> @Alejandro - if you have something else in mind that would > >> bootstrap > >> > >>>> this process - that would great - please advise. > >> > >>>>> > >> > >>>>> thoughts? > >> > >>>>> > >> > >>>>> On Jul 10, 2013, at 1:06 PM, Brian Swan > >> > >>>>> <brian.s...@microsoft.com> > >> > >>>> wrote: > >> > >>>>> > >> > >>>>>> Hi Alejandro, all- > >> > >>>>>> > >> > >>>>>> There seems to be agreement on the broad stroke description > >> > >>>>>> of the > >> > >>>> components needed to achieve pluggable token authentication > >> > >>>> (I'm > >> sure > >> > >>> I'll > >> > >>>> be corrected if that isn't the case). However, discussion of > >> > >>>> the > >> > >> details > >> > >>> of > >> > >>>> those components doesn't seem to be moving forward. I think > >> > >>>> this is > >> > >>> because > >> > >>>> the details are really best understood through code. I also > >> > >>>> see *a* > >> > >> (i.e. > >> > >>>> one of many possible) token format and pluggable > >> > >>>> authentication > >> > >>> mechanisms > >> > >>>> within the RPC layer as components that can have immediate > >> > >>>> benefit > >> to > >> > >>>> Hadoop users AND still allow flexibility in the larger design. > >> > >>>> So, I > >> > >>> think > >> > >>>> the best way to move the conversation of "what we are aiming for" > >> > >> forward > >> > >>>> is to start looking at code for these components. I am > >> > >>>> especially interested in moving forward with pluggable > >> > >>>> authentication > >> mechanisms > >> > >>>> within the RPC layer and would love to see what others have > >> > >>>> done in > >> > >> this > >> > >>>> area (if anything). > >> > >>>>>> > >> > >>>>>> Thanks. > >> > >>>>>> > >> > >>>>>> -Brian > >> > >>>>>> > >> > >>>>>> -----Original Message----- > >> > >>>>>> From: Alejandro Abdelnur [mailto:t...@cloudera.com] > >> > >>>>>> Sent: Wednesday, July 10, 2013 8:15 AM > >> > >>>>>> To: Larry McCay > >> > >>>>>> Cc: common-dev@hadoop.apache.org; da...@yahoo-inc.com; Kai > >> > >>>>>> Zheng > >> > >>>>>> Subject: Re: [DISCUSS] Hadoop SSO/Token Server Components > >> > >>>>>> > >> > >>>>>> Larry, all, > >> > >>>>>> > >> > >>>>>> Still is not clear to me what is the end state we are aiming > >> > >>>>>> for, > >> > >> or > >> > >>>> that we even agree on that. > >> > >>>>>> > >> > >>>>>> IMO, Instead trying to agree what to do, we should first > >> > >>>>>> agree on > >> > >>> the > >> > >>>> final state, then we see what should be changed to there > >> > >>>> there, then > >> > we > >> > >>> see > >> > >>>> how we change things to get there. > >> > >>>>>> > >> > >>>>>> The different documents out there focus more on how. > >> > >>>>>> > >> > >>>>>> We not try to say how before we know what. > >> > >>>>>> > >> > >>>>>> Thx. > >> > >>>>>> > >> > >>>>>> > >> > >>>>>> > >> > >>>>>> > >> > >>>>>> On Wed, Jul 10, 2013 at 6:42 AM, Larry McCay < > >> > >> lmc...@hortonworks.com > >> > >>>> > >> > >>>> wrote: > >> > >>>>>> > >> > >>>>>>> All - > >> > >>>>>>> > >> > >>>>>>> After combing through this thread - as well as the summit > >> > >>>>>>> session summary thread, I think that we have the following > >> > >>>>>>> two items that > >> > >> we > >> > >>>>>>> can probably move forward with: > >> > >>>>>>> > >> > >>>>>>> 1. TokenAuth method - assuming this means the pluggable > >> > >>>>>>> authentication mechanisms within the RPC layer (2 votes: > >> > >>>>>>> Kai and > >> > >>>>>>> Kyle) 2. An actual Hadoop Token format (2 votes: Brian and > >> myself) > >> > >>>>>>> > >> > >>>>>>> I propose that we attack both of these aspects as one. > >> > >>>>>>> Let's > >> > >> provide > >> > >>>>>>> the structure and interfaces of the pluggable framework for > >> > >>>>>>> use > >> in > >> > >>>>>>> the RPC layer through leveraging Daryn's pluggability work > >> > >>>>>>> and > >> POC > >> > >>> it > >> > >>>>>>> with a particular token format (not necessarily the only > >> > >>>>>>> format > >> > >> ever > >> > >>>>>>> supported - we just need one to start). If there has > >> > >>>>>>> already been work done in this area by anyone then please > >> > >>>>>>> speak up and commit > >> > >> to > >> > >>>>>>> providing a patch - so that we don't duplicate effort. > >> > >>>>>>> > >> > >>>>>>> @Daryn - is there a particular Jira or set of Jiras that we > >> > >>>>>>> can > >> > >> look > >> > >>>>>>> at to discern the pluggability mechanism details? > >> > >>>>>>> Documentation > >> of > >> > >>> it > >> > >>>>>>> would be great as well. > >> > >>>>>>> @Kai - do you have existing code for the pluggable token > >> > >>>>>>> authentication mechanism - if not, we can take a stab at > >> > >>> representing > >> > >>>>>>> it with interfaces and/or POC code. > >> > >>>>>>> I can standup and say that we have a token format that we > >> > >>>>>>> have > >> > >> been > >> > >>>>>>> working with already and can provide a patch that > >> > >>>>>>> represents it > >> > >> as a > >> > >>>>>>> contribution to test out the pluggable tokenAuth. > >> > >>>>>>> > >> > >>>>>>> These patches will provide progress toward code being the > >> > >>>>>>> central discussion vehicle. As a community, we can then > >> > >>>>>>> incrementally > >> > >> build > >> > >>>>>>> on that foundation in order to collaboratively deliver the > >> > >>>>>>> common > >> > >>>> vision. > >> > >>>>>>> > >> > >>>>>>> In the absence of any other home for posting such patches, > >> > >>>>>>> let's assume that they will be attached to HADOOP-9392 - or > >> > >>>>>>> a dedicated subtask for this particular aspect/s - I will > >> > >>>>>>> leave that detail > >> to > >> > >>>> Kai. > >> > >>>>>>> > >> > >>>>>>> @Alejandro, being the only voice on this thread that isn't > >> > >>>>>>> represented in the votes above, please feel free to agree > >> > >>>>>>> or > >> > >>> disagree > >> > >>>> with this direction. > >> > >>>>>>> > >> > >>>>>>> thanks, > >> > >>>>>>> > >> > >>>>>>> --larry > >> > >>>>>>> > >> > >>>>>>> On Jul 5, 2013, at 3:24 PM, Larry McCay > >> > >>>>>>> <lmc...@hortonworks.com> > >> > >>>> wrote: > >> > >>>>>>> > >> > >>>>>>>> Hi Andy - > >> > >>>>>>>> > >> > >>>>>>>>> Happy Fourth of July to you and yours. > >> > >>>>>>>> > >> > >>>>>>>> Same to you and yours. :-) We had some fun in the sun for > >> > >>>>>>>> a change - we've had nothing but > >> > >>> rain > >> > >>>>>>>> on > >> > >>>>>>> the east coast lately. > >> > >>>>>>>> > >> > >>>>>>>>> My concern here is there may have been a > >> > >>>>>>>>> misinterpretation or > >> > >> lack > >> > >>>>>>>>> of consensus on what is meant by "clean slate" > >> > >>>>>>>> > >> > >>>>>>>> > >> > >>>>>>>> Apparently so. > >> > >>>>>>>> On the pre-summit call, I stated that I was interested in > >> > >>>>>>>> reconciling > >> > >>>>>>> the jiras so that we had one to work from. > >> > >>>>>>>> > >> > >>>>>>>> You recommended that we set them aside for the time being > >> > >>>>>>>> - with > >> > >>> the > >> > >>>>>>> understanding that work would continue on your side (and > >> > >>>>>>> our's as > >> > >>>>>>> well) - and approach the community discussion from a clean > slate. > >> > >>>>>>>> We seemed to do this at the summit session quite well. > >> > >>>>>>>> It was my understanding that this community discussion > >> > >>>>>>>> would > >> live > >> > >>>>>>>> beyond > >> > >>>>>>> the summit and continue on this list. > >> > >>>>>>>> > >> > >>>>>>>> While closing the summit session we agreed to follow up on > >> > >>>>>>>> common-dev > >> > >>>>>>> with first a summary then a discussion of the moving parts. > >> > >>>>>>>> > >> > >>>>>>>> I never expected the previous work to be abandoned and > >> > >>>>>>>> fully expected it > >> > >>>>>>> to inform the discussion that happened here. > >> > >>>>>>>> > >> > >>>>>>>> If you would like to reframe what clean slate was supposed > >> > >>>>>>>> to > >> > >> mean > >> > >>>>>>>> or > >> > >>>>>>> describe what it means now - that would be welcome - before > >> > >>>>>>> I > >> > >> waste > >> > >>>>>>> anymore time trying to facilitate a community discussion > >> > >>>>>>> that is apparently not wanted. > >> > >>>>>>>> > >> > >>>>>>>>> Nowhere in this > >> > >>>>>>>>> picture are self appointed "master JIRAs" and such, which > >> > >>>>>>>>> have > >> > >>> been > >> > >>>>>>>>> disappointing to see crop up, we should be > >> > >>>>>>>>> collaboratively > >> > >> coding > >> > >>>>>>>>> not planting flags. > >> > >>>>>>>> > >> > >>>>>>>> I don't know what you mean by self-appointed master JIRAs. > >> > >>>>>>>> It has certainly not been anyone's intention to disappoint. > >> > >>>>>>>> Any mention of a new JIRA was just to have a clear context > >> > >>>>>>>> to > >> > >>> gather > >> > >>>>>>>> the > >> > >>>>>>> agreed upon points - previous and/or existing JIRAs would > >> > >>>>>>> easily > >> > >> be > >> > >>>> linked. > >> > >>>>>>>> > >> > >>>>>>>> Planting flags... I need to go back and read my discussion > >> > >>>>>>>> point about the > >> > >>>>>>> JIRA and see how this is the impression that was made. > >> > >>>>>>>> That is not how I define success. The only flags that > >> > >>>>>>>> count is > >> > >>> code. > >> > >>>>>>> What we are lacking is the roadmap on which to put the code. > >> > >>>>>>>> > >> > >>>>>>>>> I read Kai's latest document as something approaching > >> > >>>>>>>>> today's consensus > >> > >>>>>>> (or > >> > >>>>>>>>> at least a common point of view?) rather than a > >> > >>>>>>>>> historical > >> > >>> document. > >> > >>>>>>>>> Perhaps he and it can be given equal share of the > >> consideration. > >> > >>>>>>>> > >> > >>>>>>>> I definitely read it as something that has evolved into > >> something > >> > >>>>>>> approaching what we have been talking about so far. There > >> > >>>>>>> has not however been enough discussion anywhere near the > >> > >>>>>>> level of detail > >> > >> in > >> > >>>>>>> that document and more details are needed for each > >> > >>>>>>> component in > >> > >> the > >> > >>>> design. > >> > >>>>>>>> Why the work in that document should not be fed into the > >> > >> community > >> > >>>>>>> discussion as anyone else's would be - I fail to understand. > >> > >>>>>>>> > >> > >>>>>>>> My suggestion continues to be that you should take that > >> > >>>>>>>> document > >> > >>> and > >> > >>>>>>> speak to the inventory of moving parts as we agreed. > >> > >>>>>>>> As these are agreed upon, we will ensure that the > >> > >>>>>>>> appropriate subtasks > >> > >>>>>>> are filed against whatever JIRA is to host them - don't > >> > >>>>>>> really > >> > >> care > >> > >>>>>>> much which it is. > >> > >>>>>>>> > >> > >>>>>>>> I don't really want to continue with two separate JIRAs - > >> > >>>>>>>> as I stated > >> > >>>>>>> long ago - but until we understand what the pieces are and > >> > >>>>>>> how > >> > >> they > >> > >>>>>>> relate then they can't be consolidated. > >> > >>>>>>>> Even if 9533 ended up being repurposed as the server > >> > >>>>>>>> instance of > >> > >>> the > >> > >>>>>>> work - it should be a subtask of a larger one - if that is > >> > >>>>>>> to be 9392, so be it. > >> > >>>>>>>> We still need to define all the pieces of the larger > >> > >>>>>>>> picture > >> > >> before > >> > >>>>>>>> that > >> > >>>>>>> can be done. > >> > >>>>>>>> > >> > >>>>>>>> What I thought was the clean slate approach to the > >> > >>>>>>>> discussion > >> > >>> seemed > >> > >>>>>>>> a > >> > >>>>>>> very reasonable way to make all this happen. > >> > >>>>>>>> If you would like to restate what you intended by it or > >> something > >> > >>>>>>>> else > >> > >>>>>>> equally as reasonable as a way to move forward that would > >> > >>>>>>> be > >> > >>> awesome. > >> > >>>>>>>> > >> > >>>>>>>> I will be happy to work toward the roadmap with everyone > >> > >>>>>>>> once it > >> > >> is > >> > >>>>>>> articulated, understood and actionable. > >> > >>>>>>>> In the meantime, I have work to do. > >> > >>>>>>>> > >> > >>>>>>>> thanks, > >> > >>>>>>>> > >> > >>>>>>>> --larry > >> > >>>>>>>> > >> > >>>>>>>> BTW - I meant to quote you in an earlier response and > >> > >>>>>>>> ended up saying it > >> > >>>>>>> was Aaron instead. Not sure what happened there. :-) > >> > >>>>>>>> > >> > >>>>>>>> On Jul 4, 2013, at 2:40 PM, Andrew Purtell > >> > >>>>>>>> <apurt...@apache.org > >> > > >> > >>>> wrote: > >> > >>>>>>>> > >> > >>>>>>>>> Hi Larry (and all), > >> > >>>>>>>>> > >> > >>>>>>>>> Happy Fourth of July to you and yours. > >> > >>>>>>>>> > >> > >>>>>>>>> In our shop Kai and Tianyou are already doing the coding, > >> > >>>>>>>>> so > >> I'd > >> > >>>>>>>>> defer > >> > >>>>>>> to > >> > >>>>>>>>> them on the detailed points. > >> > >>>>>>>>> > >> > >>>>>>>>> My concern here is there may have been a > >> > >>>>>>>>> misinterpretation or > >> > >> lack > >> > >>>>>>>>> of consensus on what is meant by "clean slate". Hopefully > >> > >>>>>>>>> that > >> > >> can > >> > >>>>>>>>> be > >> > >>>>>>> quickly > >> > >>>>>>>>> cleared up. Certainly we did not mean ignore all that > >> > >>>>>>>>> came > >> > >> before. > >> > >>>>>>>>> The > >> > >>>>>>> idea > >> > >>>>>>>>> was to reset discussions to find common ground and new > >> direction > >> > >>>>>>>>> where > >> > >>>>>>> we > >> > >>>>>>>>> are working together, not in conflict, on an agreed upon > >> > >>>>>>>>> set of design points and tasks. There's been a lot of > >> > >>>>>>>>> good discussion > >> > >> and > >> > >>>>>>>>> design preceeding that we should figure out how to port > over. > >> > >>>>>>>>> Nowhere in this picture are self appointed "master JIRAs" > >> > >>>>>>>>> and > >> > >>> such, > >> > >>>>>>>>> which have been disappointing to see crop up, we should > >> > >>>>>>>>> be collaboratively coding not planting flags. > >> > >>>>>>>>> > >> > >>>>>>>>> I read Kai's latest document as something approaching > >> > >>>>>>>>> today's consensus > >> > >>>>>>> (or > >> > >>>>>>>>> at least a common point of view?) rather than a > >> > >>>>>>>>> historical > >> > >>> document. > >> > >>>>>>>>> Perhaps he and it can be given equal share of the > >> consideration. > >> > >>>>>>>>> > >> > >>>>>>>>> > >> > >>>>>>>>> On Wednesday, July 3, 2013, Larry McCay wrote: > >> > >>>>>>>>> > >> > >>>>>>>>>> Hey Andrew - > >> > >>>>>>>>>> > >> > >>>>>>>>>> I largely agree with that statement. > >> > >>>>>>>>>> My intention was to let the differences be worked out > >> > >>>>>>>>>> within > >> > >> the > >> > >>>>>>>>>> individual components once they were identified and > >> > >>>>>>>>>> subtasks > >> > >>>> created. > >> > >>>>>>>>>> > >> > >>>>>>>>>> My reference to HSSO was really referring to a SSO > >> > >>>>>>>>>> *server* > >> > >> based > >> > >>>>>>> design > >> > >>>>>>>>>> which was not clearly articulated in the earlier documents. > >> > >>>>>>>>>> We aren't trying to compare and contrast one design over > >> > >> another > >> > >>>>>>> anymore. > >> > >>>>>>>>>> > >> > >>>>>>>>>> Let's move this collaboration along as we've mapped out > >> > >>>>>>>>>> and > >> the > >> > >>>>>>>>>> differences in the details will reveal themselves and be > >> > >>> addressed > >> > >>>>>>> within > >> > >>>>>>>>>> their components. > >> > >>>>>>>>>> > >> > >>>>>>>>>> I've actually been looking forward to you weighing in on > >> > >>>>>>>>>> the actual discussion points in this thread. > >> > >>>>>>>>>> Could you do that? > >> > >>>>>>>>>> > >> > >>>>>>>>>> At this point, I am most interested in your thoughts on > >> > >>>>>>>>>> a > >> > >> single > >> > >>>>>>>>>> jira > >> > >>>>>>> to > >> > >>>>>>>>>> represent all of this work and whether we should start > >> > >> discussing > >> > >>>>>>>>>> the > >> > >>>>>>> SSO > >> > >>>>>>>>>> Tokens. > >> > >>>>>>>>>> If you think there are discussion points missing from > >> > >>>>>>>>>> that > >> > >> list, > >> > >>>>>>>>>> feel > >> > >>>>>>> free > >> > >>>>>>>>>> to add to it. > >> > >>>>>>>>>> > >> > >>>>>>>>>> thanks, > >> > >>>>>>>>>> > >> > >>>>>>>>>> --larry > >> > >>>>>>>>>> > >> > >>>>>>>>>> On Jul 3, 2013, at 7:35 PM, Andrew Purtell < > >> > >> apurt...@apache.org> > >> > >>>>>>> wrote: > >> > >>>>>>>>>> > >> > >>>>>>>>>>> Hi Larry, > >> > >>>>>>>>>>> > >> > >>>>>>>>>>> Of course I'll let Kai speak for himself. However, let > >> > >>>>>>>>>>> me > >> > >> point > >> > >>>>>>>>>>> out > >> > >>>>>>> that, > >> > >>>>>>>>>>> while the differences between the competing JIRAs have > >> > >>>>>>>>>>> been reduced > >> > >>>>>>> for > >> > >>>>>>>>>>> sure, there were some key differences that didn't just > >> > >>> disappear. > >> > >>>>>>>>>>> Subsequent discussion will make that clear. I also > >> > >>>>>>>>>>> disagree > >> > >> with > >> > >>>>>>>>>>> your characterization that we have simply endorsed all > >> > >>>>>>>>>>> of the design > >> > >>>>>>> decisions > >> > >>>>>>>>>>> of the so-called HSSO, this is taking a mile from an > >> > >>>>>>>>>>> inch. We > >> > >>> are > >> > >>>>>>> here to > >> > >>>>>>>>>>> engage in a collaborative process as peers. I've been > >> > >> encouraged > >> > >>>>>>>>>>> by > >> > >>>>>>> the > >> > >>>>>>>>>>> spirit of the discussions up to this point and hope > >> > >>>>>>>>>>> that can continue beyond one design summit. > >> > >>>>>>>>>>> > >> > >>>>>>>>>>> > >> > >>>>>>>>>>> > >> > >>>>>>>>>>> On Wed, Jul 3, 2013 at 1:10 PM, Larry McCay > >> > >>>>>>>>>>> <lmc...@hortonworks.com> > >> > >>>>>>>>>> wrote: > >> > >>>>>>>>>>> > >> > >>>>>>>>>>>> Hi Kai - > >> > >>>>>>>>>>>> > >> > >>>>>>>>>>>> I think that I need to clarify something... > >> > >>>>>>>>>>>> > >> > >>>>>>>>>>>> This is not an update for 9533 but a continuation of > >> > >>>>>>>>>>>> the discussions > >> > >>>>>>>>>> that > >> > >>>>>>>>>>>> are focused on a fresh look at a SSO for Hadoop. > >> > >>>>>>>>>>>> We've agreed to leave our previous designs behind and > >> > >> therefore > >> > >>>>>>>>>>>> we > >> > >>>>>>>>>> aren't > >> > >>>>>>>>>>>> really seeing it as an HSSO layered on top of TAS > >> > >>>>>>>>>>>> approach > >> or > >> > >>> an > >> > >>>>>>> HSSO vs > >> > >>>>>>>>>>>> TAS discussion. > >> > >>>>>>>>>>>> > >> > >>>>>>>>>>>> Your latest design revision actually makes it clear > >> > >>>>>>>>>>>> that you > >> > >>> are > >> > >>>>>>>>>>>> now targeting exactly what was described as HSSO - so > >> > >> comparing > >> > >>>>>>>>>>>> and > >> > >>>>>>>>>> contrasting > >> > >>>>>>>>>>>> is not going to add any value. > >> > >>>>>>>>>>>> > >> > >>>>>>>>>>>> What we need you to do at this point, is to look at > >> > >>>>>>>>>>>> those high-level components described on this thread > >> > >>>>>>>>>>>> and comment > >> on > >> > >>>>>>>>>>>> whether we need additional components or any that are > >> > >>>>>>>>>>>> listed that don't seem > >> > >>>>>>> necessary > >> > >>>>>>>>>> to > >> > >>>>>>>>>>>> you and why. > >> > >>>>>>>>>>>> In other words, we need to define and agree on the > >> > >>>>>>>>>>>> work that > >> > >>> has > >> > >>>>>>>>>>>> to > >> > >>>>>>> be > >> > >>>>>>>>>>>> done. > >> > >>>>>>>>>>>> > >> > >>>>>>>>>>>> We also need to determine those components that need > >> > >>>>>>>>>>>> to be > >> > >> done > >> > >>>>>>> before > >> > >>>>>>>>>>>> anything else can be started. > >> > >>>>>>>>>>>> I happen to agree with Brian that #4 Hadoop SSO Tokens > >> > >>>>>>>>>>>> are central to > >> > >>>>>>>>>> all > >> > >>>>>>>>>>>> the other components and should probably be defined > >> > >>>>>>>>>>>> and > >> POC'd > >> > >>> in > >> > >>>>>>> short > >> > >>>>>>>>>>>> order. > >> > >>>>>>>>>>>> > >> > >>>>>>>>>>>> Personally, I think that continuing the separation of > >> > >>>>>>>>>>>> 9533 > >> > >> and > >> > >>>>>>>>>>>> 9392 > >> > >>>>>>> will > >> > >>>>>>>>>>>> do this effort a disservice. There doesn't seem to be > >> > >>>>>>>>>>>> enough > >> > >>>>>>> differences > >> > >>>>>>>>>>>> between the two to justify separate jiras anymore. It > >> > >>>>>>>>>>>> may be best to > >> > >>>>>>>>>> file a > >> > >>>>>>>>>>>> new one that reflects a single vision without the > >> > >>>>>>>>>>>> extra > >> cruft > >> > >>>>>>>>>>>> that > >> > >>>>>>> has > >> > >>>>>>>>>>>> built up in either of the existing ones. We would > >> > >>>>>>>>>>>> certainly reference > >> > >>>>>>>>>> the > >> > >>>>>>>>>>>> existing ones within the new one. This approach would > >> > >>>>>>>>>>>> align > >> > >>> with > >> > >>>>>>>>>>>> the > >> > >>>>>>>>>> spirit > >> > >>>>>>>>>>>> of the discussions up to this point. > >> > >>>>>>>>>>>> > >> > >>>>>>>>>>>> I am prepared to start a discussion around the shape > >> > >>>>>>>>>>>> of the > >> > >> two > >> > >>>>>>> Hadoop > >> > >>>>>>>>>> SSO > >> > >>>>>>>>>>>> tokens: identity and access. If this is what others > >> > >>>>>>>>>>>> feel the next > >> > >>>>>>> topic > >> > >>>>>>>>>>>> should be. > >> > >>>>>>>>>>>> If we can identify a jira home for it, we can do it > >> > >>>>>>>>>>>> there - > >> > >>>>>>> otherwise we > >> > >>>>>>>>>>>> can create another DISCUSS thread for it. > >> > >>>>>>>>>>>> > >> > >>>>>>>>>>>> thanks, > >> > >>>>>>>>>>>> > >> > >>>>>>>>>>>> --larry > >> > >>>>>>>>>>>> > >> > >>>>>>>>>>>> > >> > >>>>>>>>>>>> On Jul 3, 2013, at 2:39 PM, "Zheng, Kai" < > >> > >> kai.zh...@intel.com> > >> > >>>>>>> wrote: > >> > >>>>>>>>>>>> > >> > >>>>>>>>>>>>> Hi Larry, > >> > >>>>>>>>>>>>> > >> > >>>>>>>>>>>>> Thanks for the update. Good to see that with this > >> > >>>>>>>>>>>>> update we > >> > >>> are > >> > >>>>>>>>>>>>> now > >> > >>>>>>>>>>>> aligned on most points. > >> > >>>>>>>>>>>>> > >> > >>>>>>>>>>>>> I have also updated our TokenAuth design in HADOOP-9392. > >> The > >> > >>>>>>>>>>>>> new > >> > >>>>>>>>>>>> revision incorporates feedback and suggestions in > >> > >>>>>>>>>>>> related discussion > >> > >>>>>>>>>> with > >> > >>>>>>>>>>>> the community, particularly from Microsoft and others > >> > >> attending > >> > >>>>>>>>>>>> the Security design lounge session at the Hadoop summit. > >> > >>> Summary > >> > >>>>>>>>>>>> of the > >> > >>>>>>>>>> changes: > >> > >>>>>>>>>>>>> 1. Revised the approach to now use two tokens, > Identity > >> > >>> Token > >> > >>>>>>> plus > >> > >>>>>>>>>>>> Access Token, particularly considering our > >> > >>>>>>>>>>>> authorization framework > >> > >>>>>>> and > >> > >>>>>>>>>>>> compatibility with HSSO; > >> > >>>>>>>>>>>>> 2. Introduced Authorization Server (AS) from our > >> > >>>> authorization > >> > >>>>>>>>>>>> framework into the flow that issues access tokens for > >> clients > >> > >>>>>>>>>>>> with > >> > >>>>>>>>>> identity > >> > >>>>>>>>>>>> tokens to access services; > >> > >>>>>>>>>>>>> 3. Refined proxy access token and the > >> proxy/impersonation > >> > >>>> flow; > >> > >>>>>>>>>>>>> 4. Refined the browser web SSO flow regarding access > to > >> > >>>> Hadoop > >> > >>>>>>> web > >> > >>>>>>>>>>>> services; > >> > >>>>>>>>>>>>> 5. Added Hadoop RPC access flow regard > >> > >>>>>>>>> > >> > >>>>>>>>> > >> > >>>>>>>>> > >> > >>>>>>>>> -- > >> > >>>>>>>>> Best regards, > >> > >>>>>>>>> > >> > >>>>>>>>> - Andy > >> > >>>>>>>>> > >> > >>>>>>>>> Problems worthy of attack prove their worth by hitting > >> > >>>>>>>>> back. - > >> > >>> Piet > >> > >>>>>>>>> Hein (via Tom White) > >> > >>>>>>>> > >> > >>>>>>> > >> > >>>>>>> > >> > >>>>>> > >> > >>>>>> > >> > >>>>>> -- > >> > >>>>>> Alejandro > >> > >>>>>> > >> > >>>>> > >> > >>>>> > >> > >>>>> > >> > >>>>> > >> > >>>>> > >> > >>>>> <Iteration1PluggableUserAuthenticationandFederation.pdf> > >> > >>>> > >> > >>>> > >> > >>> > >> > >>> > >> > >>> -- > >> > >>> Alejandro > >> > >>> > >> > >> > >> > > > >> > > > >> > > > >> > > -- > >> > > Alejandro > >> > > >> > > >> > > > > -- > > CONFIDENTIALITY NOTICE > > NOTICE: This message is intended for the use of the individual or > > entity to which it is addressed and may contain information that is > > confidential, privileged and exempt from disclosure under applicable > > law. If the reader of this message is not the intended recipient, you > > are hereby notified that any printing, copying, dissemination, > > distribution, disclosure or forwarding of this communication is > > strictly prohibited. If you have received this communication in error, > > please contact the sender immediately and delete it from your system. > Thank You. > -- CONFIDENTIALITY NOTICE NOTICE: This message is intended for the use of the individual or entity to which it is addressed and may contain information that is confidential, privileged and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, you are hereby notified that any printing, copying, dissemination, distribution, disclosure or forwarding of this communication is strictly prohibited. If you have received this communication in error, please contact the sender immediately and delete it from your system. Thank You.
