knox-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From lmc...@apache.org
Subject svn commit: r1716878 - in /knox: site/ site/books/knox-0-7-0/ trunk/books/0.7.0/ trunk/books/0.7.0/dev-guide/
Date Fri, 27 Nov 2015 14:09:28 GMT
Author: lmccay
Date: Fri Nov 27 14:09:28 2015
New Revision: 1716878

URL: http://svn.apache.org/viewvc?rev=1716878&view=rev
Log:
added CORS docs to webappsec provider

Modified:
    knox/site/books/knox-0-7-0/knoxsso_integration.html
    knox/site/books/knox-0-7-0/user-guide.html
    knox/site/index.html
    knox/site/issue-tracking.html
    knox/site/license.html
    knox/site/mail-lists.html
    knox/site/project-info.html
    knox/site/team-list.html
    knox/trunk/books/0.7.0/config_webappsec_provider.md
    knox/trunk/books/0.7.0/dev-guide/knoxsso_integration.md

Modified: knox/site/books/knox-0-7-0/knoxsso_integration.html
URL: http://svn.apache.org/viewvc/knox/site/books/knox-0-7-0/knoxsso_integration.html?rev=1716878&r1=1716877&r2=1716878&view=diff
==============================================================================
--- knox/site/books/knox-0-7-0/knoxsso_integration.html (original)
+++ knox/site/books/knox-0-7-0/knoxsso_integration.html Fri Nov 27 14:09:28 2015
@@ -78,7 +78,6 @@
             <name>Default</name>
             <enabled>true</enabled>
         </provider>
-
     </gateway>
     
     <service>

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=1716878&r1=1716877&r2=1716878&view=diff
==============================================================================
--- knox/site/books/knox-0-7-0/user-guide.html (original)
+++ knox/site/books/knox-0-7-0/user-guide.html Fri Nov 27 14:09:28 2015
@@ -1864,7 +1864,7 @@ chmod 400 knox.service.keytab
 </ul><h6><a id="Start/stop+Apache+HTTP+Server">Start/stop Apache HTTP Server</a>
<a href="#Start/stop+Apache+HTTP+Server"><img src="markbook-section-link.png"/></a></h6>
 <pre><code>APACHE_HOME/bin/apachectl -k start
 APACHE_HOME/bin/apachectl -k stop
-</code></pre><h6><a id="Verify">Verify</a> <a href="#Verify"><img
src="markbook-section-link.png"/></a></h6><p>Use Knox samples.</p><h3><a
id="Web+App+Security+Provider">Web App Security Provider</a> <a href="#Web+App+Security+Provider"><img
src="markbook-section-link.png"/></a></h3><p>Knox is a Web API (REST)
Gateway for Hadoop. The fact that REST interactions are HTTP based means that they are vulnerable
to a number of web application security vulnerabilities. This project introduces a web application
security provider for plugging in various protection filters.</p><p>The initial
vulnerability protection filter will be for Cross Site Request Forgery (CSRF). Others will
be added in future releases.</p><p>Cross site request forgery (CSRF) attacks attempt
to force an authenticated user to execute functionality without their knowledge. By presenting
them with a link or image that when clicked invokes a request to another site with which the
user may have already established an active 
 session.</p><p>CSRF is entirely a browser based attack. Some background knowledge
of how browsers work enables us to provide a filter that will prevent CSRF attacks. HTTP requests
from a web browser performed via form, image, iframe, etc are unable to set custom HTTP headers.
The only way to create a HTTP request from a browser with a custom HTTP header is to use a
technology such as Javascript XMLHttpRequest or Flash. These technologies can set custom HTTP
headers, but have security policies built in to prevent web sites from sending requests to
each other unless specifically allowed by policy. </p><p>This means that a website
www.bad.com cannot send a request to <a href="http://bank.example.com">http://bank.example.com</a>
with the custom header X-XSRF-Header unless they use a technology such as a XMLHttpRequest.
That technology would prevent such a request from being made unless the bank.example.com domain
specifically allowed it. This then results in a REST endpoint that can onl
 y be called via XMLHttpRequest (or similar technology).</p><p>NOTE: by enabling
