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 <[email protected]>wrote: > Hi Josh > > apologies for a late response... > > On Mon, Mar 15, 2010 at 7:17 PM, Josh Holtzman <[email protected] > >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 <[email protected] > > >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 < > [email protected] > > >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 > > >>> > > >>> > > >> > > > > > >
