Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
Hadoop >> mail # dev >> [DISCUSS] Hadoop SSO/Token Server Components

Copy link to this message
Re: [DISCUSS] Hadoop SSO/Token Server Components
Thanks, Brian!
Look at that - the power of collaboration - the numbering is correct already! ;-)

I am inclined to agree that we should start with the Hadoop SSO Tokens and am leaning toward a new jira that leaves behind the cruft but I don't feel very strongly about it being new.
I do feel like, especially given Kai's new document, that we have only one.

On Jul 3, 2013, at 2:32 PM, Brian Swan <[EMAIL PROTECTED]> wrote:

> Thanks, Larry, for starting this conversation (and thanks for the great Summit meeting summary you sent out a couple of days ago). To weigh in on your specific discussion points (and renumber them :-))...
> 1. Are there additional components that would be required for a Hadoop SSO service?
> Not that I can see.
> 2. Should any of the above described components be considered not actually necessary or poorly described?
> I think this will be determined as we get into the details of each component. What you've described here is certainly an excellent starting point.
> 3. Should we create a new umbrella Jira to identify each of these as a subtask?
> 4. Should we just continue to use 9533 for the SSO server and add additional subtasks?
> What is described here seem to fit with 9533, though 9533 may contain some details that need further discussion. IMHO, it may be better to file a new umbrella Jira, though I'm not 100% convinced of that. Would be very interested on input from others.
> 5. What are the natural seams of separation between these components and any dependencies between one and another that affect priority?
> Is 4 the right place to start? (4. Hadoop SSO Tokens: the exact shape and form of the sso tokens...) It seemed that in some 1:1 conversations after the Summit meeting that others may agree with this. Would like to hear if that is the case more broadly.
> -Brian
> -----Original Message-----
> From: Larry McCay [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, July 2, 2013 1:04 PM
> Subject: [DISCUSS] Hadoop SSO/Token Server Components
> All -
> As a follow up to the discussions that were had during Hadoop Summit, I would like to introduce the discussion topic around the moving parts of a Hadoop SSO/Token Service.
> There are a couple of related Jira's that can be referenced and may or may not be updated as a result of this discuss thread.
> https://issues.apache.org/jira/browse/HADOOP-9533
> https://issues.apache.org/jira/browse/HADOOP-9392
> As the first aspect of the discussion, we should probably state the overall goals and scoping for this effort:
> * An alternative authentication mechanism to Kerberos for user authentication
> * A broader capability for integration into enterprise identity and SSO solutions
> * Possibly the advertisement/negotiation of available authentication mechanisms
> * Backward compatibility for the existing use of Kerberos
> * No (or minimal) changes to existing Hadoop tokens (delegation, job, block access, etc)
> * Pluggable authentication mechanisms across: RPC, REST and webui enforcement points
> * Continued support for existing authorization policy/ACLs, etc
> * Keeping more fine grained authorization policies in mind - like attribute based access control
> - fine grained access control is a separate but related effort that we must not preclude with this effort
> * Cross cluster SSO
> In order to tease out the moving parts here are a couple high level and simplified descriptions of SSO interaction flow:
>                               +------+
> +------+ credentials 1 | SSO  |
> |CLIENT|-------------->|SERVER|
> +------+  :tokens      +------+
>  2 |                    
>    | access token
>    V :requested resource
> +-------+
> +-------+
> The above diagram represents the simplest interaction model for an SSO service in Hadoop.
> 1. client authenticates to SSO service and acquires an access token
>  a. client presents credentials to an authentication service endpoint exposed by the SSO server (AS) and receives a token representing the authentication event and verified identity