You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@knox.apache.org by Kevin Minder <ke...@hortonworks.com> on 2013/11/21 14:10:24 UTC
Re: CSRF Prevention Provider
I this is a symptom of the fact that we don't have externally defined
chains. I have started working on that but I'm not finding much time
these days. If we had an external chain definition the role/name thing
wouldn't mater so much.
That doesn't really answer the question about the role for this. I
always had it in my head the role identified some sort of a contract
such that if it were present there would be a consistent set of
attributes, subject, etc available at runtime and potentially a
consistent base-line set of understood configuration properties.
This would lead me to think the naming should be something like
role=csrf, name=default but I'm finding it hard to convince myself that
this is the right answer. It could be the name=default part. Is there
a particular technique you use so that it could be csrf/x-header or
something. That would fit better with the authentication/shiro,
dispatch/http-client model.
On 11/21/13 7:36 AM, Larry McCay wrote:
> Hey -
>
> I cranked out a simple CSRF prevention provider last night.
> Trying to figure out whether we want a separate role for it or not.
>
> I was thinking that a global or default role - like the default webapp
> in appservers - could be used to host multiple things like this and
> that it would essentially be a set of filters that get put in front of
> authentication/federation.
>
> So, this would take the shape of one of a couple options:
>
> 1. separate provider modules that get put into the default role and we
> would have to be able to handle multiple in the same role
>
> 2. a single provider module that adds them all. This would likely
> require the config in topology to be all bunched into a single
> provider element and so the config names would have to be unique
> across filters.
>
> or, maybe we just give it a csrf role...
>
> What do you think?
>
> thanks,
>
> --lar
>
--
CONFIDENTIALITY NOTICE
NOTICE: This message is intended for the use of the individual or entity to
which it is addressed and may contain information that is confidential,
privileged and exempt from disclosure under applicable law. If the reader
of this message is not the intended recipient, you are hereby notified that
any printing, copying, dissemination, distribution, disclosure or
forwarding of this communication is strictly prohibited. If you have
received this communication in error, please contact the sender immediately
and delete it from your system. Thank You.
Re: CSRF Prevention Provider
Posted by Kevin Minder <ke...@hortonworks.com>.
So are you specifically saying you don't like the "proprietary" model
described in the design below?
https://cwiki.apache.org/confluence/display/KNOX/Simplify+service+deployment+contributor+implementation+%28KNOX-177%29
My concern with a "customized snippet of web.xml" is that presents the
"illusion" of using something standard without actually doing so. This
always leads to "Well it is web.xml, why cant I, do ...?"
Can you boil this down to what your fundamental position is?
Do you not think that code should not be required to implement a
provider even if that code is drastically simplified as described in these?
https://cwiki.apache.org/confluence/display/KNOX/Simple+way+to+introduce+new+Provider+%28KNOX-179%29
https://cwiki.apache.org/confluence/display/KNOX/Simple+way+to+introduce+new+Service+%28KNOX-195%29
Both of these BTW allow both a provider and a service to be introduced
without writing any code as an option.
I'm not saying these designs or complete but they do illustrate what I'm
currently thinking.
Note that KNOX-179 is already implemented I just need to apply the patch.
I have KNOX-177 half done but I'm not finding much time to work on it
lately.
On 11/21/13 9:45 AM, Dilli Arumugam wrote:
> I would prefer exposing a snippet of standard web.xml where one could
> specify filter definitions including filter parameters that they would like
> inserted into Knox processing chain.
>
> Knox would have its own filters in the chain that would go before and after
> these custom filters.
> Knox would take the customized snippet of web.xml, merge it with its own
> web.xml and have the full web.xml.
>
> No need to write custom provider code.
>
> Thanks
> Dilli
>
>
>
>
> On Thu, Nov 21, 2013 at 5:34 AM, Kevin Minder
> <ke...@hortonworks.com>wrote:
>
>> I do agree that the whole role/name thing isn't holding together as well
>> as I intended.
>>
>> For externally defined chains see this.
>> https://cwiki.apache.org/confluence/display/KNOX/
>> Simplify+service+deployment+contributor+implementation+%28KNOX-177%29
>>
>>
>>
>> On 11/21/13 8:24 AM, larry mccay wrote:
>>
>>> I guess we could make it csrf/x-header - I do allow for a configuration
>>> element to specify a header name other than the default of X-XSRF-Header.
>>>
>>> I don't think that the role->common config thing is holding together -
>>> authentication providers will have very different config. Of course, the
>>> fact that they are all filters make the contract the same - but that is
>>> the
>>> same across provider roles too.
>>>
>>> I'm not totally clear on what you mean by externally defined chains.
>>>
>>> To touch on what I had in mind in a little more detail, what I was
>>> thinking
>>> was that some filters - like this one - maybe shouldn't have to be
>>> configured explicitly but just enabled through some higher level config
>>> elements. Like at the <gateway> element level. So that we wouldn't need an
>>> actual <provider> element for it.
>>>
>>> In the near term, we could just add it as a regular provider with its own
>>> explicit config and we can investigate the external or global/default
>>> thing
>>> later into Baikal or beyond.
>>>
>>>
>>> On Thu, Nov 21, 2013 at 8:10 AM, Kevin Minder
>>> <ke...@hortonworks.com>wrote:
>>>
>>> I this is a symptom of the fact that we don't have externally defined
>>>> chains. I have started working on that but I'm not finding much time
>>>> these
>>>> days. If we had an external chain definition the role/name thing
>>>> wouldn't
>>>> mater so much.
>>>>
>>>> That doesn't really answer the question about the role for this. I always
>>>> had it in my head the role identified some sort of a contract such that
>>>> if
>>>> it were present there would be a consistent set of attributes, subject,
>>>> etc
>>>> available at runtime and potentially a consistent base-line set of
>>>> understood configuration properties.
>>>>
>>>> This would lead me to think the naming should be something like
>>>> role=csrf,
>>>> name=default but I'm finding it hard to convince myself that this is the
>>>> right answer. It could be the name=default part. Is there a particular
>>>> technique you use so that it could be csrf/x-header or something. That
>>>> would fit better with the authentication/shiro, dispatch/http-client
>>>> model.
>>>>
>>>> On 11/21/13 7:36 AM, Larry McCay wrote:
>>>>
>>>> Hey -
>>>>> I cranked out a simple CSRF prevention provider last night.
>>>>> Trying to figure out whether we want a separate role for it or not.
>>>>>
>>>>> I was thinking that a global or default role - like the default webapp
>>>>> in
>>>>> appservers - could be used to host multiple things like this and that it
>>>>> would essentially be a set of filters that get put in front of
>>>>> authentication/federation.
>>>>>
>>>>> So, this would take the shape of one of a couple options:
>>>>>
>>>>> 1. separate provider modules that get put into the default role and we
>>>>> would have to be able to handle multiple in the same role
>>>>>
>>>>> 2. a single provider module that adds them all. This would likely
>>>>> require
>>>>> the config in topology to be all bunched into a single provider element
>>>>> and
>>>>> so the config names would have to be unique across filters.
>>>>>
>>>>> or, maybe we just give it a csrf role...
>>>>>
>>>>> What do you think?
>>>>>
>>>>> thanks,
>>>>>
>>>>> --lar
>>>>>
>>>>>
>>>>> --
>>>> CONFIDENTIALITY NOTICE
>>>> NOTICE: This message is intended for the use of the individual or entity
>>>> to which it is addressed and may contain information that is
>>>> confidential,
>>>> privileged and exempt from disclosure under applicable law. If the reader
>>>> of this message is not the intended recipient, you are hereby notified
>>>> that
>>>> any printing, copying, dissemination, distribution, disclosure or
>>>> forwarding of this communication is strictly prohibited. If you have
>>>> received this communication in error, please contact the sender
>>>> immediately
>>>> and delete it from your system. Thank You.
>>>>
>>>>
>> --
>> CONFIDENTIALITY NOTICE
>> NOTICE: This message is intended for the use of the individual or entity
>> to which it is addressed and may contain information that is confidential,
>> privileged and exempt from disclosure under applicable law. If the reader
>> of this message is not the intended recipient, you are hereby notified that
>> any printing, copying, dissemination, distribution, disclosure or
>> forwarding of this communication is strictly prohibited. If you have
>> received this communication in error, please contact the sender immediately
>> and delete it from your system. Thank You.
>>
--
CONFIDENTIALITY NOTICE
NOTICE: This message is intended for the use of the individual or entity to
which it is addressed and may contain information that is confidential,
privileged and exempt from disclosure under applicable law. If the reader
of this message is not the intended recipient, you are hereby notified that
any printing, copying, dissemination, distribution, disclosure or
forwarding of this communication is strictly prohibited. If you have
received this communication in error, please contact the sender immediately
and delete it from your system. Thank You.
Re: CSRF Prevention Provider
Posted by larry mccay <la...@gmail.com>.
Well, in the near term, I will add csrf prevention as a separate provider
role to each of the services.
WRT adding or changing the contribution and chain building model, we have
to rearticulate the intended goals of the topology file and who is expected
to manage these configurations.
It may be sufficient to have a mix of "no-one needs to know classnames" and
"custom filters require classnames in config".
Of course, we need to mindful of the fact that web.xml is rewritten on
redeployment today - so anyone that mucks with that file will lose their
work on the next triggered redeploy.
While topologies are implemented as webapps today with things like web.xml
files being created, Knox is not a webapp framework per se. We just need to
reconcile the original vision and how it works with extension for custom
filters and providers.
On Thu, Nov 21, 2013 at 10:04 AM, Dilli Arumugam
<da...@hortonworks.com>wrote:
> Adding more details:
>
> The custom filter chain snippet could have some filters prefilled by Knox
> install.
> However, those can be replaced easily.
> Core filters in the main web.xml are not meant to be replaceable.
>
> A very advanced user or PS could tinker even with main web.xml file.
>
> Tending to think, the processing logic of the new filters would be java
> code.
> But, definition, integration of the filters into web.xml would come from
> text/xml files and not java code.
>
> Thanks
> Dilli
>
>
>
>
> On Thu, Nov 21, 2013 at 6:45 AM, Dilli Arumugam
> <da...@hortonworks.com>wrote:
>
> > I would prefer exposing a snippet of standard web.xml where one could
> > specify filter definitions including filter parameters that they would
> like
> > inserted into Knox processing chain.
> >
> > Knox would have its own filters in the chain that would go before and
> > after these custom filters.
> > Knox would take the customized snippet of web.xml, merge it with its own
> > web.xml and have the full web.xml.
> >
> > No need to write custom provider code.
> >
> > Thanks
> > Dilli
> >
> >
> >
> >
> > On Thu, Nov 21, 2013 at 5:34 AM, Kevin Minder <
> > kevin.minder@hortonworks.com> wrote:
> >
> >> I do agree that the whole role/name thing isn't holding together as well
> >> as I intended.
> >>
> >> For externally defined chains see this.
> >> https://cwiki.apache.org/confluence/display/KNOX/
> >> Simplify+service+deployment+contributor+implementation+%28KNOX-177%29
> >>
> >>
> >>
> >> On 11/21/13 8:24 AM, larry mccay wrote:
> >>
> >>> I guess we could make it csrf/x-header - I do allow for a configuration
> >>> element to specify a header name other than the default of
> X-XSRF-Header.
> >>>
> >>> I don't think that the role->common config thing is holding together -
> >>> authentication providers will have very different config. Of course,
> the
> >>> fact that they are all filters make the contract the same - but that is
> >>> the
> >>> same across provider roles too.
> >>>
> >>> I'm not totally clear on what you mean by externally defined chains.
> >>>
> >>> To touch on what I had in mind in a little more detail, what I was
> >>> thinking
> >>> was that some filters - like this one - maybe shouldn't have to be
> >>> configured explicitly but just enabled through some higher level config
> >>> elements. Like at the <gateway> element level. So that we wouldn't need
> >>> an
> >>> actual <provider> element for it.
> >>>
> >>> In the near term, we could just add it as a regular provider with its
> own
> >>> explicit config and we can investigate the external or global/default
> >>> thing
> >>> later into Baikal or beyond.
> >>>
> >>>
> >>> On Thu, Nov 21, 2013 at 8:10 AM, Kevin Minder
> >>> <ke...@hortonworks.com>wrote:
> >>>
> >>> I this is a symptom of the fact that we don't have externally defined
> >>>> chains. I have started working on that but I'm not finding much time
> >>>> these
> >>>> days. If we had an external chain definition the role/name thing
> >>>> wouldn't
> >>>> mater so much.
> >>>>
> >>>> That doesn't really answer the question about the role for this. I
> >>>> always
> >>>> had it in my head the role identified some sort of a contract such
> that
> >>>> if
> >>>> it were present there would be a consistent set of attributes,
> subject,
> >>>> etc
> >>>> available at runtime and potentially a consistent base-line set of
> >>>> understood configuration properties.
> >>>>
> >>>> This would lead me to think the naming should be something like
> >>>> role=csrf,
> >>>> name=default but I'm finding it hard to convince myself that this is
> the
> >>>> right answer. It could be the name=default part. Is there a
> particular
> >>>> technique you use so that it could be csrf/x-header or something.
> That
> >>>> would fit better with the authentication/shiro, dispatch/http-client
> >>>> model.
> >>>>
> >>>> On 11/21/13 7:36 AM, Larry McCay wrote:
> >>>>
> >>>> Hey -
> >>>>>
> >>>>> I cranked out a simple CSRF prevention provider last night.
> >>>>> Trying to figure out whether we want a separate role for it or not.
> >>>>>
> >>>>> I was thinking that a global or default role - like the default
> webapp
> >>>>> in
> >>>>> appservers - could be used to host multiple things like this and that
> >>>>> it
> >>>>> would essentially be a set of filters that get put in front of
> >>>>> authentication/federation.
> >>>>>
> >>>>> So, this would take the shape of one of a couple options:
> >>>>>
> >>>>> 1. separate provider modules that get put into the default role and
> we
> >>>>> would have to be able to handle multiple in the same role
> >>>>>
> >>>>> 2. a single provider module that adds them all. This would likely
> >>>>> require
> >>>>> the config in topology to be all bunched into a single provider
> >>>>> element and
> >>>>> so the config names would have to be unique across filters.
> >>>>>
> >>>>> or, maybe we just give it a csrf role...
> >>>>>
> >>>>> What do you think?
> >>>>>
> >>>>> thanks,
> >>>>>
> >>>>> --lar
> >>>>>
> >>>>>
> >>>>> --
> >>>> CONFIDENTIALITY NOTICE
> >>>> NOTICE: This message is intended for the use of the individual or
> entity
> >>>> to which it is addressed and may contain information that is
> >>>> confidential,
> >>>> privileged and exempt from disclosure under applicable law. If the
> >>>> reader
> >>>> of this message is not the intended recipient, you are hereby notified
> >>>> that
> >>>> any printing, copying, dissemination, distribution, disclosure or
> >>>> forwarding of this communication is strictly prohibited. If you have
> >>>> received this communication in error, please contact the sender
> >>>> immediately
> >>>> and delete it from your system. Thank You.
> >>>>
> >>>>
> >>
> >> --
> >> CONFIDENTIALITY NOTICE
> >> NOTICE: This message is intended for the use of the individual or entity
> >> to which it is addressed and may contain information that is
> confidential,
> >> privileged and exempt from disclosure under applicable law. If the
> reader
> >> of this message is not the intended recipient, you are hereby notified
> that
> >> any printing, copying, dissemination, distribution, disclosure or
> >> forwarding of this communication is strictly prohibited. If you have
> >> received this communication in error, please contact the sender
> immediately
> >> and delete it from your system. Thank You.
> >>
> >
> >
>
> --
> CONFIDENTIALITY NOTICE
> NOTICE: This message is intended for the use of the individual or entity to
> which it is addressed and may contain information that is confidential,
> privileged and exempt from disclosure under applicable law. If the reader
> of this message is not the intended recipient, you are hereby notified that
> any printing, copying, dissemination, distribution, disclosure or
> forwarding of this communication is strictly prohibited. If you have
> received this communication in error, please contact the sender immediately
> and delete it from your system. Thank You.
>
Re: CSRF Prevention Provider
Posted by Dilli Arumugam <da...@hortonworks.com>.
Adding more details:
The custom filter chain snippet could have some filters prefilled by Knox
install.
However, those can be replaced easily.
Core filters in the main web.xml are not meant to be replaceable.
A very advanced user or PS could tinker even with main web.xml file.
Tending to think, the processing logic of the new filters would be java
code.
But, definition, integration of the filters into web.xml would come from
text/xml files and not java code.
Thanks
Dilli
On Thu, Nov 21, 2013 at 6:45 AM, Dilli Arumugam
<da...@hortonworks.com>wrote:
> I would prefer exposing a snippet of standard web.xml where one could
> specify filter definitions including filter parameters that they would like
> inserted into Knox processing chain.
>
> Knox would have its own filters in the chain that would go before and
> after these custom filters.
> Knox would take the customized snippet of web.xml, merge it with its own
> web.xml and have the full web.xml.
>
> No need to write custom provider code.
>
> Thanks
> Dilli
>
>
>
>
> On Thu, Nov 21, 2013 at 5:34 AM, Kevin Minder <
> kevin.minder@hortonworks.com> wrote:
>
>> I do agree that the whole role/name thing isn't holding together as well
>> as I intended.
>>
>> For externally defined chains see this.
>> https://cwiki.apache.org/confluence/display/KNOX/
>> Simplify+service+deployment+contributor+implementation+%28KNOX-177%29
>>
>>
>>
>> On 11/21/13 8:24 AM, larry mccay wrote:
>>
>>> I guess we could make it csrf/x-header - I do allow for a configuration
>>> element to specify a header name other than the default of X-XSRF-Header.
>>>
>>> I don't think that the role->common config thing is holding together -
>>> authentication providers will have very different config. Of course, the
>>> fact that they are all filters make the contract the same - but that is
>>> the
>>> same across provider roles too.
>>>
>>> I'm not totally clear on what you mean by externally defined chains.
>>>
>>> To touch on what I had in mind in a little more detail, what I was
>>> thinking
>>> was that some filters - like this one - maybe shouldn't have to be
>>> configured explicitly but just enabled through some higher level config
>>> elements. Like at the <gateway> element level. So that we wouldn't need
>>> an
>>> actual <provider> element for it.
>>>
>>> In the near term, we could just add it as a regular provider with its own
>>> explicit config and we can investigate the external or global/default
>>> thing
>>> later into Baikal or beyond.
>>>
>>>
>>> On Thu, Nov 21, 2013 at 8:10 AM, Kevin Minder
>>> <ke...@hortonworks.com>wrote:
>>>
>>> I this is a symptom of the fact that we don't have externally defined
>>>> chains. I have started working on that but I'm not finding much time
>>>> these
>>>> days. If we had an external chain definition the role/name thing
>>>> wouldn't
>>>> mater so much.
>>>>
>>>> That doesn't really answer the question about the role for this. I
>>>> always
>>>> had it in my head the role identified some sort of a contract such that
>>>> if
>>>> it were present there would be a consistent set of attributes, subject,
>>>> etc
>>>> available at runtime and potentially a consistent base-line set of
>>>> understood configuration properties.
>>>>
>>>> This would lead me to think the naming should be something like
>>>> role=csrf,
>>>> name=default but I'm finding it hard to convince myself that this is the
>>>> right answer. It could be the name=default part. Is there a particular
>>>> technique you use so that it could be csrf/x-header or something. That
>>>> would fit better with the authentication/shiro, dispatch/http-client
>>>> model.
>>>>
>>>> On 11/21/13 7:36 AM, Larry McCay wrote:
>>>>
>>>> Hey -
>>>>>
>>>>> I cranked out a simple CSRF prevention provider last night.
>>>>> Trying to figure out whether we want a separate role for it or not.
>>>>>
>>>>> I was thinking that a global or default role - like the default webapp
>>>>> in
>>>>> appservers - could be used to host multiple things like this and that
>>>>> it
>>>>> would essentially be a set of filters that get put in front of
>>>>> authentication/federation.
>>>>>
>>>>> So, this would take the shape of one of a couple options:
>>>>>
>>>>> 1. separate provider modules that get put into the default role and we
>>>>> would have to be able to handle multiple in the same role
>>>>>
>>>>> 2. a single provider module that adds them all. This would likely
>>>>> require
>>>>> the config in topology to be all bunched into a single provider
>>>>> element and
>>>>> so the config names would have to be unique across filters.
>>>>>
>>>>> or, maybe we just give it a csrf role...
>>>>>
>>>>> What do you think?
>>>>>
>>>>> thanks,
>>>>>
>>>>> --lar
>>>>>
>>>>>
>>>>> --
>>>> CONFIDENTIALITY NOTICE
>>>> NOTICE: This message is intended for the use of the individual or entity
>>>> to which it is addressed and may contain information that is
>>>> confidential,
>>>> privileged and exempt from disclosure under applicable law. If the
>>>> reader
>>>> of this message is not the intended recipient, you are hereby notified
>>>> that
>>>> any printing, copying, dissemination, distribution, disclosure or
>>>> forwarding of this communication is strictly prohibited. If you have
>>>> received this communication in error, please contact the sender
>>>> immediately
>>>> and delete it from your system. Thank You.
>>>>
>>>>
>>
>> --
>> CONFIDENTIALITY NOTICE
>> NOTICE: This message is intended for the use of the individual or entity
>> to which it is addressed and may contain information that is confidential,
>> privileged and exempt from disclosure under applicable law. If the reader
>> of this message is not the intended recipient, you are hereby notified that
>> any printing, copying, dissemination, distribution, disclosure or
>> forwarding of this communication is strictly prohibited. If you have
>> received this communication in error, please contact the sender immediately
>> and delete it from your system. Thank You.
>>
>
>
--
CONFIDENTIALITY NOTICE
NOTICE: This message is intended for the use of the individual or entity to
which it is addressed and may contain information that is confidential,
privileged and exempt from disclosure under applicable law. If the reader
of this message is not the intended recipient, you are hereby notified that
any printing, copying, dissemination, distribution, disclosure or
forwarding of this communication is strictly prohibited. If you have
received this communication in error, please contact the sender immediately
and delete it from your system. Thank You.
Re: CSRF Prevention Provider
Posted by Dilli Arumugam <da...@hortonworks.com>.
I would prefer exposing a snippet of standard web.xml where one could
specify filter definitions including filter parameters that they would like
inserted into Knox processing chain.
Knox would have its own filters in the chain that would go before and after
these custom filters.
Knox would take the customized snippet of web.xml, merge it with its own
web.xml and have the full web.xml.
No need to write custom provider code.
Thanks
Dilli
On Thu, Nov 21, 2013 at 5:34 AM, Kevin Minder
<ke...@hortonworks.com>wrote:
> I do agree that the whole role/name thing isn't holding together as well
> as I intended.
>
> For externally defined chains see this.
> https://cwiki.apache.org/confluence/display/KNOX/
> Simplify+service+deployment+contributor+implementation+%28KNOX-177%29
>
>
>
> On 11/21/13 8:24 AM, larry mccay wrote:
>
>> I guess we could make it csrf/x-header - I do allow for a configuration
>> element to specify a header name other than the default of X-XSRF-Header.
>>
>> I don't think that the role->common config thing is holding together -
>> authentication providers will have very different config. Of course, the
>> fact that they are all filters make the contract the same - but that is
>> the
>> same across provider roles too.
>>
>> I'm not totally clear on what you mean by externally defined chains.
>>
>> To touch on what I had in mind in a little more detail, what I was
>> thinking
>> was that some filters - like this one - maybe shouldn't have to be
>> configured explicitly but just enabled through some higher level config
>> elements. Like at the <gateway> element level. So that we wouldn't need an
>> actual <provider> element for it.
>>
>> In the near term, we could just add it as a regular provider with its own
>> explicit config and we can investigate the external or global/default
>> thing
>> later into Baikal or beyond.
>>
>>
>> On Thu, Nov 21, 2013 at 8:10 AM, Kevin Minder
>> <ke...@hortonworks.com>wrote:
>>
>> I this is a symptom of the fact that we don't have externally defined
>>> chains. I have started working on that but I'm not finding much time
>>> these
>>> days. If we had an external chain definition the role/name thing
>>> wouldn't
>>> mater so much.
>>>
>>> That doesn't really answer the question about the role for this. I always
>>> had it in my head the role identified some sort of a contract such that
>>> if
>>> it were present there would be a consistent set of attributes, subject,
>>> etc
>>> available at runtime and potentially a consistent base-line set of
>>> understood configuration properties.
>>>
>>> This would lead me to think the naming should be something like
>>> role=csrf,
>>> name=default but I'm finding it hard to convince myself that this is the
>>> right answer. It could be the name=default part. Is there a particular
>>> technique you use so that it could be csrf/x-header or something. That
>>> would fit better with the authentication/shiro, dispatch/http-client
>>> model.
>>>
>>> On 11/21/13 7:36 AM, Larry McCay wrote:
>>>
>>> Hey -
>>>>
>>>> I cranked out a simple CSRF prevention provider last night.
>>>> Trying to figure out whether we want a separate role for it or not.
>>>>
>>>> I was thinking that a global or default role - like the default webapp
>>>> in
>>>> appservers - could be used to host multiple things like this and that it
>>>> would essentially be a set of filters that get put in front of
>>>> authentication/federation.
>>>>
>>>> So, this would take the shape of one of a couple options:
>>>>
>>>> 1. separate provider modules that get put into the default role and we
>>>> would have to be able to handle multiple in the same role
>>>>
>>>> 2. a single provider module that adds them all. This would likely
>>>> require
>>>> the config in topology to be all bunched into a single provider element
>>>> and
>>>> so the config names would have to be unique across filters.
>>>>
>>>> or, maybe we just give it a csrf role...
>>>>
>>>> What do you think?
>>>>
>>>> thanks,
>>>>
>>>> --lar
>>>>
>>>>
>>>> --
>>> CONFIDENTIALITY NOTICE
>>> NOTICE: This message is intended for the use of the individual or entity
>>> to which it is addressed and may contain information that is
>>> confidential,
>>> privileged and exempt from disclosure under applicable law. If the reader
>>> of this message is not the intended recipient, you are hereby notified
>>> that
>>> any printing, copying, dissemination, distribution, disclosure or
>>> forwarding of this communication is strictly prohibited. If you have
>>> received this communication in error, please contact the sender
>>> immediately
>>> and delete it from your system. Thank You.
>>>
>>>
>
> --
> CONFIDENTIALITY NOTICE
> NOTICE: This message is intended for the use of the individual or entity
> to which it is addressed and may contain information that is confidential,
> privileged and exempt from disclosure under applicable law. If the reader
> of this message is not the intended recipient, you are hereby notified that
> any printing, copying, dissemination, distribution, disclosure or
> forwarding of this communication is strictly prohibited. If you have
> received this communication in error, please contact the sender immediately
> and delete it from your system. Thank You.
>
--
CONFIDENTIALITY NOTICE
NOTICE: This message is intended for the use of the individual or entity to
which it is addressed and may contain information that is confidential,
privileged and exempt from disclosure under applicable law. If the reader
of this message is not the intended recipient, you are hereby notified that
any printing, copying, dissemination, distribution, disclosure or
forwarding of this communication is strictly prohibited. If you have
received this communication in error, please contact the sender immediately
and delete it from your system. Thank You.
Re: CSRF Prevention Provider
Posted by Kevin Minder <ke...@hortonworks.com>.
I do agree that the whole role/name thing isn't holding together as well
as I intended.
For externally defined chains see this.
https://cwiki.apache.org/confluence/display/KNOX/Simplify+service+deployment+contributor+implementation+%28KNOX-177%29
On 11/21/13 8:24 AM, larry mccay wrote:
> I guess we could make it csrf/x-header - I do allow for a configuration
> element to specify a header name other than the default of X-XSRF-Header.
>
> I don't think that the role->common config thing is holding together -
> authentication providers will have very different config. Of course, the
> fact that they are all filters make the contract the same - but that is the
> same across provider roles too.
>
> I'm not totally clear on what you mean by externally defined chains.
>
> To touch on what I had in mind in a little more detail, what I was thinking
> was that some filters - like this one - maybe shouldn't have to be
> configured explicitly but just enabled through some higher level config
> elements. Like at the <gateway> element level. So that we wouldn't need an
> actual <provider> element for it.
>
> In the near term, we could just add it as a regular provider with its own
> explicit config and we can investigate the external or global/default thing
> later into Baikal or beyond.
>
>
> On Thu, Nov 21, 2013 at 8:10 AM, Kevin Minder
> <ke...@hortonworks.com>wrote:
>
>> I this is a symptom of the fact that we don't have externally defined
>> chains. I have started working on that but I'm not finding much time these
>> days. If we had an external chain definition the role/name thing wouldn't
>> mater so much.
>>
>> That doesn't really answer the question about the role for this. I always
>> had it in my head the role identified some sort of a contract such that if
>> it were present there would be a consistent set of attributes, subject, etc
>> available at runtime and potentially a consistent base-line set of
>> understood configuration properties.
>>
>> This would lead me to think the naming should be something like role=csrf,
>> name=default but I'm finding it hard to convince myself that this is the
>> right answer. It could be the name=default part. Is there a particular
>> technique you use so that it could be csrf/x-header or something. That
>> would fit better with the authentication/shiro, dispatch/http-client model.
>>
>> On 11/21/13 7:36 AM, Larry McCay wrote:
>>
>>> Hey -
>>>
>>> I cranked out a simple CSRF prevention provider last night.
>>> Trying to figure out whether we want a separate role for it or not.
>>>
>>> I was thinking that a global or default role - like the default webapp in
>>> appservers - could be used to host multiple things like this and that it
>>> would essentially be a set of filters that get put in front of
>>> authentication/federation.
>>>
>>> So, this would take the shape of one of a couple options:
>>>
>>> 1. separate provider modules that get put into the default role and we
>>> would have to be able to handle multiple in the same role
>>>
>>> 2. a single provider module that adds them all. This would likely require
>>> the config in topology to be all bunched into a single provider element and
>>> so the config names would have to be unique across filters.
>>>
>>> or, maybe we just give it a csrf role...
>>>
>>> What do you think?
>>>
>>> thanks,
>>>
>>> --lar
>>>
>>>
>> --
>> CONFIDENTIALITY NOTICE
>> NOTICE: This message is intended for the use of the individual or entity
>> to which it is addressed and may contain information that is confidential,
>> privileged and exempt from disclosure under applicable law. If the reader
>> of this message is not the intended recipient, you are hereby notified that
>> any printing, copying, dissemination, distribution, disclosure or
>> forwarding of this communication is strictly prohibited. If you have
>> received this communication in error, please contact the sender immediately
>> and delete it from your system. Thank You.
>>
--
CONFIDENTIALITY NOTICE
NOTICE: This message is intended for the use of the individual or entity to
which it is addressed and may contain information that is confidential,
privileged and exempt from disclosure under applicable law. If the reader
of this message is not the intended recipient, you are hereby notified that
any printing, copying, dissemination, distribution, disclosure or
forwarding of this communication is strictly prohibited. If you have
received this communication in error, please contact the sender immediately
and delete it from your system. Thank You.
Re: CSRF Prevention Provider
Posted by larry mccay <la...@gmail.com>.
I guess we could make it csrf/x-header - I do allow for a configuration
element to specify a header name other than the default of X-XSRF-Header.
I don't think that the role->common config thing is holding together -
authentication providers will have very different config. Of course, the
fact that they are all filters make the contract the same - but that is the
same across provider roles too.
I'm not totally clear on what you mean by externally defined chains.
To touch on what I had in mind in a little more detail, what I was thinking
was that some filters - like this one - maybe shouldn't have to be
configured explicitly but just enabled through some higher level config
elements. Like at the <gateway> element level. So that we wouldn't need an
actual <provider> element for it.
In the near term, we could just add it as a regular provider with its own
explicit config and we can investigate the external or global/default thing
later into Baikal or beyond.
On Thu, Nov 21, 2013 at 8:10 AM, Kevin Minder
<ke...@hortonworks.com>wrote:
> I this is a symptom of the fact that we don't have externally defined
> chains. I have started working on that but I'm not finding much time these
> days. If we had an external chain definition the role/name thing wouldn't
> mater so much.
>
> That doesn't really answer the question about the role for this. I always
> had it in my head the role identified some sort of a contract such that if
> it were present there would be a consistent set of attributes, subject, etc
> available at runtime and potentially a consistent base-line set of
> understood configuration properties.
>
> This would lead me to think the naming should be something like role=csrf,
> name=default but I'm finding it hard to convince myself that this is the
> right answer. It could be the name=default part. Is there a particular
> technique you use so that it could be csrf/x-header or something. That
> would fit better with the authentication/shiro, dispatch/http-client model.
>
> On 11/21/13 7:36 AM, Larry McCay wrote:
>
>> Hey -
>>
>> I cranked out a simple CSRF prevention provider last night.
>> Trying to figure out whether we want a separate role for it or not.
>>
>> I was thinking that a global or default role - like the default webapp in
>> appservers - could be used to host multiple things like this and that it
>> would essentially be a set of filters that get put in front of
>> authentication/federation.
>>
>> So, this would take the shape of one of a couple options:
>>
>> 1. separate provider modules that get put into the default role and we
>> would have to be able to handle multiple in the same role
>>
>> 2. a single provider module that adds them all. This would likely require
>> the config in topology to be all bunched into a single provider element and
>> so the config names would have to be unique across filters.
>>
>> or, maybe we just give it a csrf role...
>>
>> What do you think?
>>
>> thanks,
>>
>> --lar
>>
>>
>
> --
> CONFIDENTIALITY NOTICE
> NOTICE: This message is intended for the use of the individual or entity
> to which it is addressed and may contain information that is confidential,
> privileged and exempt from disclosure under applicable law. If the reader
> of this message is not the intended recipient, you are hereby notified that
> any printing, copying, dissemination, distribution, disclosure or
> forwarding of this communication is strictly prohibited. If you have
> received this communication in error, please contact the sender immediately
> and delete it from your system. Thank You.
>