Hi Josh On Fri, Mar 19, 2010 at 7:09 AM, Josh Holtzman <[email protected]>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 <[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 > > > >>> > > > >>> > > > >> > > > > > > > > > >