this protection within the gateway, this custom header will be required for <em>all</em>
clients that interact with it - not just browsers.</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 web app security provider is configured through
provider params. Unlike many other providers, the web app security provider may actually host
multiple vulnerability filters. Currently, we only have an implementation for CSRF but others
will follow and you may be interested in creating your own.</p><p>Because of this
one-to-many provider/filter relationship, there is an extra configuration element for this
provider per filter. As you can see in the sample below, the actual filter configuration is
define
 d entirely within the params of the WebAppSec provider.</p>
+</code></pre><h6><a id="Verify">Verify</a> <a href="#Verify"><img
src="markbook-section-link.png"/></a></h6><p>Use Knox samples.</p><h3><a
id="Web+App+Security+Provider">Web App Security Provider</a> <a href="#Web+App+Security+Provider"><img
src="markbook-section-link.png"/></a></h3><p>Knox is a Web API (REST)
Gateway for Hadoop. The fact that REST interactions are HTTP based means that they are vulnerable
to a number of web application security vulnerabilities. This project introduces a web application
security provider for plugging in various protection filters.</p><p>There are
two aspects of web application security that are handled now: Cross Site Request Forgery (CSRF)
and Cross Origin Resource Sharing. Others will be added in future releases.</p><h4><a
id="CSRF">CSRF</a> <a href="#CSRF"><img src="markbook-section-link.png"/></a></h4><p>Cross
site request forgery (CSRF) attacks attempt to force an authenticated user to execute functionality
without their knowledge. By presentin
 g them with a link or image that when clicked invokes a request to another site with which
the user may have already established an active session.</p><p>CSRF is entirely
a browser based attack. Some background knowledge of how browsers work enables us to provide
a filter that will prevent CSRF attacks. HTTP requests from a web browser performed via form,
image, iframe, etc are unable to set custom HTTP headers. The only way to create a HTTP request
from a browser with a custom HTTP header is to use a technology such as Javascript XMLHttpRequest
or Flash. These technologies can set custom HTTP headers, but have security policies built
in to prevent web sites from sending requests to each other unless specifically allowed by
policy. </p><p>This means that a website www.bad.com cannot send a request to
<a href="http://bank.example.com">http://bank.example.com</a> with the custom
header X-XSRF-Header unless they use a technology such as a XMLHttpRequest. That technology
would prevent s
 uch a request from being made unless the bank.example.com domain specifically allowed it.
This then results in a REST endpoint that can only be called via XMLHttpRequest (or similar
technology).</p><p>NOTE: by enabling this protection within the topology, this
custom header will be required for <em>all</em> clients that interact with it
- not just browsers.</p><h4><a id="CORS">CORS</a> <a href="#CORS"><img
src="markbook-section-link.png"/></a></h4><p>For security reasons, browsers
restrict cross-origin HTTP requests initiated from within scripts. For example, XMLHttpRequest
follows the same-origin policy. So, a web application using XMLHttpRequest could only make
HTTP requests to its own domain. To improve web applications, developers asked browser vendors
to allow XMLHttpRequest to make cross-domain requests.</p><p>Cross Origin Resource
Sharing is a way to explicitly alter the same-origin policy for a given application or API.
In order to allow for applications to make cross domain
  requests through Apache Knox, we need to configure the CORS filter of the WebAppSec provider.</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 web app security provider is configured through
provider params. Unlike many other providers, the web app security provider may actually host
multiple vulnerability/security filters. Currently, we only have implementations for CSRF
and CORS but others will follow and you may be interested in creating your own.</p><p>Because
of this one-to-many provider/filter relationship, there is an extra configuration element
for this provider per filter. As you can see in the sample below, the actual filter configuration
is defined entirely within the params of the WebAppSec provider.</p>
 <pre><code>&lt;provider&gt;
   &lt;role&gt;webappsec&lt;/role&gt;
   &lt;name&gt;WebAppSec&lt;/name&gt;
@@ -1872,8 +1872,9 @@ APACHE_HOME/bin/apachectl -k stop
   &lt;param&gt;&lt;name&gt;csrf.enabled&lt;/name&gt;&lt;value&gt;true&lt;/value&gt;&lt;/param&gt;
   &lt;param&gt;&lt;name&gt;csrf.customHeader&lt;/name&gt;&lt;value&gt;X-XSRF-Header&lt;/value&gt;&lt;/param&gt;
   &lt;param&gt;&lt;name&gt;csrf.methodsToIgnore&lt;/name&gt;&lt;value&gt;GET,OPTIONS,HEAD&lt;/value&gt;&lt;/param&gt;
+  &lt;param&gt;&lt;name&gt;cors.enabled&lt;/name&gt;&lt;value&gt;true&lt;/value&gt;&lt;/param&gt;
 &lt;/provider&gt;
-</code></pre><h4><a id="Descriptions">Descriptions</a> <a
href="#Descriptions"><img src="markbook-section-link.png"/></a></h4><p>The
following table describes the configuration options for the web app security provider:</p>
+</code></pre><h4><a id="Descriptions">Descriptions</a> <a
href="#Descriptions"><img src="markbook-section-link.png"/></a></h4><p>The
following tables describes the configuration options for the web app security provider:</p><h5><a
id="CSRF">CSRF</a> <a href="#CSRF"><img src="markbook-section-link.png"/></a></h5><h6><a
id="Config">Config</a> <a href="#Config"><img src="markbook-section-link.png"/></a></h6>
 <table>
   <thead>
     <tr>
@@ -1899,9 +1900,49 @@ APACHE_HOME/bin/apachectl -k stop
       <td>GET,OPTIONS,HEAD</td>
     </tr>
   </tbody>
-</table><h4><a id="REST+Invocation">REST Invocation</a> <a href="#REST+Invocation"><img
src="markbook-section-link.png"/></a></h4><p>The following curl command
can be used to request a directory listing from HDFS while passing in the expected header
X-XSRF-Header.</p>
+</table><h6><a id="REST+Invocation">REST Invocation</a> <a href="#REST+Invocation"><img
src="markbook-section-link.png"/></a></h6><p>The following curl command
can be used to request a directory listing from HDFS while passing in the expected header
X-XSRF-Header.</p>
 <pre><code>curl -k -i --header &quot;X-XSRF-Header: valid&quot; -v -u
guest:guest-password https://localhost:8443/gateway/sandbox/webhdfs/v1/tmp?op=LISTSTATUS
-</code></pre><p>Omitting the &ndash;header &ldquo;X-XSRF-Header:
valid&rdquo; above should result in an HTTP 400 bad_request.</p><p>Disabling
the provider will then allow a request that is missing the header through. </p><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 prov
 ider 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">Overview</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>
+</code></pre><p>Omitting the &ndash;header &ldquo;X-XSRF-Header:
valid&rdquo; above should result in an HTTP 400 bad_request.</p><p>Disabling
the provider will then allow a request that is missing the header through. </p><h5><a
id="CORS">CORS</a> <a href="#CORS"><img src="markbook-section-link.png"/></a></h5><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>cors.enabled</td>
+      <td>This param enables the CORS capabilities</td>
+      <td>false</td>
+    </tr>
+    <tr>
+      <td>cors.allowGenericHttpRequests</td>
+      <td>{true|false} defaults to true. If true generic HTTP requests will be allowed
to pass through the filter, else only valid and accepted CORS requests will be allowed (strict
CORS filtering).</td>
+      <td>true</td>
+    </tr>
+    <tr>
+      <td>cors.allowOrigin</td>
+      <td>{&ldquo;*&rdquo;|origin-list} defaults to &ldquo;*&rdquo;.
Whitespace-separated list of origins that the CORS filter must allow. Requests from origins
not included here will be refused with an HTTP 403 &ldquo;Forbidden&rdquo; response.
If set to * (asterisk) any origin will be allowed.</td>
+      <td>&ldquo;*&rdquo;</td>
+    </tr>
+    <tr>
+      <td>cors.allowSubdomains</td>
+      <td>{true|false} defaults to false. If true the CORS filter will allow requests
from any origin which is a subdomain origin of the allowed origins. A subdomain is matched
by comparing its scheme and suffix (host name / IP address and optional port number).</td>
+      <td>false</td>
+    </tr>
+    <tr>
+      <td>cors.supportedMethods</td>
+      <td>{method-list} defaults to &ldquo;GET, POST, HEAD, OPTIONS&rdquo;.
List of the supported HTTP methods. These are advertised through the Access-Control-Allow-Methods
header and must also be implemented by the actual CORS web service. Requests for methods not
included here will be refused by the CORS filter with an HTTP 405 &ldquo;Method not allowed&rdquo;
response.</td>
+      <td>&ldquo;GET, POST, HEAD, OPTIONS&rdquo;</td>
+    </tr>
+    <tr>
+      <td>cors.supportedHeaders </td>
+      <td>{&quot;*&quot;|header-list} defaults to *. The names of the supported
author request headers. These are advertised through the Access-Control-Allow-Headers header.
If the configuration property value is set to * (asterisk) any author request header will
be allowed. The CORS Filter implements this by simply echoing the requested value back to
the browser. What is an author request header? This any custom header set by the browser JavaScript
application through the XMLHttpRequest.setRequestHeader() method.|&ldquo;*&rdquo;
cors.exposedHeaders | {header-list} defaults to empty list. List of the response headers other
than simple response headers that the browser should expose to the author of the cross-domain
request through the XMLHttpRequest.getResponseHeader() method. The CORS filter supplies this
information through the Access-Control-Expose-Headers header.| empty cors.supportsCredentials
| {true|false} defaults to true. Indicates whether user credentials, such as cookies,
  HTTP authentication or client-side certificates, are supported. The CORS filter uses this
value in constructing the Access-Control-Allow-Credentials header.|true cors.maxAge | {int}
defaults to -1 (unspecified). Indicates how long the results of a preflight request can be
cached by the web browser, in seconds. If -1 unspecified. This information is passed to the
browser via the Access-Control-Max-Age header.| -1 cors.tagRequests| {true|false} defaults
to false (no tagging). Enables HTTP servlet request tagging to provide CORS information to
downstream handlers (filters and/or servlets).| false</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>
 <pre><code>&lt;provider&gt;
   &lt;role&gt;federation&lt;/role&gt;
   &lt;name&gt;HeaderPreAuth&lt;/name&gt;

Modified: knox/site/index.html
URL: http://svn.apache.org/viewvc/knox/site/index.html?rev=1716878&r1=1716877&r2=1716878&view=diff
==============================================================================
--- knox/site/index.html (original)
+++ knox/site/index.html Fri Nov 27 14:09:28 2015
@@ -1,13 +1,13 @@
 <!DOCTYPE html>
 <!--
- | Generated by Apache Maven Doxia at 2015-11-14
+ | Generated by Apache Maven Doxia at 2015-11-27
  | Rendered using Apache Maven Fluido Skin 1.3.0
 -->
 <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
   <head>
     <meta charset="UTF-8" />
     <meta name="viewport" content="width=device-width, initial-scale=1.0" />
-    <meta name="Date-Revision-yyyymmdd" content="20151114" />
+    <meta name="Date-Revision-yyyymmdd" content="20151127" />
     <meta http-equiv="Content-Language" content="en" />
     <title>Knox Gateway &#x2013; REST API Gateway for the Hadoop Ecosystem</title>
     <link rel="stylesheet" href="./css/apache-maven-fluido-1.3.0.min.css" />
