You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Josh Holtzman <jh...@berkeley.edu> on 2010/02/18 17:04:27 UTC
Specifying an org.osgi.service.http.HttpContext in DOSGi
DOSGi seems to publish JAX-RS endpoints using a null HttpContext, which
means that the HttpService will create a default context. This makes it
hard to add pluggable authentication handlers using
httpContext.handleSecurity(). Does anyone have suggestions for hooking into
the request before it's sent to the JAX-RS resource methods? I'd prefer to
bind to the OSGI APIs rather than to CXF, and it seems like the httpContext
should be a good way of doing that.
If there isn't a convenient plact to hook in, I suppose I'll have to provide
a custom HttpService that overrides HttpService.createDefaultHttpContext().
Thanks,
Josh
Re: Specifying an org.osgi.service.http.HttpContext in DOSGi
Posted by Josh Holtzman <jh...@berkeley.edu>.
The latest patch is now attached to
https://issues.apache.org/jira/browse/DOSGI-67
Thanks,
Josh
On Sat, Mar 20, 2010 at 4:44 PM, Josh Holtzman <jh...@berkeley.edu>wrote:
> Hi David and Sergey. Since the approach looks right, I'll go ahead and
> generalize the code for use in other kinds of endpoints, and I'll add the
> unit tests and sample code. I should be able to get this done in the next
> few days.
>
> Thanks,
> Josh
>
>
> On Sat, Mar 20, 2010 at 11:34 AM, David Bosschaert <
> david.bosschaert@gmail.com> wrote:
>
>> I also had a look at the patch. While the code looks fine to me I'm
>> concerned that there is no unit tests with it.
>>
>> David
>>
>> On 19 March 2010 14:54, Sergey Beryozkin <sb...@gmail.com> wrote:
>> > Hi Josh
>> >
>> > On Fri, Mar 19, 2010 at 7:09 AM, Josh Holtzman <jholtzman@berkeley.edu
>> >wrote:
>> >
>> >> Hi Sergey,
>> >> The more I think about this, the more I believe that DOSGi is the right
>> >> place to put in a hook for applying security. The ability to apply
>> >> security
>> >> to the DOSGi endpoints should work regardless of the HttpService
>> >> implementation, IMO.
>> >>
>> >> So, I put together a patch that addresses my needs, and I think would
>> be a
>> >> good addition to the DOSGi project in general. See
>> >> https://issues.apache.org/jira/browse/DOSGI-67
>> >>
>> >> The basic approach is this: when registering a CxfNonSpringServlet, a
>> >> DelegatingHttpContext is used to handle security (everything else is
>> >> handled
>> >> with the HttpService's default HttpContext). This HttpContext looks
>> for
>> >> any
>> >> Filters registered with a specific property, builds a filterChain of
>> those
>> >> filters, and allows the request to pass only when the filters have had
>> >> their
>> >> chance at returning an HttpServletResponse.
>> >>
>> >
>> >
>> > S.B : I think it is a good patch and agree it can be a very useful
>> > enhancement in general. I'll try to find some time next week to change
>> it a
>> > bit so that all DOSGI endpoints can get the benefit and apply it. IMHO
>> it
>> > should definitely go to 1.2
>> >
>> >
>> >>
>> >> There's also a switch (BundleContext property
>> >> "org.apache.cxf.rs.httpservice.requirefilter" = true) to force DOSGi
>> >> endpoints to return 403 if there are no filters registered. This way,
>> >> start
>> >> order isn't an issue... DOSGi endpoints only start serving requests
>> when
>> >> the
>> >> security filters are in place.
>> >>
>> >> sounds good
>> >
>> >
>> >> Let me know if you have any concerns about this approach, of if there's
>> >> anything I can do to get this patch into shape.
>> >>
>> >
>> > I have no concerns at all. Hope all DOSGi RI contributors agree this
>> patch
>> > can add some edge to the RI. And if you could at some time add some
>> sample
>> > (by attaching some config, etc to the JIRA) showing how to apply the
>> spring
>> > security to DOSGI endpoints or blog about it then it would be super :-)
>> >
>> > thanks a lot, Sergey
>> >
>> >
>> >>
>> >> Thanks,
>> >> Josh
>> >>
>> >> On Wed, Mar 17, 2010 at 12:06 PM, Sergey Beryozkin <
>> sberyozkin@gmail.com
>> >> >wrote:
>> >>
>> >> > Hi Josh
>> >> >
>> >> > apologies for a late response...
>> >> >
>> >> > On Mon, Mar 15, 2010 at 7:17 PM, Josh Holtzman <
>> jholtzman@berkeley.edu
>> >> > >wrote:
>> >> >
>> >> > > I'm picking up this old thread again in hopes that my use case can
>> be
>> >> > > addressed in CXF. I modified pax-web to look for and, if
>> available,
>> >> use
>> >> > a
>> >> > > custom HttpContext as the default context. I then defined and
>> >> registered
>> >> > > the HttpContext in another bundle. However, CXF isn't able to
>> register
>> >> > > servlets properly using this HttpContext. This might be because
>> that
>> >> > > HttpContext can't properly implement the "public URL
>> getResource(String
>> >> > > name)" method, since it doesn't have access to the right
>> classloader.
>> >> > >
>> >> >
>> >> > S.B : it is probably a better solution, having pax-web checking for a
>> >> > custom
>> >> > HttpContext...But the problem you're seeing with a custom one could
>> show
>> >> up
>> >> > even if CXF detects a custom context, as suggested earlier on. Do you
>> see
>> >> > some stack trace from CXf DSW or paxweb reporting some exception ?
>> >> >
>> >> >
>> >> > > So I'm going to ask my question in a slightly different way in
>> hopes
>> >> that
>> >> > > the details of this experiment don't send us off track: if you
>> needed
>> >> to
>> >> > > apply spring security filters to all DOSGi endpoints, how would you
>> do
>> >> > it?
>> >> > >
>> >> > >
>> >> > S.B. My limited experience with SpringSecurity tells me a CXF servlet
>> >> > should
>> >> > have a Spring security filter for a start, is it possible to set up
>> >> pax-web
>> >> > such that adds a filter to all servlets ?
>> >> > Next, you can probably register a Spring DM context and rely on the
>> >> > URI-related Spring Security configuration
>> >> >
>> >> > Let us know please how it goes on...
>> >> >
>> >> > thanks, Sergey
>> >> >
>> >> >
>> >> > > Thanks,
>> >> > > Josh
>> >> > >
>> >> > > On Thu, Feb 18, 2010 at 10:30 AM, Josh Holtzman <
>> >> jholtzman@berkeley.edu
>> >> > > >wrote:
>> >> > >
>> >> > > > Checking the osgi service registry for a custom HttpContext makes
>> >> sense
>> >> > > to
>> >> > > > me, but it introduces a startup order problem. If CXF can handle
>> >> that,
>> >> > > then
>> >> > > > we're in good shape.
>> >> > > >
>> >> > > > I'll have a look at pax web to see what I can do there in the
>> >> meantime.
>> >> > > >
>> >> > > > Thanks,
>> >> > > > Josh
>> >> > > >
>> >> > > >
>> >> > > > On Thu, Feb 18, 2010 at 8:35 AM, Sergey Beryozkin <
>> >> > sberyozk@progress.com
>> >> > > >wrote:
>> >> > > >
>> >> > > >> Hi Josh
>> >> > > >>
>> >> > > >> We've chatted with David a bit about it...
>> >> > > >> Are you actually proposing for CXF DSW to check for a custom
>> >> > HttpContext
>> >> > > >> implementation registered as an OSGI Service ? It would make
>> >> > sense...It
>> >> > > >> would probaly make sense to have an additional list property
>> passed
>> >> > > along
>> >> > > >> during the custom HttpContext registration, which will list
>> custom
>> >> > > >> interfaces (possibly with wildcards) and which CXF DSW will
>> check to
>> >> > > ensure
>> >> > > >> it does not attach a 'foreign' HttpContext to a given servlet
>> >> > > endpoint...
>> >> > > >>
>> >> > > >> In meantime, may be paxweb can let users specify a custom
>> >> HttpContext
>> >> > in
>> >> > > >> the system properties which it will use instead of the default
>> impl
>> >> ?
>> >> > If
>> >> > > it
>> >> > > >> were possible then it could help till the proper fix goes in.
>> >> > > >>
>> >> > > >> Cheers, Sergey
>> >> > > >>
>> >> > > >>
>> >> > > >> DOSGi seems to publish JAX-RS endpoints using a null
>> HttpContext,
>> >> > which
>> >> > > >>> means that the HttpService will create a default context. This
>> >> makes
>> >> > > it
>> >> > > >>> hard to add pluggable authentication handlers using
>> >> > > >>> httpContext.handleSecurity(). Does anyone have suggestions for
>> >> > hooking
>> >> > > >>> into
>> >> > > >>> the request before it's sent to the JAX-RS resource methods?
>> I'd
>> >> > > prefer
>> >> > > >>> to
>> >> > > >>> bind to the OSGI APIs rather than to CXF, and it seems like the
>> >> > > >>> httpContext
>> >> > > >>> should be a good way of doing that.
>> >> > > >>>
>> >> > > >>> If there isn't a convenient plact to hook in, I suppose I'll
>> have
>> >> to
>> >> > > >>> provide
>> >> > > >>> a custom HttpService that overrides
>> >> > > >>> HttpService.createDefaultHttpContext().
>> >> > > >>>
>> >> > > >>> Thanks,
>> >> > > >>> Josh
>> >> > > >>>
>> >> > > >>>
>> >> > > >>
>> >> > > >
>> >> > >
>> >> >
>> >>
>> >
>>
>
>
Re: Specifying an org.osgi.service.http.HttpContext in DOSGi
Posted by Josh Holtzman <jh...@berkeley.edu>.
Hi David and Sergey. Since the approach looks right, I'll go ahead and
generalize the code for use in other kinds of endpoints, and I'll add the
unit tests and sample code. I should be able to get this done in the next
few days.
Thanks,
Josh
On Sat, Mar 20, 2010 at 11:34 AM, David Bosschaert <
david.bosschaert@gmail.com> wrote:
> I also had a look at the patch. While the code looks fine to me I'm
> concerned that there is no unit tests with it.
>
> David
>
> On 19 March 2010 14:54, Sergey Beryozkin <sb...@gmail.com> wrote:
> > Hi Josh
> >
> > On Fri, Mar 19, 2010 at 7:09 AM, Josh Holtzman <jholtzman@berkeley.edu
> >wrote:
> >
> >> Hi Sergey,
> >> The more I think about this, the more I believe that DOSGi is the right
> >> place to put in a hook for applying security. The ability to apply
> >> security
> >> to the DOSGi endpoints should work regardless of the HttpService
> >> implementation, IMO.
> >>
> >> So, I put together a patch that addresses my needs, and I think would be
> a
> >> good addition to the DOSGi project in general. See
> >> https://issues.apache.org/jira/browse/DOSGI-67
> >>
> >> The basic approach is this: when registering a CxfNonSpringServlet, a
> >> DelegatingHttpContext is used to handle security (everything else is
> >> handled
> >> with the HttpService's default HttpContext). This HttpContext looks for
> >> any
> >> Filters registered with a specific property, builds a filterChain of
> those
> >> filters, and allows the request to pass only when the filters have had
> >> their
> >> chance at returning an HttpServletResponse.
> >>
> >
> >
> > S.B : I think it is a good patch and agree it can be a very useful
> > enhancement in general. I'll try to find some time next week to change it
> a
> > bit so that all DOSGI endpoints can get the benefit and apply it. IMHO it
> > should definitely go to 1.2
> >
> >
> >>
> >> There's also a switch (BundleContext property
> >> "org.apache.cxf.rs.httpservice.requirefilter" = true) to force DOSGi
> >> endpoints to return 403 if there are no filters registered. This way,
> >> start
> >> order isn't an issue... DOSGi endpoints only start serving requests when
> >> the
> >> security filters are in place.
> >>
> >> sounds good
> >
> >
> >> Let me know if you have any concerns about this approach, of if there's
> >> anything I can do to get this patch into shape.
> >>
> >
> > I have no concerns at all. Hope all DOSGi RI contributors agree this
> patch
> > can add some edge to the RI. And if you could at some time add some
> sample
> > (by attaching some config, etc to the JIRA) showing how to apply the
> spring
> > security to DOSGI endpoints or blog about it then it would be super :-)
> >
> > thanks a lot, Sergey
> >
> >
> >>
> >> Thanks,
> >> Josh
> >>
> >> On Wed, Mar 17, 2010 at 12:06 PM, Sergey Beryozkin <
> sberyozkin@gmail.com
> >> >wrote:
> >>
> >> > Hi Josh
> >> >
> >> > apologies for a late response...
> >> >
> >> > On Mon, Mar 15, 2010 at 7:17 PM, Josh Holtzman <
> jholtzman@berkeley.edu
> >> > >wrote:
> >> >
> >> > > I'm picking up this old thread again in hopes that my use case can
> be
> >> > > addressed in CXF. I modified pax-web to look for and, if available,
> >> use
> >> > a
> >> > > custom HttpContext as the default context. I then defined and
> >> registered
> >> > > the HttpContext in another bundle. However, CXF isn't able to
> register
> >> > > servlets properly using this HttpContext. This might be because
> that
> >> > > HttpContext can't properly implement the "public URL
> getResource(String
> >> > > name)" method, since it doesn't have access to the right
> classloader.
> >> > >
> >> >
> >> > S.B : it is probably a better solution, having pax-web checking for a
> >> > custom
> >> > HttpContext...But the problem you're seeing with a custom one could
> show
> >> up
> >> > even if CXF detects a custom context, as suggested earlier on. Do you
> see
> >> > some stack trace from CXf DSW or paxweb reporting some exception ?
> >> >
> >> >
> >> > > So I'm going to ask my question in a slightly different way in hopes
> >> that
> >> > > the details of this experiment don't send us off track: if you
> needed
> >> to
> >> > > apply spring security filters to all DOSGi endpoints, how would you
> do
> >> > it?
> >> > >
> >> > >
> >> > S.B. My limited experience with SpringSecurity tells me a CXF servlet
> >> > should
> >> > have a Spring security filter for a start, is it possible to set up
> >> pax-web
> >> > such that adds a filter to all servlets ?
> >> > Next, you can probably register a Spring DM context and rely on the
> >> > URI-related Spring Security configuration
> >> >
> >> > Let us know please how it goes on...
> >> >
> >> > thanks, Sergey
> >> >
> >> >
> >> > > Thanks,
> >> > > Josh
> >> > >
> >> > > On Thu, Feb 18, 2010 at 10:30 AM, Josh Holtzman <
> >> jholtzman@berkeley.edu
> >> > > >wrote:
> >> > >
> >> > > > Checking the osgi service registry for a custom HttpContext makes
> >> sense
> >> > > to
> >> > > > me, but it introduces a startup order problem. If CXF can handle
> >> that,
> >> > > then
> >> > > > we're in good shape.
> >> > > >
> >> > > > I'll have a look at pax web to see what I can do there in the
> >> meantime.
> >> > > >
> >> > > > Thanks,
> >> > > > Josh
> >> > > >
> >> > > >
> >> > > > On Thu, Feb 18, 2010 at 8:35 AM, Sergey Beryozkin <
> >> > sberyozk@progress.com
> >> > > >wrote:
> >> > > >
> >> > > >> Hi Josh
> >> > > >>
> >> > > >> We've chatted with David a bit about it...
> >> > > >> Are you actually proposing for CXF DSW to check for a custom
> >> > HttpContext
> >> > > >> implementation registered as an OSGI Service ? It would make
> >> > sense...It
> >> > > >> would probaly make sense to have an additional list property
> passed
> >> > > along
> >> > > >> during the custom HttpContext registration, which will list
> custom
> >> > > >> interfaces (possibly with wildcards) and which CXF DSW will check
> to
> >> > > ensure
> >> > > >> it does not attach a 'foreign' HttpContext to a given servlet
> >> > > endpoint...
> >> > > >>
> >> > > >> In meantime, may be paxweb can let users specify a custom
> >> HttpContext
> >> > in
> >> > > >> the system properties which it will use instead of the default
> impl
> >> ?
> >> > If
> >> > > it
> >> > > >> were possible then it could help till the proper fix goes in.
> >> > > >>
> >> > > >> Cheers, Sergey
> >> > > >>
> >> > > >>
> >> > > >> DOSGi seems to publish JAX-RS endpoints using a null
> HttpContext,
> >> > which
> >> > > >>> means that the HttpService will create a default context. This
> >> makes
> >> > > it
> >> > > >>> hard to add pluggable authentication handlers using
> >> > > >>> httpContext.handleSecurity(). Does anyone have suggestions for
> >> > hooking
> >> > > >>> into
> >> > > >>> the request before it's sent to the JAX-RS resource methods?
> I'd
> >> > > prefer
> >> > > >>> to
> >> > > >>> bind to the OSGI APIs rather than to CXF, and it seems like the
> >> > > >>> httpContext
> >> > > >>> should be a good way of doing that.
> >> > > >>>
> >> > > >>> If there isn't a convenient plact to hook in, I suppose I'll
> have
> >> to
> >> > > >>> provide
> >> > > >>> a custom HttpService that overrides
> >> > > >>> HttpService.createDefaultHttpContext().
> >> > > >>>
> >> > > >>> Thanks,
> >> > > >>> Josh
> >> > > >>>
> >> > > >>>
> >> > > >>
> >> > > >
> >> > >
> >> >
> >>
> >
>
Re: Specifying an org.osgi.service.http.HttpContext in DOSGi
Posted by David Bosschaert <da...@gmail.com>.
I also had a look at the patch. While the code looks fine to me I'm
concerned that there is no unit tests with it.
David
On 19 March 2010 14:54, Sergey Beryozkin <sb...@gmail.com> wrote:
> Hi Josh
>
> On Fri, Mar 19, 2010 at 7:09 AM, Josh Holtzman <jh...@berkeley.edu>wrote:
>
>> Hi Sergey,
>> The more I think about this, the more I believe that DOSGi is the right
>> place to put in a hook for applying security. The ability to apply
>> security
>> to the DOSGi endpoints should work regardless of the HttpService
>> implementation, IMO.
>>
>> So, I put together a patch that addresses my needs, and I think would be a
>> good addition to the DOSGi project in general. See
>> https://issues.apache.org/jira/browse/DOSGI-67
>>
>> The basic approach is this: when registering a CxfNonSpringServlet, a
>> DelegatingHttpContext is used to handle security (everything else is
>> handled
>> with the HttpService's default HttpContext). This HttpContext looks for
>> any
>> Filters registered with a specific property, builds a filterChain of those
>> filters, and allows the request to pass only when the filters have had
>> their
>> chance at returning an HttpServletResponse.
>>
>
>
> S.B : I think it is a good patch and agree it can be a very useful
> enhancement in general. I'll try to find some time next week to change it a
> bit so that all DOSGI endpoints can get the benefit and apply it. IMHO it
> should definitely go to 1.2
>
>
>>
>> There's also a switch (BundleContext property
>> "org.apache.cxf.rs.httpservice.requirefilter" = true) to force DOSGi
>> endpoints to return 403 if there are no filters registered. This way,
>> start
>> order isn't an issue... DOSGi endpoints only start serving requests when
>> the
>> security filters are in place.
>>
>> sounds good
>
>
>> Let me know if you have any concerns about this approach, of if there's
>> anything I can do to get this patch into shape.
>>
>
> I have no concerns at all. Hope all DOSGi RI contributors agree this patch
> can add some edge to the RI. And if you could at some time add some sample
> (by attaching some config, etc to the JIRA) showing how to apply the spring
> security to DOSGI endpoints or blog about it then it would be super :-)
>
> thanks a lot, Sergey
>
>
>>
>> Thanks,
>> Josh
>>
>> On Wed, Mar 17, 2010 at 12:06 PM, Sergey Beryozkin <sberyozkin@gmail.com
>> >wrote:
>>
>> > Hi Josh
>> >
>> > apologies for a late response...
>> >
>> > On Mon, Mar 15, 2010 at 7:17 PM, Josh Holtzman <jholtzman@berkeley.edu
>> > >wrote:
>> >
>> > > I'm picking up this old thread again in hopes that my use case can be
>> > > addressed in CXF. I modified pax-web to look for and, if available,
>> use
>> > a
>> > > custom HttpContext as the default context. I then defined and
>> registered
>> > > the HttpContext in another bundle. However, CXF isn't able to register
>> > > servlets properly using this HttpContext. This might be because that
>> > > HttpContext can't properly implement the "public URL getResource(String
>> > > name)" method, since it doesn't have access to the right classloader.
>> > >
>> >
>> > S.B : it is probably a better solution, having pax-web checking for a
>> > custom
>> > HttpContext...But the problem you're seeing with a custom one could show
>> up
>> > even if CXF detects a custom context, as suggested earlier on. Do you see
>> > some stack trace from CXf DSW or paxweb reporting some exception ?
>> >
>> >
>> > > So I'm going to ask my question in a slightly different way in hopes
>> that
>> > > the details of this experiment don't send us off track: if you needed
>> to
>> > > apply spring security filters to all DOSGi endpoints, how would you do
>> > it?
>> > >
>> > >
>> > S.B. My limited experience with SpringSecurity tells me a CXF servlet
>> > should
>> > have a Spring security filter for a start, is it possible to set up
>> pax-web
>> > such that adds a filter to all servlets ?
>> > Next, you can probably register a Spring DM context and rely on the
>> > URI-related Spring Security configuration
>> >
>> > Let us know please how it goes on...
>> >
>> > thanks, Sergey
>> >
>> >
>> > > Thanks,
>> > > Josh
>> > >
>> > > On Thu, Feb 18, 2010 at 10:30 AM, Josh Holtzman <
>> jholtzman@berkeley.edu
>> > > >wrote:
>> > >
>> > > > Checking the osgi service registry for a custom HttpContext makes
>> sense
>> > > to
>> > > > me, but it introduces a startup order problem. If CXF can handle
>> that,
>> > > then
>> > > > we're in good shape.
>> > > >
>> > > > I'll have a look at pax web to see what I can do there in the
>> meantime.
>> > > >
>> > > > Thanks,
>> > > > Josh
>> > > >
>> > > >
>> > > > On Thu, Feb 18, 2010 at 8:35 AM, Sergey Beryozkin <
>> > sberyozk@progress.com
>> > > >wrote:
>> > > >
>> > > >> Hi Josh
>> > > >>
>> > > >> We've chatted with David a bit about it...
>> > > >> Are you actually proposing for CXF DSW to check for a custom
>> > HttpContext
>> > > >> implementation registered as an OSGI Service ? It would make
>> > sense...It
>> > > >> would probaly make sense to have an additional list property passed
>> > > along
>> > > >> during the custom HttpContext registration, which will list custom
>> > > >> interfaces (possibly with wildcards) and which CXF DSW will check to
>> > > ensure
>> > > >> it does not attach a 'foreign' HttpContext to a given servlet
>> > > endpoint...
>> > > >>
>> > > >> In meantime, may be paxweb can let users specify a custom
>> HttpContext
>> > in
>> > > >> the system properties which it will use instead of the default impl
>> ?
>> > If
>> > > it
>> > > >> were possible then it could help till the proper fix goes in.
>> > > >>
>> > > >> Cheers, Sergey
>> > > >>
>> > > >>
>> > > >> DOSGi seems to publish JAX-RS endpoints using a null HttpContext,
>> > which
>> > > >>> means that the HttpService will create a default context. This
>> makes
>> > > it
>> > > >>> hard to add pluggable authentication handlers using
>> > > >>> httpContext.handleSecurity(). Does anyone have suggestions for
>> > hooking
>> > > >>> into
>> > > >>> the request before it's sent to the JAX-RS resource methods? I'd
>> > > prefer
>> > > >>> to
>> > > >>> bind to the OSGI APIs rather than to CXF, and it seems like the
>> > > >>> httpContext
>> > > >>> should be a good way of doing that.
>> > > >>>
>> > > >>> If there isn't a convenient plact to hook in, I suppose I'll have
>> to
>> > > >>> provide
>> > > >>> a custom HttpService that overrides
>> > > >>> HttpService.createDefaultHttpContext().
>> > > >>>
>> > > >>> Thanks,
>> > > >>> Josh
>> > > >>>
>> > > >>>
>> > > >>
>> > > >
>> > >
>> >
>>
>
Re: Specifying an org.osgi.service.http.HttpContext in DOSGi
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi Josh
On Fri, Mar 19, 2010 at 7:09 AM, Josh Holtzman <jh...@berkeley.edu>wrote:
> Hi Sergey,
> The more I think about this, the more I believe that DOSGi is the right
> place to put in a hook for applying security. The ability to apply
> security
> to the DOSGi endpoints should work regardless of the HttpService
> implementation, IMO.
>
> So, I put together a patch that addresses my needs, and I think would be a
> good addition to the DOSGi project in general. See
> https://issues.apache.org/jira/browse/DOSGI-67
>
> The basic approach is this: when registering a CxfNonSpringServlet, a
> DelegatingHttpContext is used to handle security (everything else is
> handled
> with the HttpService's default HttpContext). This HttpContext looks for
> any
> Filters registered with a specific property, builds a filterChain of those
> filters, and allows the request to pass only when the filters have had
> their
> chance at returning an HttpServletResponse.
>
S.B : I think it is a good patch and agree it can be a very useful
enhancement in general. I'll try to find some time next week to change it a
bit so that all DOSGI endpoints can get the benefit and apply it. IMHO it
should definitely go to 1.2
>
> There's also a switch (BundleContext property
> "org.apache.cxf.rs.httpservice.requirefilter" = true) to force DOSGi
> endpoints to return 403 if there are no filters registered. This way,
> start
> order isn't an issue... DOSGi endpoints only start serving requests when
> the
> security filters are in place.
>
> sounds good
> Let me know if you have any concerns about this approach, of if there's
> anything I can do to get this patch into shape.
>
I have no concerns at all. Hope all DOSGi RI contributors agree this patch
can add some edge to the RI. And if you could at some time add some sample
(by attaching some config, etc to the JIRA) showing how to apply the spring
security to DOSGI endpoints or blog about it then it would be super :-)
thanks a lot, Sergey
>
> Thanks,
> Josh
>
> On Wed, Mar 17, 2010 at 12:06 PM, Sergey Beryozkin <sberyozkin@gmail.com
> >wrote:
>
> > Hi Josh
> >
> > apologies for a late response...
> >
> > On Mon, Mar 15, 2010 at 7:17 PM, Josh Holtzman <jholtzman@berkeley.edu
> > >wrote:
> >
> > > I'm picking up this old thread again in hopes that my use case can be
> > > addressed in CXF. I modified pax-web to look for and, if available,
> use
> > a
> > > custom HttpContext as the default context. I then defined and
> registered
> > > the HttpContext in another bundle. However, CXF isn't able to register
> > > servlets properly using this HttpContext. This might be because that
> > > HttpContext can't properly implement the "public URL getResource(String
> > > name)" method, since it doesn't have access to the right classloader.
> > >
> >
> > S.B : it is probably a better solution, having pax-web checking for a
> > custom
> > HttpContext...But the problem you're seeing with a custom one could show
> up
> > even if CXF detects a custom context, as suggested earlier on. Do you see
> > some stack trace from CXf DSW or paxweb reporting some exception ?
> >
> >
> > > So I'm going to ask my question in a slightly different way in hopes
> that
> > > the details of this experiment don't send us off track: if you needed
> to
> > > apply spring security filters to all DOSGi endpoints, how would you do
> > it?
> > >
> > >
> > S.B. My limited experience with SpringSecurity tells me a CXF servlet
> > should
> > have a Spring security filter for a start, is it possible to set up
> pax-web
> > such that adds a filter to all servlets ?
> > Next, you can probably register a Spring DM context and rely on the
> > URI-related Spring Security configuration
> >
> > Let us know please how it goes on...
> >
> > thanks, Sergey
> >
> >
> > > Thanks,
> > > Josh
> > >
> > > On Thu, Feb 18, 2010 at 10:30 AM, Josh Holtzman <
> jholtzman@berkeley.edu
> > > >wrote:
> > >
> > > > Checking the osgi service registry for a custom HttpContext makes
> sense
> > > to
> > > > me, but it introduces a startup order problem. If CXF can handle
> that,
> > > then
> > > > we're in good shape.
> > > >
> > > > I'll have a look at pax web to see what I can do there in the
> meantime.
> > > >
> > > > Thanks,
> > > > Josh
> > > >
> > > >
> > > > On Thu, Feb 18, 2010 at 8:35 AM, Sergey Beryozkin <
> > sberyozk@progress.com
> > > >wrote:
> > > >
> > > >> Hi Josh
> > > >>
> > > >> We've chatted with David a bit about it...
> > > >> Are you actually proposing for CXF DSW to check for a custom
> > HttpContext
> > > >> implementation registered as an OSGI Service ? It would make
> > sense...It
> > > >> would probaly make sense to have an additional list property passed
> > > along
> > > >> during the custom HttpContext registration, which will list custom
> > > >> interfaces (possibly with wildcards) and which CXF DSW will check to
> > > ensure
> > > >> it does not attach a 'foreign' HttpContext to a given servlet
> > > endpoint...
> > > >>
> > > >> In meantime, may be paxweb can let users specify a custom
> HttpContext
> > in
> > > >> the system properties which it will use instead of the default impl
> ?
> > If
> > > it
> > > >> were possible then it could help till the proper fix goes in.
> > > >>
> > > >> Cheers, Sergey
> > > >>
> > > >>
> > > >> DOSGi seems to publish JAX-RS endpoints using a null HttpContext,
> > which
> > > >>> means that the HttpService will create a default context. This
> makes
> > > it
> > > >>> hard to add pluggable authentication handlers using
> > > >>> httpContext.handleSecurity(). Does anyone have suggestions for
> > hooking
> > > >>> into
> > > >>> the request before it's sent to the JAX-RS resource methods? I'd
> > > prefer
> > > >>> to
> > > >>> bind to the OSGI APIs rather than to CXF, and it seems like the
> > > >>> httpContext
> > > >>> should be a good way of doing that.
> > > >>>
> > > >>> If there isn't a convenient plact to hook in, I suppose I'll have
> to
> > > >>> provide
> > > >>> a custom HttpService that overrides
> > > >>> HttpService.createDefaultHttpContext().
> > > >>>
> > > >>> Thanks,
> > > >>> Josh
> > > >>>
> > > >>>
> > > >>
> > > >
> > >
> >
>
Re: Specifying an org.osgi.service.http.HttpContext in DOSGi
Posted by Josh Holtzman <jh...@berkeley.edu>.
Hi Sergey,
The more I think about this, the more I believe that DOSGi is the right
place to put in a hook for applying security. The ability to apply security
to the DOSGi endpoints should work regardless of the HttpService
implementation, IMO.
So, I put together a patch that addresses my needs, and I think would be a
good addition to the DOSGi project in general. See
https://issues.apache.org/jira/browse/DOSGI-67
The basic approach is this: when registering a CxfNonSpringServlet, a
DelegatingHttpContext is used to handle security (everything else is handled
with the HttpService's default HttpContext). This HttpContext looks for any
Filters registered with a specific property, builds a filterChain of those
filters, and allows the request to pass only when the filters have had their
chance at returning an HttpServletResponse.
There's also a switch (BundleContext property
"org.apache.cxf.rs.httpservice.requirefilter" = true) to force DOSGi
endpoints to return 403 if there are no filters registered. This way, start
order isn't an issue... DOSGi endpoints only start serving requests when the
security filters are in place.
Let me know if you have any concerns about this approach, of if there's
anything I can do to get this patch into shape.
Thanks,
Josh
On Wed, Mar 17, 2010 at 12:06 PM, Sergey Beryozkin <sb...@gmail.com>wrote:
> Hi Josh
>
> apologies for a late response...
>
> On Mon, Mar 15, 2010 at 7:17 PM, Josh Holtzman <jholtzman@berkeley.edu
> >wrote:
>
> > I'm picking up this old thread again in hopes that my use case can be
> > addressed in CXF. I modified pax-web to look for and, if available, use
> a
> > custom HttpContext as the default context. I then defined and registered
> > the HttpContext in another bundle. However, CXF isn't able to register
> > servlets properly using this HttpContext. This might be because that
> > HttpContext can't properly implement the "public URL getResource(String
> > name)" method, since it doesn't have access to the right classloader.
> >
>
> S.B : it is probably a better solution, having pax-web checking for a
> custom
> HttpContext...But the problem you're seeing with a custom one could show up
> even if CXF detects a custom context, as suggested earlier on. Do you see
> some stack trace from CXf DSW or paxweb reporting some exception ?
>
>
> > So I'm going to ask my question in a slightly different way in hopes that
> > the details of this experiment don't send us off track: if you needed to
> > apply spring security filters to all DOSGi endpoints, how would you do
> it?
> >
> >
> S.B. My limited experience with SpringSecurity tells me a CXF servlet
> should
> have a Spring security filter for a start, is it possible to set up pax-web
> such that adds a filter to all servlets ?
> Next, you can probably register a Spring DM context and rely on the
> URI-related Spring Security configuration
>
> Let us know please how it goes on...
>
> thanks, Sergey
>
>
> > Thanks,
> > Josh
> >
> > On Thu, Feb 18, 2010 at 10:30 AM, Josh Holtzman <jholtzman@berkeley.edu
> > >wrote:
> >
> > > Checking the osgi service registry for a custom HttpContext makes sense
> > to
> > > me, but it introduces a startup order problem. If CXF can handle that,
> > then
> > > we're in good shape.
> > >
> > > I'll have a look at pax web to see what I can do there in the meantime.
> > >
> > > Thanks,
> > > Josh
> > >
> > >
> > > On Thu, Feb 18, 2010 at 8:35 AM, Sergey Beryozkin <
> sberyozk@progress.com
> > >wrote:
> > >
> > >> Hi Josh
> > >>
> > >> We've chatted with David a bit about it...
> > >> Are you actually proposing for CXF DSW to check for a custom
> HttpContext
> > >> implementation registered as an OSGI Service ? It would make
> sense...It
> > >> would probaly make sense to have an additional list property passed
> > along
> > >> during the custom HttpContext registration, which will list custom
> > >> interfaces (possibly with wildcards) and which CXF DSW will check to
> > ensure
> > >> it does not attach a 'foreign' HttpContext to a given servlet
> > endpoint...
> > >>
> > >> In meantime, may be paxweb can let users specify a custom HttpContext
> in
> > >> the system properties which it will use instead of the default impl ?
> If
> > it
> > >> were possible then it could help till the proper fix goes in.
> > >>
> > >> Cheers, Sergey
> > >>
> > >>
> > >> DOSGi seems to publish JAX-RS endpoints using a null HttpContext,
> which
> > >>> means that the HttpService will create a default context. This makes
> > it
> > >>> hard to add pluggable authentication handlers using
> > >>> httpContext.handleSecurity(). Does anyone have suggestions for
> hooking
> > >>> into
> > >>> the request before it's sent to the JAX-RS resource methods? I'd
> > prefer
> > >>> to
> > >>> bind to the OSGI APIs rather than to CXF, and it seems like the
> > >>> httpContext
> > >>> should be a good way of doing that.
> > >>>
> > >>> If there isn't a convenient plact to hook in, I suppose I'll have to
> > >>> provide
> > >>> a custom HttpService that overrides
> > >>> HttpService.createDefaultHttpContext().
> > >>>
> > >>> Thanks,
> > >>> Josh
> > >>>
> > >>>
> > >>
> > >
> >
>
Re: Specifying an org.osgi.service.http.HttpContext in DOSGi
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi Josh
apologies for a late response...
On Mon, Mar 15, 2010 at 7:17 PM, Josh Holtzman <jh...@berkeley.edu>wrote:
> I'm picking up this old thread again in hopes that my use case can be
> addressed in CXF. I modified pax-web to look for and, if available, use a
> custom HttpContext as the default context. I then defined and registered
> the HttpContext in another bundle. However, CXF isn't able to register
> servlets properly using this HttpContext. This might be because that
> HttpContext can't properly implement the "public URL getResource(String
> name)" method, since it doesn't have access to the right classloader.
>
S.B : it is probably a better solution, having pax-web checking for a custom
HttpContext...But the problem you're seeing with a custom one could show up
even if CXF detects a custom context, as suggested earlier on. Do you see
some stack trace from CXf DSW or paxweb reporting some exception ?
> So I'm going to ask my question in a slightly different way in hopes that
> the details of this experiment don't send us off track: if you needed to
> apply spring security filters to all DOSGi endpoints, how would you do it?
>
>
S.B. My limited experience with SpringSecurity tells me a CXF servlet should
have a Spring security filter for a start, is it possible to set up pax-web
such that adds a filter to all servlets ?
Next, you can probably register a Spring DM context and rely on the
URI-related Spring Security configuration
Let us know please how it goes on...
thanks, Sergey
> Thanks,
> Josh
>
> On Thu, Feb 18, 2010 at 10:30 AM, Josh Holtzman <jholtzman@berkeley.edu
> >wrote:
>
> > Checking the osgi service registry for a custom HttpContext makes sense
> to
> > me, but it introduces a startup order problem. If CXF can handle that,
> then
> > we're in good shape.
> >
> > I'll have a look at pax web to see what I can do there in the meantime.
> >
> > Thanks,
> > Josh
> >
> >
> > On Thu, Feb 18, 2010 at 8:35 AM, Sergey Beryozkin <sberyozk@progress.com
> >wrote:
> >
> >> Hi Josh
> >>
> >> We've chatted with David a bit about it...
> >> Are you actually proposing for CXF DSW to check for a custom HttpContext
> >> implementation registered as an OSGI Service ? It would make sense...It
> >> would probaly make sense to have an additional list property passed
> along
> >> during the custom HttpContext registration, which will list custom
> >> interfaces (possibly with wildcards) and which CXF DSW will check to
> ensure
> >> it does not attach a 'foreign' HttpContext to a given servlet
> endpoint...
> >>
> >> In meantime, may be paxweb can let users specify a custom HttpContext in
> >> the system properties which it will use instead of the default impl ? If
> it
> >> were possible then it could help till the proper fix goes in.
> >>
> >> Cheers, Sergey
> >>
> >>
> >> DOSGi seems to publish JAX-RS endpoints using a null HttpContext, which
> >>> means that the HttpService will create a default context. This makes
> it
> >>> hard to add pluggable authentication handlers using
> >>> httpContext.handleSecurity(). Does anyone have suggestions for hooking
> >>> into
> >>> the request before it's sent to the JAX-RS resource methods? I'd
> prefer
> >>> to
> >>> bind to the OSGI APIs rather than to CXF, and it seems like the
> >>> httpContext
> >>> should be a good way of doing that.
> >>>
> >>> If there isn't a convenient plact to hook in, I suppose I'll have to
> >>> provide
> >>> a custom HttpService that overrides
> >>> HttpService.createDefaultHttpContext().
> >>>
> >>> Thanks,
> >>> Josh
> >>>
> >>>
> >>
> >
>
Re: Specifying an org.osgi.service.http.HttpContext in DOSGi
Posted by Josh Holtzman <jh...@berkeley.edu>.
I'm picking up this old thread again in hopes that my use case can be
addressed in CXF. I modified pax-web to look for and, if available, use a
custom HttpContext as the default context. I then defined and registered
the HttpContext in another bundle. However, CXF isn't able to register
servlets properly using this HttpContext. This might be because that
HttpContext can't properly implement the "public URL getResource(String
name)" method, since it doesn't have access to the right classloader.
So I'm going to ask my question in a slightly different way in hopes that
the details of this experiment don't send us off track: if you needed to
apply spring security filters to all DOSGi endpoints, how would you do it?
Thanks,
Josh
On Thu, Feb 18, 2010 at 10:30 AM, Josh Holtzman <jh...@berkeley.edu>wrote:
> Checking the osgi service registry for a custom HttpContext makes sense to
> me, but it introduces a startup order problem. If CXF can handle that, then
> we're in good shape.
>
> I'll have a look at pax web to see what I can do there in the meantime.
>
> Thanks,
> Josh
>
>
> On Thu, Feb 18, 2010 at 8:35 AM, Sergey Beryozkin <sb...@progress.com>wrote:
>
>> Hi Josh
>>
>> We've chatted with David a bit about it...
>> Are you actually proposing for CXF DSW to check for a custom HttpContext
>> implementation registered as an OSGI Service ? It would make sense...It
>> would probaly make sense to have an additional list property passed along
>> during the custom HttpContext registration, which will list custom
>> interfaces (possibly with wildcards) and which CXF DSW will check to ensure
>> it does not attach a 'foreign' HttpContext to a given servlet endpoint...
>>
>> In meantime, may be paxweb can let users specify a custom HttpContext in
>> the system properties which it will use instead of the default impl ? If it
>> were possible then it could help till the proper fix goes in.
>>
>> Cheers, Sergey
>>
>>
>> DOSGi seems to publish JAX-RS endpoints using a null HttpContext, which
>>> means that the HttpService will create a default context. This makes it
>>> hard to add pluggable authentication handlers using
>>> httpContext.handleSecurity(). Does anyone have suggestions for hooking
>>> into
>>> the request before it's sent to the JAX-RS resource methods? I'd prefer
>>> to
>>> bind to the OSGI APIs rather than to CXF, and it seems like the
>>> httpContext
>>> should be a good way of doing that.
>>>
>>> If there isn't a convenient plact to hook in, I suppose I'll have to
>>> provide
>>> a custom HttpService that overrides
>>> HttpService.createDefaultHttpContext().
>>>
>>> Thanks,
>>> Josh
>>>
>>>
>>
>
Re: Specifying an org.osgi.service.http.HttpContext in DOSGi
Posted by Josh Holtzman <jh...@berkeley.edu>.
Checking the osgi service registry for a custom HttpContext makes sense to
me, but it introduces a startup order problem. If CXF can handle that, then
we're in good shape.
I'll have a look at pax web to see what I can do there in the meantime.
Thanks,
Josh
On Thu, Feb 18, 2010 at 8:35 AM, Sergey Beryozkin <sb...@progress.com>wrote:
> Hi Josh
>
> We've chatted with David a bit about it...
> Are you actually proposing for CXF DSW to check for a custom HttpContext
> implementation registered as an OSGI Service ? It would make sense...It
> would probaly make sense to have an additional list property passed along
> during the custom HttpContext registration, which will list custom
> interfaces (possibly with wildcards) and which CXF DSW will check to ensure
> it does not attach a 'foreign' HttpContext to a given servlet endpoint...
>
> In meantime, may be paxweb can let users specify a custom HttpContext in
> the system properties which it will use instead of the default impl ? If it
> were possible then it could help till the proper fix goes in.
>
> Cheers, Sergey
>
>
> DOSGi seems to publish JAX-RS endpoints using a null HttpContext, which
>> means that the HttpService will create a default context. This makes it
>> hard to add pluggable authentication handlers using
>> httpContext.handleSecurity(). Does anyone have suggestions for hooking
>> into
>> the request before it's sent to the JAX-RS resource methods? I'd prefer
>> to
>> bind to the OSGI APIs rather than to CXF, and it seems like the
>> httpContext
>> should be a good way of doing that.
>>
>> If there isn't a convenient plact to hook in, I suppose I'll have to
>> provide
>> a custom HttpService that overrides
>> HttpService.createDefaultHttpContext().
>>
>> Thanks,
>> Josh
>>
>>
>
Re: Specifying an org.osgi.service.http.HttpContext in DOSGi
Posted by Sergey Beryozkin <sb...@progress.com>.
Hi Josh
We've chatted with David a bit about it...
Are you actually proposing for CXF DSW to check for a custom HttpContext implementation registered as an OSGI Service ? It would
make sense...It would probaly make sense to have an additional list property passed along during the custom HttpContext
registration, which will list custom interfaces (possibly with wildcards) and which CXF DSW will check to ensure it does not attach
a 'foreign' HttpContext to a given servlet endpoint...
In meantime, may be paxweb can let users specify a custom HttpContext in the system properties which it will use instead of the
default impl ? If it were possible then it could help till the proper fix goes in.
Cheers, Sergey
> DOSGi seems to publish JAX-RS endpoints using a null HttpContext, which
> means that the HttpService will create a default context. This makes it
> hard to add pluggable authentication handlers using
> httpContext.handleSecurity(). Does anyone have suggestions for hooking into
> the request before it's sent to the JAX-RS resource methods? I'd prefer to
> bind to the OSGI APIs rather than to CXF, and it seems like the httpContext
> should be a good way of doing that.
>
> If there isn't a convenient plact to hook in, I suppose I'll have to provide
> a custom HttpService that overrides HttpService.createDefaultHttpContext().
>
> Thanks,
> Josh
>