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 2014/02/19 03:26:25 UTC
svn commit: r1569613 - in /incubator/knox: site/books/knox-incubating-0-4-0/
trunk/books/0.4.0/
Author: lmccay
Date: Wed Feb 19 02:26:24 2014
New Revision: 1569613
URL: http://svn.apache.org/r1569613
Log:
adding preauthenticated sso provider documentation
Added:
incubator/knox/trunk/books/0.4.0/config_preauth_sso_provider.md
incubator/knox/trunk/books/0.4.0/config_webappsec_provider.md
Modified:
incubator/knox/site/books/knox-incubating-0-4-0/knox-incubating-0-4-0.html
incubator/knox/trunk/books/0.4.0/book.md
incubator/knox/trunk/books/0.4.0/book_gateway-details.md
Modified: incubator/knox/site/books/knox-incubating-0-4-0/knox-incubating-0-4-0.html
URL: http://svn.apache.org/viewvc/incubator/knox/site/books/knox-incubating-0-4-0/knox-incubating-0-4-0.html?rev=1569613&r1=1569612&r2=1569613&view=diff
==============================================================================
--- incubator/knox/site/books/knox-incubating-0-4-0/knox-incubating-0-4-0.html (original)
+++ incubator/knox/site/books/knox-incubating-0-4-0/knox-incubating-0-4-0.html Wed Feb 19 02:26:24 2014
@@ -36,6 +36,8 @@
<li><a href="#Authorization">Authorization</a></li>
<li><a href="#Secure+Clusters">Secure Clusters</a></li>
<li><a href="#High+Availability">High Availability</a></li>
+ <li><a href="#Web+App+Security+Provider">Web App Security Provider</a></li>
+ <li><a href="#Preauthenticated+SSO+Provider">Preauthenticated SSO Provider</a></li>
</ul></li>
<li><a href="#Client+Details">Client Details</a></li>
<li><a href="#Service+Details">Service Details</a>
@@ -1077,7 +1079,105 @@ chmod 400 knox.service.keytab
</ul><h6><a id="Start/stop+Apache+HTTP+Server"></a>Start/stop Apache HTTP Server</h6>
<pre><code>APACHE_HOME/bin/apachectl -k start
APACHE_HOME/bin/apachectl -k stop
-</code></pre><h6><a id="Verify"></a>Verify</h6><p>Use Knox samples.</p><h2><a id="Client+Details"></a>Client Details</h2><p>Hadoop requires a client that can be used to interact remotely with the services provided by Hadoop cluster. This will also be true when using the Apache Knox Gateway to provide perimeter security and centralized access for these services. The two primary existing clients for Hadoop are the CLI (i.e. Command Line Interface, hadoop) and HUE (i.e. Hadoop User Environment). For several reasons however, neither of these clients can <em>currently</em> be used to access Hadoop services via the Apache Knox Gateway.</p><p>This led to thinking about a very simple client that could help people use and evaluate the gateway. The list below outlines the general requirements for such a client.</p>
+</code></pre><h6><a id="Verify"></a>Verify</h6><p>Use Knox samples.</p><h3><a id="Web+App+Security+Provider"></a>Web App Security Provider</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 wi
ll 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 only be called via XMLHttpRequest (or similar technology).</p><p>NOTE: by enabling this protection within the gateway, this custom header will b
e required for <em>all</em> clients that interact with it - not just browsers.</p><h4><a id="Configuration"></a>Configuration</h4><h5><a id="Overview"></a>Overview</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 defined entirely within the params of the WebAppSec provider.</p>
+<pre><code><provider
+ <role>webappsec</role>
+ <name>WebAppSec</name>
+ <enabled>true</enabled>
+ <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>
+</provider>
+</code></pre><h4><a id="Descriptions"></a>Descriptions</h4><p>The following table describes the configuration options for the web app security provider:</p>
+<table>
+ <thead>
+ <tr>
+ <th>Name </th>
+ <th>Description </th>
+ <th>Default</th>
+ </tr>
+ </thead>
+ <tbody>
+ <tr>
+ <td>csrf.enabled</td>
+ <td>This param enables the CSRF protection capabilities</td>
+ <td>false</td>
+ </tr>
+ <tr>
+ <td>csrf.customHeader</td>
+ <td>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.</td>
+ <td>X_XSRF_Header</td>
+ </tr>
+ <tr>
+ <td>csrf.methodsToIgnore</td>
+ <td>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.</td>
+ <td>GET,OPTIONS,HEAD</td>
+ </tr>
+ </tbody>
+</table><h4><a id="REST+Invocation"></a>REST Invocation</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>
+<pre><code>curl -k -i --header "X-XSRF-Header: oihdfgilhsdog" -v -u guest:guest-password https://localhost:8443/gateway/sandbox/webhdfs/v1/tmp?op=LISTSTATUS
+</code></pre><p>Omitting the –header “X-XSRF-Header: oihdfgilhsdog” above should result in an HTTP 400 bad_request or a 403 forbidden.</p><p>Disabling the provider will then allow a request that is missing the header through. </p><h3><a id="Preauthenticated+SSO+Provider"></a>Preauthenticated SSO Provider</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>
+<pre><code>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.
+</code></pre><h4><a id="Configuration"></a>Configuration</h4><h5><a id="Overview"></a>Overview</h5><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>
+ <enabled>true</enabled>
+</provider>
+</code></pre><p>The following table describes the configuration options for the web app security provider:</p><h5><a id="Descriptions"></a>Descriptions</h5>
+<table>
+ <thead>
+ <tr>
+ <th>Name </th>
+ <th>Description </th>
+ <th>Default</th>
+ </tr>
+ </thead>
+ <tbody>
+ <tr>
+ <td>preauth.validation.method</td>
+ <td>Optional parameter that indicates the type of trust validation to perform on incoming requests. Possible values are: null, preauth.ip.validation (others will be added in future releases). Failure results in a 403 forbidden HTTP status response.</td>
+ <td>null - which means no validation will be performed and that we are assuming that the network security and external authentication system is sufficient.</td>
+ </tr>
+ <tr>
+ <td>preauth.ip.addresses</td>
+ <td>Optional parameter that indicates the list of trusted ip addresses. When preauth.ip.validation is indicated as the validation method this parameter must be provided to indicate the trusted ip address set. Wildcarded IPs may be used to indicate subnet level trust. ie. 127.0.*</td>
+ <td>null - which means that no validation will be performed.</td>
+ </tr>
+ <tr>
+ <td>preauth.custom.header</td>
+ <td>Required parameter for indicating a custom header to use for extracting the preauthenticated principal. The value extracted from this header is utilized as the PrimaryPrincipal within the established Subject. An incoming request that is missing the configured header will be refused with a 401 unauthorized HTTP status.</td>
+ <td>SM_USER for SiteMinder usecase</td>
+ </tr>
+ <tr>
+ <td>preauth.custom.group.header</td>
+ <td>Optional parameter for indicating a HTTP header name that contains a comma separated list of groups. These are added to the authenticated Subject as group principals. A missing group header will result in no groups being extracted from the incoming request and a log entry but processing will continue.</td>
+ <td>null - which means that there will be no group principals extracted from the request and added to the established Subject.</td>
+ </tr>
+ </tbody>
+</table><h5><a id="Configuration+for+SiteMinder"></a>Configuration for SiteMinder</h5><p>The following is an example of a configuration of the preauthenticated sso provider that leverages the default SM_USER header name - assuming use with CA SiteMinder. It further configures the validation based on the IP address from the incoming request.</p>
+<pre><code><provider>
+ <role>federation</role>
+ <name>HeaderPreAuth</name>
+ <enabled>true</enabled>
+ <param><name>preauth.validation.method</name><value>preauth.ip.validation</value></param>
+ <param><name>preauth.ip.addresses</name><value>127.0.0.2,127.0.0.1</value></param>
+</provider>
+</code></pre><h5><a id="REST+Invocation+for+SiteMinder"></a>REST Invocation for SiteMinder</h5><p>The following curl command can be used to request a directory listing from HDFS while passing in the expected header SM_USER.</p>
+<pre><code>curl -k -i --header "SM_USER: guest" -v https://localhost:8443/gateway/sandbox/webhdfs/v1/tmp?op=LISTSTATUS
+</code></pre><p>Omitting the –header “SM_USER: guest” above will result in a rejected request.</p><h5><a id="Configuration+for+IBM+Tivoli+AM"></a>Configuration for IBM Tivoli AM</h5><p>As an example for configuring the preauthenticated sso provider for another SSO provider, the following illustrates the values used for IBM’s Tivoli Access Manager:</p>
+<pre><code><provider>
+ <role>federation</role>
+ <name>HeaderPreAuth</name>
+ <enabled>true</enabled>
+ <param><name>preauth.custom.header</name><value>iv_user</value></param>
+ <param><name>preauth.custom.group.header</name><value>iv_group</value></param>
+ <param><name>preauth.validation.method</name><value>preauth.ip.validation</value></param>
+ <param><name>preauth.ip.addresses</name><value>127.0.0.2,127.0.0.1</value></param>
+</provider>
+</code></pre><h5><a id="REST+Invocation+for+Tivoli+AM"></a>REST Invocation for Tivoli AM</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><h2><a id="Client+Details"></a>Client Details</h2><p>Hadoop requires a client that can be used to interact remotely with the services provided by Hadoop cluster. This will also be true when using the Apache Knox Gateway to provide perimeter security and centralized access for these services. The two primary existing clients for Hadoop are the CLI (i.e. Command Line Interface, hadoop) and HUE (i.e. Hadoop User Environment). For several reasons however, neither of these clients can <em>currently</em> be used to access Hadoop services via the Apache Knox Gateway.</p><p>This led to thinking about a very simple client that could help people use and evaluate the gateway. The list below outlines the general requirements for such a client.</p>
<ul>
<li>Promote the evaluation and adoption of the Apache Knox Gateway</li>
<li>Simple to deploy and use on data worker desktops to access to remote Hadoop clusters</li>
Modified: incubator/knox/trunk/books/0.4.0/book.md
URL: http://svn.apache.org/viewvc/incubator/knox/trunk/books/0.4.0/book.md?rev=1569613&r1=1569612&r2=1569613&view=diff
==============================================================================
--- incubator/knox/trunk/books/0.4.0/book.md (original)
+++ incubator/knox/trunk/books/0.4.0/book.md Wed Feb 19 02:26:24 2014
@@ -43,6 +43,8 @@
* #[Authorization]
* #[Secure Clusters]
* #[High Availability]
+ * #[Web App Security Provider]
+ * #[Preauthenticated SSO Provider]
* #[Client Details]
* #[Service Details]
* #[WebHDFS]
Modified: incubator/knox/trunk/books/0.4.0/book_gateway-details.md
URL: http://svn.apache.org/viewvc/incubator/knox/trunk/books/0.4.0/book_gateway-details.md?rev=1569613&r1=1569612&r2=1569613&view=diff
==============================================================================
--- incubator/knox/trunk/books/0.4.0/book_gateway-details.md (original)
+++ incubator/knox/trunk/books/0.4.0/book_gateway-details.md Wed Feb 19 02:26:24 2014
@@ -58,4 +58,6 @@ Their values can also be provided via th
<<config_authz.md>>
<<config_kerberos.md>>
<<config_ha.md>>
+<<config_webappsec_provider.md>>
+<<config_preauth_sso_provider.md>>
Added: incubator/knox/trunk/books/0.4.0/config_preauth_sso_provider.md
URL: http://svn.apache.org/viewvc/incubator/knox/trunk/books/0.4.0/config_preauth_sso_provider.md?rev=1569613&view=auto
==============================================================================
--- incubator/knox/trunk/books/0.4.0/config_preauth_sso_provider.md (added)
+++ incubator/knox/trunk/books/0.4.0/config_preauth_sso_provider.md Wed Feb 19 02:26:24 2014
@@ -0,0 +1,83 @@
+<!---
+ Licensed to the Apache Software Foundation (ASF) under one or more
+ contributor license agreements. See the NOTICE file distributed with
+ this work for additional information regarding copyright ownership.
+ The ASF licenses this file to You under the Apache License, Version 2.0
+ (the "License"); you may not use this file except in compliance with
+ the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+--->
+
+### Preauthenticated SSO Provider ###
+
+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.
+
+Knox Gateway needs a pluggable mechanism for consuming these tokens and federating the asserted identity through an interaction with the Hadoop cluster.
+
+ 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.
+
+#### Configuration ####
+##### Overview #####
+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).
+
+ <provider>
+ <role>federation</role>
+ <name>HeaderPreAuth</name>
+ <enabled>true</enabled>
+ </provider>
+
+The following table describes the configuration options for the web app security provider:
+
+##### Descriptions #####
+
+Name | Description | Default
+---------|-----------
+preauth.validation.method|Optional parameter that indicates the type of trust validation to perform on incoming requests. Possible values are: null, preauth.ip.validation (others will be added in future releases). Failure results in a 403 forbidden HTTP status response.|null - which means no validation will be performed and that we are assuming that the network security and external authentication system is sufficient.
+preauth.ip.addresses|Optional parameter that indicates the list of trusted ip addresses. When preauth.ip.validation is indicated as the validation method this parameter must be provided to indicate the trusted ip address set. Wildcarded IPs may be used to indicate subnet level trust. ie. 127.0.*|null - which means that no validation will be performed.
+preauth.custom.header|Required parameter for indicating a custom header to use for extracting the preauthenticated principal. The value extracted from this header is utilized as the PrimaryPrincipal within the established Subject. An incoming request that is missing the configured header will be refused with a 401 unauthorized HTTP status.|SM_USER for SiteMinder usecase
+preauth.custom.group.header|Optional parameter for indicating a HTTP header name that contains a comma separated list of groups. These are added to the authenticated Subject as group principals. A missing group header will result in no groups being extracted from the incoming request and a log entry but processing will continue.|null - which means that there will be no group principals extracted from the request and added to the established Subject.
+
+##### Configuration for SiteMinder
+The following is an example of a configuration of the preauthenticated sso provider that leverages the default SM_USER header name - assuming use with CA SiteMinder. It further configures the validation based on the IP address from the incoming request.
+
+ <provider>
+ <role>federation</role>
+ <name>HeaderPreAuth</name>
+ <enabled>true</enabled>
+ <param><name>preauth.validation.method</name><value>preauth.ip.validation</value></param>
+ <param><name>preauth.ip.addresses</name><value>127.0.0.2,127.0.0.1</value></param>
+ </provider>
+
+##### REST Invocation for SiteMinder
+The following curl command can be used to request a directory listing from HDFS while passing in the expected header SM_USER.
+
+ curl -k -i --header "SM_USER: guest" -v https://localhost:8443/gateway/sandbox/webhdfs/v1/tmp?op=LISTSTATUS
+
+Omitting the --header "SM_USER: guest" above will result in a rejected request.
+
+##### Configuration for IBM Tivoli AM
+As an example for configuring the preauthenticated sso provider for another SSO provider, the following illustrates the values used for IBM's Tivoli Access Manager:
+
+ <provider>
+ <role>federation</role>
+ <name>HeaderPreAuth</name>
+ <enabled>true</enabled>
+ <param><name>preauth.custom.header</name><value>iv_user</value></param>
+ <param><name>preauth.custom.group.header</name><value>iv_group</value></param>
+ <param><name>preauth.validation.method</name><value>preauth.ip.validation</value></param>
+ <param><name>preauth.ip.addresses</name><value>127.0.0.2,127.0.0.1</value></param>
+ </provider>
+
+##### REST Invocation for Tivoli AM
+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.
+
+ curl -k -i --header "iv_user: guest" --header "iv_group: admin" -v https://localhost:8443/gateway/sandbox/webhdfs/v1/tmp?op=LISTSTATUS
+
+Omitting the --header "iv_user: guest" above will result in a rejected request.
Added: incubator/knox/trunk/books/0.4.0/config_webappsec_provider.md
URL: http://svn.apache.org/viewvc/incubator/knox/trunk/books/0.4.0/config_webappsec_provider.md?rev=1569613&view=auto
==============================================================================
--- incubator/knox/trunk/books/0.4.0/config_webappsec_provider.md (added)
+++ incubator/knox/trunk/books/0.4.0/config_webappsec_provider.md Wed Feb 19 02:26:24 2014
@@ -0,0 +1,66 @@
+<!---
+ Licensed to the Apache Software Foundation (ASF) under one or more
+ contributor license agreements. See the NOTICE file distributed with
+ this work for additional information regarding copyright ownership.
+ The ASF licenses this file to You under the Apache License, Version 2.0
+ (the "License"); you may not use this file except in compliance with
+ the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+--->
+
+### 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.
+
+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.
+
+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.
+
+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.
+
+
+#### 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.
+
+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.
+
+ <provider
+ <role>webappsec</role>
+ <name>WebAppSec</name>
+ <enabled>true</enabled>
+ <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>
+ </provider>
+
+#### Descriptions ####
+The following table describes the configuration options for the web app security provider:
+
+Name | Description | Default
+---------|-----------
+csrf.enabled|This param enables the CSRF protection capabilities|false
+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
+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: oihdfgilhsdog" -v -u guest:guest-password https://localhost:8443/gateway/sandbox/webhdfs/v1/tmp?op=LISTSTATUS
+
+Omitting the --header "X-XSRF-Header: oihdfgilhsdog" above should result in an HTTP 400 bad_request or a 403 forbidden.
+
+Disabling the provider will then allow a request that is missing the header through.
+