@@ -58,7 +58,7 @@
               
                 
                     
-                  <li id="publishDate" class="pull-right">Last Published: 2015-11-14</li>

+                  <li id="publishDate" class="pull-right">Last Published: 2015-11-27</li>

             
                             </ul>
       </div>

Modified: knox/site/issue-tracking.html
URL: http://svn.apache.org/viewvc/knox/site/issue-tracking.html?rev=1716878&r1=1716877&r2=1716878&view=diff
==============================================================================
--- knox/site/issue-tracking.html (original)
+++ knox/site/issue-tracking.html Fri Nov 27 14:09:28 2015
@@ -1,13 +1,13 @@
 <!DOCTYPE html>
 <!--
- | Generated by Apache Maven Doxia at 2015-11-14
+ | Generated by Apache Maven Doxia at 2015-11-27
  | Rendered using Apache Maven Fluido Skin 1.3.0
 -->
 <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
   <head>
     <meta charset="UTF-8" />
     <meta name="viewport" content="width=device-width, initial-scale=1.0" />
-    <meta name="Date-Revision-yyyymmdd" content="20151114" />
+    <meta name="Date-Revision-yyyymmdd" content="20151127" />
     <meta http-equiv="Content-Language" content="en" />
     <title>Knox Gateway &#x2013; Issue Tracking</title>
     <link rel="stylesheet" href="./css/apache-maven-fluido-1.3.0.min.css" />
@@ -58,7 +58,7 @@
               
                 
                     
-                  <li id="publishDate" class="pull-right">Last Published: 2015-11-14</li>

+                  <li id="publishDate" class="pull-right">Last Published: 2015-11-27</li>

             
                             </ul>
       </div>

Modified: knox/site/license.html
URL: http://svn.apache.org/viewvc/knox/site/license.html?rev=1716878&r1=1716877&r2=1716878&view=diff
==============================================================================
--- knox/site/license.html (original)
+++ knox/site/license.html Fri Nov 27 14:09:28 2015
@@ -1,13 +1,13 @@
 <!DOCTYPE html>
 <!--
- | Generated by Apache Maven Doxia at 2015-11-14
+ | Generated by Apache Maven Doxia at 2015-11-27
  | Rendered using Apache Maven Fluido Skin 1.3.0
 -->
 <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
   <head>
     <meta charset="UTF-8" />
     <meta name="viewport" content="width=device-width, initial-scale=1.0" />
-    <meta name="Date-Revision-yyyymmdd" content="20151114" />
+    <meta name="Date-Revision-yyyymmdd" content="20151127" />
     <meta http-equiv="Content-Language" content="en" />
     <title>Knox Gateway &#x2013; Project License</title>
     <link rel="stylesheet" href="./css/apache-maven-fluido-1.3.0.min.css" />
@@ -58,7 +58,7 @@
               
                 
                     
-                  <li id="publishDate" class="pull-right">Last Published: 2015-11-14</li>

+                  <li id="publishDate" class="pull-right">Last Published: 2015-11-27</li>

             
                             </ul>
       </div>

Modified: knox/site/mail-lists.html
URL: http://svn.apache.org/viewvc/knox/site/mail-lists.html?rev=1716878&r1=1716877&r2=1716878&view=diff
==============================================================================
--- knox/site/mail-lists.html (original)
+++ knox/site/mail-lists.html Fri Nov 27 14:09:28 2015
@@ -1,13 +1,13 @@
 <!DOCTYPE html>
 <!--
- | Generated by Apache Maven Doxia at 2015-11-14
+ | Generated by Apache Maven Doxia at 2015-11-27
  | Rendered using Apache Maven Fluido Skin 1.3.0
 -->
 <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
   <head>
     <meta charset="UTF-8" />
     <meta name="viewport" content="width=device-width, initial-scale=1.0" />
