Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 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
> To: [EMAIL PROTECTED]
> 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
> +-------+
> |HADOOP |
> |SERVICE|
> +-------+
>
> 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
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB