You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@knox.apache.org by larry mccay <lm...@apache.org> on 2016/01/20 01:26:30 UTC

CSRF Header Requirements and Dispatch

All -

As https://issues.apache.org/jira/browse/HADOOP-12691 gets rolled out in
Hadoop 2.8 with uptake from hopefully coming from WebHDFS and YARN, Knox
will likely need to be able to send expected headers to the component
through dispatch.

This will mean something like a service param to indicate the special
header to be expected by the service and then each dispatch be able to
recognize this and send the header.

I will likely file a JIRA for this work but wanted to raise it as an issue
that will come along with 2.8.

Any thoughts, concerns or questions, insights?

thanks,

--larry

Re: CSRF Header Requirements and Dispatch

Posted by Kevin Minder <ke...@hortonworks.com>.
From a behavior perspective I can see #1 adding value.  In my own words that means this:

1) There is a WebAppSecurityProvider configured with a Knox specific CSRF filter.
2) Each each service dispatch (or rewrite rules) will optionally inject the service specific CSRF headers.

There are several points of complexity here:

A) The service specific CSRF header should only be injected (i.e. #2) if an inbound CSRF header is verified by #1.  This implies of level of cooperation between providers and dispatch that we don’t really have much precedence for yet.
B) The configuration for #2 could become a usability issue.
C) Will clients be hard coded to send service specific CSRF headers and never capable of sending a Knox specific one?


On 1/20/16, 9:49 AM, "larry mccay" <lm...@apache.org> wrote:

>I've been thinking about the same thing.
>
>If we were to add it without the client send any CSRF header than I would
>agree.
>It feels like it would have to be a one of two things:
>
>1. a combination of the Knox CSRF header being added and we translate that
>to the service expected header
>2. just a pass through where Knox CSRF is not configured and we make sure
>that the CSRF header provided by the client isn't blocked from the service
>
>A benefit to #1 is that it hides the possible complexities of knowing all
>the headers for all the services from Knox clients but this comes at the
>expense of complicated topology config to ensure that we have the header to
>translate it to configured for each service.
>
>If we made the default expected header the same across Knox and all
>components then maybe we could only have to rewrite the header for those
>services that change it from the default.
>
>On Wed, Jan 20, 2016 at 9:37 AM, Kevin Minder <ke...@hortonworks.com>
>wrote:
>
>> Would Knox automatically adding this header dilute the benefit of it?
>> Isn’t the point that the browser (i.e. real client) is expected to send the
>> header?
>>
>>
>>
>>
>> On 1/19/16, 7:26 PM, "larry mccay" <lm...@apache.org> wrote:
>>
>> >All -
>> >
>> >As https://issues.apache.org/jira/browse/HADOOP-12691 gets rolled out in
>> >Hadoop 2.8 with uptake from hopefully coming from WebHDFS and YARN, Knox
>> >will likely need to be able to send expected headers to the component
>> >through dispatch.
>> >
>> >This will mean something like a service param to indicate the special
>> >header to be expected by the service and then each dispatch be able to
>> >recognize this and send the header.
>> >
>> >I will likely file a JIRA for this work but wanted to raise it as an issue
>> >that will come along with 2.8.
>> >
>> >Any thoughts, concerns or questions, insights?
>> >
>> >thanks,
>> >
>> >--larry
>>

Re: CSRF Header Requirements and Dispatch

Posted by larry mccay <lm...@apache.org>.
I've been thinking about the same thing.

If we were to add it without the client send any CSRF header than I would
agree.
It feels like it would have to be a one of two things:

1. a combination of the Knox CSRF header being added and we translate that
to the service expected header
2. just a pass through where Knox CSRF is not configured and we make sure
that the CSRF header provided by the client isn't blocked from the service

A benefit to #1 is that it hides the possible complexities of knowing all
the headers for all the services from Knox clients but this comes at the
expense of complicated topology config to ensure that we have the header to
translate it to configured for each service.

If we made the default expected header the same across Knox and all
components then maybe we could only have to rewrite the header for those
services that change it from the default.

On Wed, Jan 20, 2016 at 9:37 AM, Kevin Minder <ke...@hortonworks.com>
wrote:

> Would Knox automatically adding this header dilute the benefit of it?
> Isn’t the point that the browser (i.e. real client) is expected to send the
> header?
>
>
>
>
> On 1/19/16, 7:26 PM, "larry mccay" <lm...@apache.org> wrote:
>
> >All -
> >
> >As https://issues.apache.org/jira/browse/HADOOP-12691 gets rolled out in
> >Hadoop 2.8 with uptake from hopefully coming from WebHDFS and YARN, Knox
> >will likely need to be able to send expected headers to the component
> >through dispatch.
> >
> >This will mean something like a service param to indicate the special
> >header to be expected by the service and then each dispatch be able to
> >recognize this and send the header.
> >
> >I will likely file a JIRA for this work but wanted to raise it as an issue
> >that will come along with 2.8.
> >
> >Any thoughts, concerns or questions, insights?
> >
> >thanks,
> >
> >--larry
>

Re: CSRF Header Requirements and Dispatch

Posted by Kevin Minder <ke...@hortonworks.com>.
Would Knox automatically adding this header dilute the benefit of it?  Isn’t the point that the browser (i.e. real client) is expected to send the header?




On 1/19/16, 7:26 PM, "larry mccay" <lm...@apache.org> wrote:

>All -
>
>As https://issues.apache.org/jira/browse/HADOOP-12691 gets rolled out in
>Hadoop 2.8 with uptake from hopefully coming from WebHDFS and YARN, Knox
>will likely need to be able to send expected headers to the component
>through dispatch.
>
>This will mean something like a service param to indicate the special
>header to be expected by the service and then each dispatch be able to
>recognize this and send the header.
>
>I will likely file a JIRA for this work but wanted to raise it as an issue
>that will come along with 2.8.
>
>Any thoughts, concerns or questions, insights?
>
>thanks,
>
>--larry