-    <meta name="Date-Revision-yyyymmdd" content="20151114" />
+    <meta name="Date-Revision-yyyymmdd" content="20151127" />
     <meta http-equiv="Content-Language" content="en" />
     <title>Knox Gateway &#x2013; Project Mailing Lists</title>
     <link rel="stylesheet" href="./css/apache-maven-fluido-1.3.0.min.css" />
@@ -58,7 +58,7 @@
               
                 
                     
-                  <li id="publishDate" class="pull-right">Last Published: 2015-11-14</li>

+                  <li id="publishDate" class="pull-right">Last Published: 2015-11-27</li>

             
                             </ul>
       </div>

Modified: knox/site/project-info.html
URL: http://svn.apache.org/viewvc/knox/site/project-info.html?rev=1716878&r1=1716877&r2=1716878&view=diff
==============================================================================
--- knox/site/project-info.html (original)
+++ knox/site/project-info.html Fri Nov 27 14:09:28 2015
@@ -1,13 +1,13 @@
 <!DOCTYPE html>
 <!--
- | Generated by Apache Maven Doxia at 2015-11-14
+ | Generated by Apache Maven Doxia at 2015-11-27
  | Rendered using Apache Maven Fluido Skin 1.3.0
 -->
 <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
   <head>
     <meta charset="UTF-8" />
     <meta name="viewport" content="width=device-width, initial-scale=1.0" />
-    <meta name="Date-Revision-yyyymmdd" content="20151114" />
+    <meta name="Date-Revision-yyyymmdd" content="20151127" />
     <meta http-equiv="Content-Language" content="en" />
     <title>Knox Gateway &#x2013; Project Information</title>
     <link rel="stylesheet" href="./css/apache-maven-fluido-1.3.0.min.css" />
@@ -58,7 +58,7 @@
               
                 
                     
-                  <li id="publishDate" class="pull-right">Last Published: 2015-11-14</li>

+                  <li id="publishDate" class="pull-right">Last Published: 2015-11-27</li>

             
                             </ul>
       </div>

Modified: knox/site/team-list.html
URL: http://svn.apache.org/viewvc/knox/site/team-list.html?rev=1716878&r1=1716877&r2=1716878&view=diff
==============================================================================
--- knox/site/team-list.html (original)
+++ knox/site/team-list.html Fri Nov 27 14:09:28 2015
@@ -1,13 +1,13 @@
 <!DOCTYPE html>
 <!--
- | Generated by Apache Maven Doxia at 2015-11-14
+ | Generated by Apache Maven Doxia at 2015-11-27
  | Rendered using Apache Maven Fluido Skin 1.3.0
 -->
 <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
   <head>
     <meta charset="UTF-8" />
     <meta name="viewport" content="width=device-width, initial-scale=1.0" />
-    <meta name="Date-Revision-yyyymmdd" content="20151114" />
+    <meta name="Date-Revision-yyyymmdd" content="20151127" />
     <meta http-equiv="Content-Language" content="en" />
     <title>Knox Gateway &#x2013; Team list</title>
     <link rel="stylesheet" href="./css/apache-maven-fluido-1.3.0.min.css" />
@@ -58,7 +58,7 @@
               
                 
                     
-                  <li id="publishDate" class="pull-right">Last Published: 2015-11-14</li>

+                  <li id="publishDate" class="pull-right">Last Published: 2015-11-27</li>

             
                             </ul>
       </div>

Modified: knox/trunk/books/0.7.0/config_webappsec_provider.md
URL: http://svn.apache.org/viewvc/knox/trunk/books/0.7.0/config_webappsec_provider.md?rev=1716878&r1=1716877&r2=1716878&view=diff
==============================================================================
--- knox/trunk/books/0.7.0/config_webappsec_provider.md (original)
+++ knox/trunk/books/0.7.0/config_webappsec_provider.md Fri Nov 27 14:09:28 2015
@@ -18,8 +18,9 @@
 ### Web App Security Provider ###
 Knox is a Web API (REST) Gateway for Hadoop. The fact that REST interactions are HTTP based
