knox-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From lmc...@apache.org
Subject 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
Date Wed, 02 Nov 2016 01:24:41 GMT
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&rsquo;s
SiteMinder and IBM&rsquo;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 &lsquo;hadoop.auth.config&rsquo;.
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:&#x2d;&#107;&#110;&#111;&#x78;&#x66;&#x74;&#45;&#50;&#52;&#x6d;&#x2d;&#114;&#54;-&#x73;e&#99;&#45;1&#x36;&#x30;&#x34;&#50;&#50;-&#49;&#51;&#x3
 2;7&#45;&#50;&#46;&#x6e;&#111;v&#97;loc&#97;&#x6c;&#x40;&#x45;X&#x41;MP&#76;&#69;&#46;&#67;O&#77;&#60;&#47;&#x76;&#x61;&#x6c;&#x75;&#101;">&#x2d;&#107;&#110;&#111;&#x78;&#x66;&#x74;&#45;&#50;&#52;&#x6d;&#x2d;&#114;&#54;-&#x73;e&#99;&#45;1&#x36;&#x30;&#x34;&#50;&#50;-&#49;&#51;&#x32;7&#45;&#50;&#46;&#x6e;&#111;v&#97;loc&#97;&#x6c;&#x40;&#x45;X&#x41;MP&#76;&#69;&#46;&#67;O&#77;&#60;&#47;&#x76;&#x61;&#x6c;&#x75;&#101;</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/&hellip;. 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 &ndash;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&rsquo;s
SiteMinder and IBM&rsquo;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>&lt;provider&gt;
     &lt;role&gt;federation&lt;/role&gt;
     &lt;name&gt;HeaderPreAuth&lt;/name&gt;

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&rsquo;s
SiteMinder and IBM&rsquo;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 &lsquo;hadoop.auth.config&rsquo;.
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:&#x2d;&#107;&#110;&#111;&#x78;&#x66;&#x74;&#45;&#50;&#52;&#x6d;&#x2d;&#114;&#54;-&#x73;e&#99;&#45;1&#x36;&#x30;&#x34;&#50;&#50;-&#49;&#51;&#x3
 2;7&#45;&#50;&#46;&#x6e;&#111;v&#97;loc&#97;&#x6c;&#x40;&#x45;X&#x41;MP&#76;&#69;&#46;&#67;O&#77;&#60;&#47;&#x76;&#x61;&#x6c;&#x75;&#101;">&#x2d;&#107;&#110;&#111;&#x78;&#x66;&#x74;&#45;&#50;&#52;&#x6d;&#x2d;&#114;&#54;-&#x73;e&#99;&#45;1&#x36;&#x30;&#x34;&#50;&#50;-&#49;&#51;&#x32;7&#45;&#50;&#46;&#x6e;&#111;v&#97;loc&#97;&#x6c;&#x40;&#x45;X&#x41;MP&#76;&#69;&#46;&#67;O&#77;&#60;&#47;&#x76;&#x61;&#x6c;&#x75;&#101;</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/&hellip;. 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 &ndash;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&rsquo;s
SiteMinder and IBM&rsquo;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>&lt;provider&gt;
     &lt;role&gt;federation&lt;/role&gt;
     &lt;name&gt;HeaderPreAuth&lt;/name&gt;

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>>



Mime
View raw message