You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@knox.apache.org by lm...@apache.org on 2015/11/29 18:52:58 UTC
svn commit: r1717102 - /knox/site/books/knox-0-7-0/user-guide.html
Author: lmccay
Date: Sun Nov 29 17:52:58 2015
New Revision: 1717102
URL: http://svn.apache.org/viewvc?rev=1717102&view=rev
Log:
updated knox_sso_config
Modified:
knox/site/books/knox-0-7-0/user-guide.html
Modified: knox/site/books/knox-0-7-0/user-guide.html
URL: http://svn.apache.org/viewvc/knox/site/books/knox-0-7-0/user-guide.html?rev=1717102&r1=1717101&r2=1717102&view=diff
==============================================================================
--- knox/site/books/knox-0-7-0/user-guide.html (original)
+++ knox/site/books/knox-0-7-0/user-guide.html Sun Nov 29 17:52:58 2015
@@ -2024,7 +2024,7 @@ APACHE_HOME/bin/apachectl -k stop
</code></pre><h5><a id="REST+Invocation+for+Tivoli+AM">REST Invocation for Tivoli AM</a> <a href="#REST+Invocation+for+Tivoli+AM"><img src="markbook-section-link.png"/></a></h5><p>The following curl command can be used to request a directory listing from HDFS while passing in the expected headers of iv_user and iv_group. Note that the iv_group value in this command matches the expected ACL for webhdfs in the above topology file. Changing this from “admin” to “admin2” should result in a 401 unauthorized response.</p>
<pre><code>curl -k -i --header "iv_user: guest" --header "iv_group: admin" -v https://localhost:8443/gateway/sandbox/webhdfs/v1/tmp?op=LISTSTATUS
</code></pre><p>Omitting the –header “iv_user: guest” above will result in a rejected request.</p><h1><a id="KnoxSSO+Setup+and+Configuration">KnoxSSO Setup and Configuration</a> <a href="#KnoxSSO+Setup+and+Configuration"><img src="markbook-section-link.png"/></a></h1><h2><a id="Introduction">Introduction</a> <a href="#Introduction"><img src="markbook-section-link.png"/></a></h2>
-<hr/><p>Authentication of the Hadoop component UIs, and those of the overall ecosystem, is usually limited to Kerberos (which requires SPNEGO to be configured for the user’s browser) and simple/psuedo. This often results in the UIs not being secured - even in secured clusters. This is where KnoxSSO provides value for through providing WebSSO capabilities to the Hadoop cluster.</p><p>By leveraging the hadoop-auth module in Hadoop common, we have introduced the ability to consume a common SSO cookie for web UIs while retaining the non-web browser authentication through kerberos/SPNEGO. We do this by extneding the AltKerberosAuthenticationHandler class which provides the useragent based multiplexing. </p><p>We also provide integration guidance within the developers guide for other applications to be able to participate in these SSO capabilities.</p><p>The flexibility of the Apache Knox authentication and federation providers allows KnoxSSO to provide a normalization of authentica
tion events through token exchange resulting in a common JWT (JSON WebToken) based token.</p><p>KnoxSSO provides an abstraction for integrating any number of authentication systems and SSO solutions and enables participating web applications to scale to those solutions more easily. Without the token exchange capabilities offered by KnoxSSO each component UI would need to integrate with each desired solution on its own. With KnoxSSO they only need to integrate with the single solution and common token.</p><p>This document describes the overall setup requirements for KnoxSSO and participating applications. [Please see the integration guide for instructions in adding support for new applications.]</p><h4><a id="KnoxSSO+Setup">KnoxSSO Setup</a> <a href="#KnoxSSO+Setup"><img src="markbook-section-link.png"/></a></h4><h5><a id="knoxsso.xml+Topology">knoxsso.xml Topology</a> <a href="#knoxsso.xml+Topology"><img src="markbook-section-link.png"/></a></h5><p>To enable KnoxSSO, we need to conf
igure the KnoxSSO topology. The following is an example of this topology which is configured to use HTTP Basic Auth against the Knox Demo LDAP server. This is the lowest barrier of entry for your development environment that actually authenticates against a real user store. Whatâs great is if you work against the IdP with Basic Auth then you will work with SAML or anything else as well. SAML support is provided through our PicketLink federation provider and we will provide an example configuration for that as well.</p>
+<hr/><p>Authentication of the Hadoop component UIs, and those of the overall ecosystem, is usually limited to Kerberos (which requires SPNEGO to be configured for the user’s browser) and simple/psuedo. This often results in the UIs not being secured - even in secured clusters. This is where KnoxSSO provides value for through providing WebSSO capabilities to the Hadoop cluster.</p><p>By leveraging the hadoop-auth module in Hadoop common, we have introduced the ability to consume a common SSO cookie for web UIs while retaining the non-web browser authentication through kerberos/SPNEGO. We do this by extneding the AltKerberosAuthenticationHandler class which provides the useragent based multiplexing. </p><p>We also provide integration guidance within the developers guide for other applications to be able to participate in these SSO capabilities.</p><p>The flexibility of the Apache Knox authentication and federation providers allows KnoxSSO to provide a normalization of authentica
tion events through token exchange resulting in a common JWT (JSON WebToken) based token.</p><p>KnoxSSO provides an abstraction for integrating any number of authentication systems and SSO solutions and enables participating web applications to scale to those solutions more easily. Without the token exchange capabilities offered by KnoxSSO each component UI would need to integrate with each desired solution on its own. With KnoxSSO they only need to integrate with the single solution and common token.</p><p>This document describes the overall setup requirements for KnoxSSO and participating applications. [Please see the integration guide for instructions in adding support for new applications.]</p><h2><a id="KnoxSSO+Setup">KnoxSSO Setup</a> <a href="#KnoxSSO+Setup"><img src="markbook-section-link.png"/></a></h2><h3><a id="knoxsso.xml+Topology">knoxsso.xml Topology</a> <a href="#knoxsso.xml+Topology"><img src="markbook-section-link.png"/></a></h3><p>To enable KnoxSSO, we need to conf
igure the KnoxSSO topology. The following is an example of this topology which is configured to use HTTP Basic Auth against the Knox Demo LDAP server. This is the lowest barrier of entry for your development environment that actually authenticates against a real user store. Whatâs great is if you work against the IdP with Basic Auth then you will work with SAML or anything else as well. SAML support is provided through our PicketLink federation provider and we will provide an example configuration for that as well.</p>
<pre><code> <?xml version="1.0" encoding="utf-8"?>
<topology>
<gateway>
@@ -2125,7 +2125,7 @@ APACHE_HOME/bin/apachectl -k stop
<td>^/.*$;^https?://localhost:\d{0,9}/.*$</td>
</tr>
</tbody>
-</table><h3><a id="Hadoop+Configuration+Example">Hadoop Configuration Example</a> <a href="#Hadoop+Configuration+Example"><img src="markbook-section-link.png"/></a></h3><p>The following is used as the KnoxSSO configuration in the Hadoop JWTRedirectAuthenticationHandler implementation. Any participating application will need similar configuration. Since JWTRedirectAuthenticationHandler extends the AltKerberosAuthenticationHandler, the typical kerberos configuration parameters for authentication are also required.</p>
+</table><h2><a id="Participating+Application+Configuration">Participating Application Configuration</a> <a href="#Participating+Application+Configuration"><img src="markbook-section-link.png"/></a></h2><h3><a id="Hadoop+Configuration+Example">Hadoop Configuration Example</a> <a href="#Hadoop+Configuration+Example"><img src="markbook-section-link.png"/></a></h3><p>The following is used as the KnoxSSO configuration in the Hadoop JWTRedirectAuthenticationHandler implementation. Any participating application will need similar configuration. Since JWTRedirectAuthenticationHandler extends the AltKerberosAuthenticationHandler, the typical kerberos configuration parameters for authentication are also required.</p>
<pre><code> <property>
<name>hadoop.http.authentication.type</name> <value>org.apache.hadoop.security.authentication.server.JWTRedirectAuthenticationHandler</value>
</property>