means that they are vulnerable to a number of web application security vulnerabilities. This
project introduces a web application security provider for plugging in various protection
filters.
 
-The initial vulnerability protection filter will be for Cross Site Request Forgery (CSRF).
Others will be added in future releases.
- 
+There are two aspects of web application security that are handled now: Cross Site Request
Forgery (CSRF) and Cross Origin Resource Sharing. Others will be added in future releases.
+
+#### CSRF
 Cross site request forgery (CSRF) attacks attempt to force an authenticated user to 
 execute functionality without their knowledge. By presenting them with a link or image that
when clicked invokes a request to another site with which the user may have already established
an active session.
 
@@ -28,12 +29,17 @@ unless specifically allowed by policy.
 
 This means that a website www.bad.com cannot send a request to  http://bank.example.com with
the custom header X-XSRF-Header unless they use a technology such as a XMLHttpRequest. That
technology  would prevent such a request from being made unless the bank.example.com domain
specifically allowed it. This then results in a REST endpoint that can only be called via
XMLHttpRequest (or similar technology).
 
-NOTE: by enabling this protection within the gateway, this custom header will be required
for *all* clients that interact with it - not just browsers.
+NOTE: by enabling this protection within the topology, this custom header will be required
for *all* clients that interact with it - not just browsers.
+
+#### CORS
+For security reasons, browsers restrict cross-origin HTTP requests initiated from within
scripts.  For example, XMLHttpRequest follows the same-origin policy. So, a web application
using XMLHttpRequest could only make HTTP requests to its own domain. To improve web applications,
developers asked browser vendors to allow XMLHttpRequest to make cross-domain requests.
+
+Cross Origin Resource Sharing is a way to explicitly alter the same-origin policy for a given
application or API. In order to allow for applications to make cross domain requests through
Apache Knox, we need to configure the CORS filter of the WebAppSec provider.
 
 
 #### Configuration ####
 ##### Overview #####
-As with all providers in the Knox gateway, the web app security provider is configured through
provider params. Unlike many other providers, the web app security provider may actually host
multiple vulnerability filters. Currently, we only have an implementation for CSRF but others
will follow and you may be interested in creating your own.
+As with all providers in the Knox gateway, the web app security provider is configured through
provider params. Unlike many other providers, the web app security provider may actually host
multiple vulnerability/security filters. Currently, we only have implementations for CSRF
and CORS but others will follow and you may be interested in creating your own.
 
 Because of this one-to-many provider/filter relationship, there is an extra configuration
element for this provider per filter. As you can see in the sample below, the actual filter
configuration is defined entirely within the params of the WebAppSec provider.
 
@@ -44,10 +50,15 @@ Because of this one-to-many provider/fil
 	  <param><name>csrf.enabled</name><value>true</value></param>
 	  <param><name>csrf.customHeader</name><value>X-XSRF-Header</value></param>
 	  <param><name>csrf.methodsToIgnore</name><value>GET,OPTIONS,HEAD</value></param>
+	  <param><name>cors.enabled</name><value>true</value></param>
 	</provider>
 
 #### Descriptions ####
-The following table describes the configuration options for the web app security provider:
+The following tables describes the configuration options for the web app security provider:
+
+##### CSRF
+
+###### Config
 
 Name | Description | Default
 ---------|-----------
@@ -55,7 +66,7 @@ csrf.enabled|This param enables the CSRF
 csrf.customHeader|This is an optional param that indicates the name of the header to be used
in order to determine that the request is from a trusted source. It defaults to the header
name described by the NSA in its guidelines for dealing with CSRF in REST.|X-XSRF-Header
 csrf.methodsToIgnore|This is also an optional param that enumerates the HTTP methods to allow
through without the custom HTTP header. This is useful for allowing things like GET requests
from the URL bar of a browser but it assumes that the GET request adheres to REST principals
in terms of being idempotent. If this cannot be assumed then it would be wise to not include
GET in the list of methods to ignore.|GET,OPTIONS,HEAD
 
