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 2016/11/02 01:24:41 UTC
svn commit: r1767596 - in /knox: site/books/knox-0-9-0/user-guide.html
site/books/knox-0-9-1/user-guide.html
trunk/books/0.10.0/book_gateway-details.md
trunk/books/0.9.0/book_gateway-details.md
Author: lmccay
Date: Wed Nov 2 01:24:40 2016
New Revision: 1767596
URL: http://svn.apache.org/viewvc?rev=1767596&view=rev
Log:
fix links to hadoop-auth provider book
Modified:
knox/site/books/knox-0-9-0/user-guide.html
knox/site/books/knox-0-9-1/user-guide.html
knox/trunk/books/0.10.0/book_gateway-details.md
knox/trunk/books/0.9.0/book_gateway-details.md
Modified: knox/site/books/knox-0-9-0/user-guide.html
URL: http://svn.apache.org/viewvc/knox/site/books/knox-0-9-0/user-guide.html?rev=1767596&r1=1767595&r2=1767596&view=diff
==============================================================================
--- knox/site/books/knox-0-9-0/user-guide.html (original)
+++ knox/site/books/knox-0-9-0/user-guide.html Wed Nov 2 01:24:40 2016
@@ -2174,7 +2174,70 @@ APACHE_HOME/bin/apachectl -k stop
<td>DENY</td>
</tr>
</tbody>
-</table><h3><a id="Preauthenticated+SSO+Provider">Preauthenticated SSO Provider</a> <a href="#Preauthenticated+SSO+Provider"><img src="markbook-section-link.png"/></a></h3><p>A number of SSO solutions provide mechanisms for federating an authenticated identity across applications. These mechanisms are at times simple HTTP Header type tokens that can be used to propagate the identity across process boundaries.</p><p>Knox Gateway needs a pluggable mechanism for consuming these tokens and federating the asserted identity through an interaction with the Hadoop cluster. </p><p><strong>CAUTION: The use of this provider requires that proper network security and identity provider configuration and deployment does not allow requests directly to the Knox gateway. Otherwise, this provider will leave the gateway exposed to identity spoofing.</strong></p><h4><a id="Configuration">Configuration</a> <a href="#Configuration"><img src="markbook-section-link.png"/></a></h4><h5><a id="Overview">Overvi
ew</a> <a href="#Overview"><img src="markbook-section-link.png"/></a></h5><p>This provider was designed for use with identity solutions such as those provided by CA’s SiteMinder and IBM’s Tivoli Access Manager. While direct testing with these products has not been done, there has been extensive unit and functional testing that ensure that it should work with such providers.</p><p>The HeaderPreAuth provider is configured within the topology file and has a minimal configuration that assumes SM_USER for CA SiteMinder. The following example is the bare minimum configuration for SiteMinder (with no IP address validation).</p>
+</table><h3><a id="HadoopAuth+Authentication+Provider">HadoopAuth Authentication Provider</a> <a href="#HadoopAuth+Authentication+Provider"><img src="markbook-section-link.png"/></a></h3><p>The HadoopAuth authentication provider for Knox integrates the use of the Apache Hadoop module for SPNEGO and delegation token based authentication. This introduces the same authentication pattern used across much of the Hadoop ecosystem to Apache Knox and allows clients to using the strong authentication and SSO capabilities of Kerberos.</p><h4><a id="Configuration">Configuration</a> <a href="#Configuration"><img src="markbook-section-link.png"/></a></h4><h5><a id="Overview">Overview</a> <a href="#Overview"><img src="markbook-section-link.png"/></a></h5><p>As with all providers in the Knox gateway, the HadoopAuth provider is configured through provider params. The configuration parameters are the same parameters used within Apache Hadoop for the same capabilities. In this section, we provide an
example configuration and description of each of the parameters. We do encourage the reader to refer to the Hadoop documentation for this as well. (see <a href="http://hadoop.apache.org/docs/current/hadoop-auth/Configuration.html">http://hadoop.apache.org/docs/current/hadoop-auth/Configuration.html</a>)</p><p>One of the interesting things to note about this configuration is the use of the config.prefix parameter. In Hadoop there may be multiple components with their own specific configuration values for these parameters and since they may get mixed into the same Configuration object - there needs to be a way to identify the component specific values. The config.prefix parameter is used for this and is prepended to each of the configuration parameters for this provider. Below, you see an example configuration where the value for config.prefix happens to be ‘hadoop.auth.config’. You will also notice that this same value is prepended to the name of the rest of the configura
tion parameters.</p><p><provider> <role>authentication</role> <name>HadoopAuth</name> <enabled>true</enabled> <param> <name>config.prefix</name> <value>hadoop.auth.config</value> </param> <param> <name>hadoop.auth.config.signature.secret</name> <value>knox-signature-secret</value> </param> <param> <name>hadoop.auth.config.type</name> <value>kerberos</value> </param> <param> <name>hadoop.auth.config.simple.anonymous.allowed</name> <value>false</value> </param> <param> <name>hadoop.auth.config.token.validity</name> <value>1800</value> </param> <param> <name>hadoop.auth.config.cookie.domain</name> <value>novalocal</value> </param> <param> <name>hadoop.auth.config.cookie.path</name> <value>gateway/default</value> </param> <param> <name>hadoop.auth.config.kerberos.principal</name> <value>HTTP/lmccay<a href="mailto:-knoxft-24m-r6-sec-160422-13
2;7-2.novalocal@EXAMPLE.COM</value">-knoxft-24m-r6-sec-160422-1327-2.novalocal@EXAMPLE.COM</value</a> </param> <param> <name>hadoop.auth.config.kerberos.keytab</name> <value>/etc/security/keytabs/spnego.service.keytab</value> </param> <param> <name>hadoop.auth.config.kerberos.name.rules</name> <value>DEFAULT</value> </param> </provider></p><h4><a id="Descriptions">Descriptions</a> <a href="#Descriptions"><img src="markbook-section-link.png"/></a></h4><p>The following tables describes the configuration parameters for the HadoopAuth provider:</p><h6><a id="Config">Config</a> <a href="#Config"><img src="markbook-section-link.png"/></a></h6>
+<table>
+ <thead>
+ <tr>
+ <th>Name </th>
+ <th>Description </th>
+ <th>Default</th>
+ </tr>
+ </thead>
+ <tbody>
+ <tr>
+ <td>config.prefix</td>
+ <td>If specified, all other configuration parameter names must start with the prefix.</td>
+ <td>none</td>
+ </tr>
+ <tr>
+ <td>signature.secret</td>
+ <td>This is the secret used to sign the delegation token in the hadoop.auth cookie. This same secret needs to be used across all instances of the Knox gateway in a given cluster. Otherwise, the delegation token will fail validation and authentication will be repeated each request.</td>
+ <td>a simple random number</td>
+ </tr>
+ <tr>
+ <td>type</td>
+ <td>This parameter needs to be set to kerberos.</td>
+ <td>none, would throw exception</td>
+ </tr>
+ <tr>
+ <td>simple.anonymous.allowed</td>
+ <td>This should always be false for a secure deployment.</td>
+ <td>true</td>
+ </tr>
+ <tr>
+ <td>token.validity</td>
+ <td>The validity -in seconds- of the generated authentication token. This is also used for the rollover interval when signer.secret.provider is set to random or zookeeper.</td>
+ <td>36000 seconds</td>
+ </tr>
+ <tr>
+ <td>cookie.domain</td>
+ <td>domain to use for the HTTP cookie that stores the authentication token</td>
+ <td>null</td>
+ </tr>
+ <tr>
+ <td>cookie.path</td>
+ <td>path to use for the HTTP cookie that stores the authentication token</td>
+ <td>null</td>
+ </tr>
+ <tr>
+ <td>kerberos.principal</td>
+ <td>The web-application Kerberos principal name. The Kerberos principal name must start with HTTP/…. For example: HTTP/localhost@LOCALHOST</td>
+ <td>null</td>
+ </tr>
+ <tr>
+ <td>kerberos.keytab</td>
+ <td>The path to the keytab file containing the credentials for the kerberos principal. For example: /Users/lmccay/lmccay.keytab</td>
+ <td>null</td>
+ </tr>
+ <tr>
+ <td>kerberos.name.rules</td>
+ <td>The name of the ruleset for extracting the username from the kerberos principal.</td>
+ <td>DEFAULT</td>
+ </tr>
+ </tbody>
+</table><h6><a id="REST+Invocation">REST Invocation</a> <a href="#REST+Invocation"><img src="markbook-section-link.png"/></a></h6><p>Once a user logs in with kinit then their kerberos session may be used across client requests with things like curl. The following curl command can be used to request a directory listing from HDFS while authenticating with SPNEGO via the –negotiate flag</p>
+<pre><code>curl -k -i --negotiate -u https://localhost:8443/gateway/sandbox/webhdfs/v1/tmp?op=LISTSTATUS
+</code></pre><h3><a id="Preauthenticated+SSO+Provider">Preauthenticated SSO Provider</a> <a href="#Preauthenticated+SSO+Provider"><img src="markbook-section-link.png"/></a></h3><p>A number of SSO solutions provide mechanisms for federating an authenticated identity across applications. These mechanisms are at times simple HTTP Header type tokens that can be used to propagate the identity across process boundaries.</p><p>Knox Gateway needs a pluggable mechanism for consuming these tokens and federating the asserted identity through an interaction with the Hadoop cluster. </p><p><strong>CAUTION: The use of this provider requires that proper network security and identity provider configuration and deployment does not allow requests directly to the Knox gateway. Otherwise, this provider will leave the gateway exposed to identity spoofing.</strong></p><h4><a id="Configuration">Configuration</a> <a href="#Configuration"><img src="markbook-section-link.png"/></a></h4><h5><a id="Overview">O
verview</a> <a href="#Overview"><img src="markbook-section-link.png"/></a></h5><p>This provider was designed for use with identity solutions such as those provided by CA’s SiteMinder and IBM’s Tivoli Access Manager. While direct testing with these products has not been done, there has been extensive unit and functional testing that ensure that it should work with such providers.</p><p>The HeaderPreAuth provider is configured within the topology file and has a minimal configuration that assumes SM_USER for CA SiteMinder. The following example is the bare minimum configuration for SiteMinder (with no IP address validation).</p>
<pre><code><provider>
<role>federation</role>
<name>HeaderPreAuth</name>
Modified: knox/site/books/knox-0-9-1/user-guide.html
URL: http://svn.apache.org/viewvc/knox/site/books/knox-0-9-1/user-guide.html?rev=1767596&r1=1767595&r2=1767596&view=diff
==============================================================================
--- knox/site/books/knox-0-9-1/user-guide.html (original)
+++ knox/site/books/knox-0-9-1/user-guide.html Wed Nov 2 01:24:40 2016
@@ -2174,7 +2174,70 @@ APACHE_HOME/bin/apachectl -k stop
<td>DENY</td>
</tr>
</tbody>
-</table><h3><a id="Preauthenticated+SSO+Provider">Preauthenticated SSO Provider</a> <a href="#Preauthenticated+SSO+Provider"><img src="markbook-section-link.png"/></a></h3><p>A number of SSO solutions provide mechanisms for federating an authenticated identity across applications. These mechanisms are at times simple HTTP Header type tokens that can be used to propagate the identity across process boundaries.</p><p>Knox Gateway needs a pluggable mechanism for consuming these tokens and federating the asserted identity through an interaction with the Hadoop cluster. </p><p><strong>CAUTION: The use of this provider requires that proper network security and identity provider configuration and deployment does not allow requests directly to the Knox gateway. Otherwise, this provider will leave the gateway exposed to identity spoofing.</strong></p><h4><a id="Configuration">Configuration</a> <a href="#Configuration"><img src="markbook-section-link.png"/></a></h4><h5><a id="Overview">Overvi
ew</a> <a href="#Overview"><img src="markbook-section-link.png"/></a></h5><p>This provider was designed for use with identity solutions such as those provided by CA’s SiteMinder and IBM’s Tivoli Access Manager. While direct testing with these products has not been done, there has been extensive unit and functional testing that ensure that it should work with such providers.</p><p>The HeaderPreAuth provider is configured within the topology file and has a minimal configuration that assumes SM_USER for CA SiteMinder. The following example is the bare minimum configuration for SiteMinder (with no IP address validation).</p>
+</table><h3><a id="HadoopAuth+Authentication+Provider">HadoopAuth Authentication Provider</a> <a href="#HadoopAuth+Authentication+Provider"><img src="markbook-section-link.png"/></a></h3><p>The HadoopAuth authentication provider for Knox integrates the use of the Apache Hadoop module for SPNEGO and delegation token based authentication. This introduces the same authentication pattern used across much of the Hadoop ecosystem to Apache Knox and allows clients to using the strong authentication and SSO capabilities of Kerberos.</p><h4><a id="Configuration">Configuration</a> <a href="#Configuration"><img src="markbook-section-link.png"/></a></h4><h5><a id="Overview">Overview</a> <a href="#Overview"><img src="markbook-section-link.png"/></a></h5><p>As with all providers in the Knox gateway, the HadoopAuth provider is configured through provider params. The configuration parameters are the same parameters used within Apache Hadoop for the same capabilities. In this section, we provide an
example configuration and description of each of the parameters. We do encourage the reader to refer to the Hadoop documentation for this as well. (see <a href="http://hadoop.apache.org/docs/current/hadoop-auth/Configuration.html">http://hadoop.apache.org/docs/current/hadoop-auth/Configuration.html</a>)</p><p>One of the interesting things to note about this configuration is the use of the config.prefix parameter. In Hadoop there may be multiple components with their own specific configuration values for these parameters and since they may get mixed into the same Configuration object - there needs to be a way to identify the component specific values. The config.prefix parameter is used for this and is prepended to each of the configuration parameters for this provider. Below, you see an example configuration where the value for config.prefix happens to be ‘hadoop.auth.config’. You will also notice that this same value is prepended to the name of the rest of the configura
tion parameters.</p><p><provider> <role>authentication</role> <name>HadoopAuth</name> <enabled>true</enabled> <param> <name>config.prefix</name> <value>hadoop.auth.config</value> </param> <param> <name>hadoop.auth.config.signature.secret</name> <value>knox-signature-secret</value> </param> <param> <name>hadoop.auth.config.type</name> <value>kerberos</value> </param> <param> <name>hadoop.auth.config.simple.anonymous.allowed</name> <value>false</value> </param> <param> <name>hadoop.auth.config.token.validity</name> <value>1800</value> </param> <param> <name>hadoop.auth.config.cookie.domain</name> <value>novalocal</value> </param> <param> <name>hadoop.auth.config.cookie.path</name> <value>gateway/default</value> </param> <param> <name>hadoop.auth.config.kerberos.principal</name> <value>HTTP/lmccay<a href="mailto:-knoxft-24m-r6-sec-160422-13
2;7-2.novalocal@EXAMPLE.COM</value">-knoxft-24m-r6-sec-160422-1327-2.novalocal@EXAMPLE.COM</value</a> </param> <param> <name>hadoop.auth.config.kerberos.keytab</name> <value>/etc/security/keytabs/spnego.service.keytab</value> </param> <param> <name>hadoop.auth.config.kerberos.name.rules</name> <value>DEFAULT</value> </param> </provider></p><h4><a id="Descriptions">Descriptions</a> <a href="#Descriptions"><img src="markbook-section-link.png"/></a></h4><p>The following tables describes the configuration parameters for the HadoopAuth provider:</p><h6><a id="Config">Config</a> <a href="#Config"><img src="markbook-section-link.png"/></a></h6>
+<table>
+ <thead>
+ <tr>
+ <th>Name </th>
+ <th>Description </th>
+ <th>Default</th>
+ </tr>
+ </thead>
+ <tbody>
+ <tr>
+ <td>config.prefix</td>
+ <td>If specified, all other configuration parameter names must start with the prefix.</td>
+ <td>none</td>
+ </tr>
+ <tr>
+ <td>signature.secret</td>
+ <td>This is the secret used to sign the delegation token in the hadoop.auth cookie. This same secret needs to be used across all instances of the Knox gateway in a given cluster. Otherwise, the delegation token will fail validation and authentication will be repeated each request.</td>
+ <td>a simple random number</td>
+ </tr>
+ <tr>
+ <td>type</td>
+ <td>This parameter needs to be set to kerberos.</td>
+ <td>none, would throw exception</td>
+ </tr>
+ <tr>
+ <td>simple.anonymous.allowed</td>
+ <td>This should always be false for a secure deployment.</td>
+ <td>true</td>
+ </tr>
+ <tr>
+ <td>token.validity</td>
+ <td>The validity -in seconds- of the generated authentication token. This is also used for the rollover interval when signer.secret.provider is set to random or zookeeper.</td>
+ <td>36000 seconds</td>
+ </tr>
+ <tr>
+ <td>cookie.domain</td>
+ <td>domain to use for the HTTP cookie that stores the authentication token</td>
+ <td>null</td>
+ </tr>
+ <tr>
+ <td>cookie.path</td>
+ <td>path to use for the HTTP cookie that stores the authentication token</td>
+ <td>null</td>
+ </tr>
+ <tr>
+ <td>kerberos.principal</td>
+ <td>The web-application Kerberos principal name. The Kerberos principal name must start with HTTP/…. For example: HTTP/localhost@LOCALHOST</td>
+ <td>null</td>
+ </tr>
+ <tr>
+ <td>kerberos.keytab</td>
+ <td>The path to the keytab file containing the credentials for the kerberos principal. For example: /Users/lmccay/lmccay.keytab</td>
+ <td>null</td>
+ </tr>
+ <tr>
+ <td>kerberos.name.rules</td>
+ <td>The name of the ruleset for extracting the username from the kerberos principal.</td>
+ <td>DEFAULT</td>
+ </tr>
+ </tbody>
+</table><h6><a id="REST+Invocation">REST Invocation</a> <a href="#REST+Invocation"><img src="markbook-section-link.png"/></a></h6><p>Once a user logs in with kinit then their kerberos session may be used across client requests with things like curl. The following curl command can be used to request a directory listing from HDFS while authenticating with SPNEGO via the –negotiate flag</p>
+<pre><code>curl -k -i --negotiate -u https://localhost:8443/gateway/sandbox/webhdfs/v1/tmp?op=LISTSTATUS
+</code></pre><h3><a id="Preauthenticated+SSO+Provider">Preauthenticated SSO Provider</a> <a href="#Preauthenticated+SSO+Provider"><img src="markbook-section-link.png"/></a></h3><p>A number of SSO solutions provide mechanisms for federating an authenticated identity across applications. These mechanisms are at times simple HTTP Header type tokens that can be used to propagate the identity across process boundaries.</p><p>Knox Gateway needs a pluggable mechanism for consuming these tokens and federating the asserted identity through an interaction with the Hadoop cluster. </p><p><strong>CAUTION: The use of this provider requires that proper network security and identity provider configuration and deployment does not allow requests directly to the Knox gateway. Otherwise, this provider will leave the gateway exposed to identity spoofing.</strong></p><h4><a id="Configuration">Configuration</a> <a href="#Configuration"><img src="markbook-section-link.png"/></a></h4><h5><a id="Overview">O
verview</a> <a href="#Overview"><img src="markbook-section-link.png"/></a></h5><p>This provider was designed for use with identity solutions such as those provided by CA’s SiteMinder and IBM’s Tivoli Access Manager. While direct testing with these products has not been done, there has been extensive unit and functional testing that ensure that it should work with such providers.</p><p>The HeaderPreAuth provider is configured within the topology file and has a minimal configuration that assumes SM_USER for CA SiteMinder. The following example is the bare minimum configuration for SiteMinder (with no IP address validation).</p>
<pre><code><provider>
<role>federation</role>
<name>HeaderPreAuth</name>
Modified: knox/trunk/books/0.10.0/book_gateway-details.md
URL: http://svn.apache.org/viewvc/knox/trunk/books/0.10.0/book_gateway-details.md?rev=1767596&r1=1767595&r2=1767596&view=diff
==============================================================================
--- knox/trunk/books/0.10.0/book_gateway-details.md (original)
+++ knox/trunk/books/0.10.0/book_gateway-details.md Wed Nov 2 01:24:40 2016
@@ -91,6 +91,7 @@ In the Hortonworks Sandbox Ambari might
<<config_kerberos.md>>
<<config_ha.md>>
<<config_webappsec_provider.md>>
+<<config_hadoop_auth_provider.md>>
<<config_preauth_sso_provider.md>>
<<config_pac4j_provider.md>>
<<config_knox_sso.md>>
Modified: knox/trunk/books/0.9.0/book_gateway-details.md
URL: http://svn.apache.org/viewvc/knox/trunk/books/0.9.0/book_gateway-details.md?rev=1767596&r1=1767595&r2=1767596&view=diff
==============================================================================
--- knox/trunk/books/0.9.0/book_gateway-details.md (original)
+++ knox/trunk/books/0.9.0/book_gateway-details.md Wed Nov 2 01:24:40 2016
@@ -91,6 +91,7 @@ In the Hortonworks Sandbox Ambari might
<<config_kerberos.md>>
<<config_ha.md>>
<<config_webappsec_provider.md>>
+<<config_hadoop_auth_provider.md>>
<<config_preauth_sso_provider.md>>
<<config_pac4j_provider.md>>
<<config_knox_sso.md>>