-#### REST Invocation
+###### REST Invocation
 The following curl command can be used to request a directory listing from HDFS while passing
in the expected header X-XSRF-Header.
 
 	curl -k -i --header "X-XSRF-Header: valid" -v -u guest:guest-password https://localhost:8443/gateway/sandbox/webhdfs/v1/tmp?op=LISTSTATUS
@@ -64,3 +75,20 @@ Omitting the --header "X-XSRF-Header: va
 
 Disabling the provider will then allow a request that is missing the header through. 
 
+##### CORS
+
+###### Config
+
+Name | Description | Default
+---------|-----------
+cors.enabled|This param enables the CORS capabilities|false
+cors.allowGenericHttpRequests|{true\|false} defaults to true. If true generic HTTP requests
will be allowed to pass through the filter, else only valid and accepted CORS requests will
be allowed (strict CORS filtering).|true
+cors.allowOrigin|{"\*"\|origin-list} defaults to "\*". Whitespace-separated list of origins
that the CORS filter must allow. Requests from origins not included here will be refused with
an HTTP 403 "Forbidden" response. If set to * (asterisk) any origin will be allowed.|"\*"
+cors.allowSubdomains|{true\|false} defaults to false. If true the CORS filter will allow
requests from any origin which is a subdomain origin of the allowed origins. A subdomain is
matched by comparing its scheme and suffix (host name / IP address and optional port number).|false
+cors.supportedMethods|{method-list} defaults to "GET, POST, HEAD, OPTIONS". List of the supported
HTTP methods. These are advertised through the Access-Control-Allow-Methods header and must
also be implemented by the actual CORS web service. Requests for methods not included here
will be refused by the CORS filter with an HTTP 405 "Method not allowed" response.| "GET,
POST, HEAD, OPTIONS"
+cors.supportedHeaders |{"*"\|header-list} defaults to *. The names of the supported author
request headers. These are advertised through the Access-Control-Allow-Headers header. If
the configuration property value is set to * (asterisk) any author request header will be
allowed. The CORS Filter implements this by simply echoing the requested value back to the
browser. What is an author request header? This any custom header set by the browser JavaScript
application through the XMLHttpRequest.setRequestHeader() method.|"\*"
+cors.exposedHeaders | {header-list} defaults to empty list. List of the response headers
other than simple response headers that the browser should expose to the author of the cross-domain
request through the XMLHttpRequest.getResponseHeader() method. The CORS filter supplies this
information through the Access-Control-Expose-Headers header.| empty
+cors.supportsCredentials | {true\|false} defaults to true. Indicates whether user credentials,
such as cookies, HTTP authentication or client-side certificates, are supported. The CORS
filter uses this value in constructing the Access-Control-Allow-Credentials header.|true
+cors.maxAge | {int} defaults to -1 (unspecified). Indicates how long the results of a preflight
request can be cached by the web browser, in seconds. If -1 unspecified. This information
is passed to the browser via the Access-Control-Max-Age header.| -1
+cors.tagRequests| {true\|false} defaults to false (no tagging). Enables HTTP servlet request
tagging to provide CORS information to downstream handlers (filters and/or servlets).| false
+

Modified: knox/trunk/books/0.7.0/dev-guide/knoxsso_integration.md
URL: http://svn.apache.org/viewvc/knox/trunk/books/0.7.0/dev-guide/knoxsso_integration.md?rev=1716878&r1=1716877&r2=1716878&view=diff
==============================================================================
--- knox/trunk/books/0.7.0/dev-guide/knoxsso_integration.md (original)
+++ knox/trunk/books/0.7.0/dev-guide/knoxsso_integration.md Fri Nov 27 14:09:28 2015
@@ -107,7 +107,6 @@ In order to see the end to end story and
             <name>Default</name>
             <enabled>true</enabled>
         </provider>
-
     </gateway>
     
     <service>



Mime
View raw message