3 Replies Latest reply on Jul 31, 2012 11:53 AM by asoldano

    WS-Security without Spring, without WS-Policy and without the CXF annotations?

    mwringe

      Is it possible to configure ws-security with JBossWS CXF Stack without using Spring, without using ws-policy, and without using the cxf annotations in the service classes?

       

      I need to configure ws-security with wsrp, and wsrp is _not_ compatible with ws-policy (its against the spec, it may be supported in the next spec version but its not in the current one). So I can't just use ws-policy with the configuration properties to enable ws-security.

       

      It looks like you still have the pre and post soap handlers for the CXF stack like you did with the native stack (https://docs.jboss.org/author/display/JBWS/Predefined+client+and+endpoint+configurations). But this is only for adding in soaphandlers, and cxf is configured using interceptors, which means I can't use this to add the security interceptors. Is there anyway to add in intereceptors in a similar manner?

       

      IIts possible to use the cxf annotations on the java service classes to add in the security interceptors, but this means making our service classes dependent on cxf or having to have separate classes just for cxf. This really isn't an acceptable solution either, we need to support more than one application server.

       

      Since the recommended way to configure CXF is to use Spring configuration files, I am confused why Spring is not the recommended manner to configure cxf in JBossWS (and Spring isn't include in AS7 either). Or is Spring the recommended manner with the cxf stack in JBossWS and I am reading the docs wrong? I would rather not have to add a spring dependency, but it looks like this might be the only real solution :/

       

      Am I missing anything obvious on how to do this in a manner that is not dependent on spring, ws-policy or custom cxf only classes with the special cxf annotations?

        • 1. Re: WS-Security without Spring, without WS-Policy and without the CXF annotations?
          asoldano

          Hi Matt,

          WS-Security is configurable in Apache CXF in different ways: 1) annotation (server side) 2) spring descriptor (client and server side) 3) direct CXF api usage (client side) 4) policy engine (client and server side).

          The JBossWS preferred method for configuring ws-security is using policies, but the other approaches are still usable.

          Spring is not installed by default on JBoss AS 7 and not strictly required when using jbossws-cxf because it's actually used for configuration only, and pretty much anything can be configured differently (see [1] and subpages). You can still install Spring in the org.springframework.spring module (either manually or using the jbossws-cxf install) and use it, if it's your only acceptable approach.

          To be honest, achieving a completely agnostic configuration when using WS-Security is not completely doable; the policy approach is probably the closest one to the target, if you can use that.

           

          [1] https://docs.jboss.org/author/display/JBWS/Advanced+User+Guide

          • 2. Re: WS-Security without Spring, without WS-Policy and without the CXF annotations?
            mwringe

            I know (and mentioned) those configuration options in my original post As mentioned:

             

            1) we can't use ws-policy since its against the wsrp spec

             

            2) adding annotations to add in interceptors means that our purely jax java service classes now have to become dependent on cxf (which doesn't make a lot of sense since have to support non-cxf based web services, and we also want an admin to be able to enable/disable the interceptors themselves).

             

            3) we don't want to have to bring in spring just to configure the web service. And this doesn't appear to the preferred method of configuring jbossws (but it is the preferred way to configure cxf).

             

            The client side is fine, I can easily add in the interceptors here.

             

            The problem is how to configure the server. Using JBossWS Native stack I could just use the pre and post handlers to add in proper soap handlers for ws-security, this was simple and straight forward and configurable from an admin perspective. The ws-security setup could be handled outside of the service configuration (add in the options in the web.xml file to specify the endpoint config name and config file). It would be perfect if we could add in interceptors also in this manner, but this option doesn't seem to exist (which is strange since in cxf interceptors are the preferred method).

             

            Its strange that CXF is the preferred web service stack in JBossAS, and the preferred way to configure CXF is using Spring configuration files, but JBossAS doesn't ship or include Spring. So we can't properly configure web services the way they were meant to be configured.

            • 3. Re: WS-Security without Spring, without WS-Policy and without the CXF annotations?
              asoldano

              Matt Wringe wrote:

               

              I know (and mentioned) those configuration options in my original post As mentioned:

               

              1) we can't use ws-policy since its against the wsrp spec

               

              2) adding annotations to add in interceptors means that our purely jax java service classes now have to become dependent on cxf (which doesn't make a lot of sense since have to support non-cxf based web services, and we also want an admin to be able to enable/disable the interceptors themselves).

              Quite frankly, I see and understand the need for avoiding implementation specific api in endpoints (you might want to deploy the same archive on another vendor container), but as hinted before that's probably simply not doable (especially without WS-Policy support) with WS-Security. The reason basically being that there's no JCP spec covering ws-security configuration, so you'll always need to use an implementation specific configuration approach.

              If the real need is actually with the admin wanting to enable/disable the cxf interceptor without touching the code, you can go the spring descriptor way, after having added spring libraries to the app server.

               

              3) we don't want to have to bring in spring just to configure the web service. And this doesn't appear to the preferred method of configuring jbossws (but it is the preferred way to configure cxf).

              You don't want to bring in spring because it's just for configuration *or* you're simply somehow confused by the fact jbossas/jbossws does not ship with / install spring by default? If it's a matter of willing to avoid spring for ws configuration only, I see what you mean (as a matter of fact jbossws has moved in this direction, hence is not forcing the spring approach and encouraging the ws-policy based approach), but when you have many other contraints like "wsrp does not support policies", "I don't want to use cxf api", ... you need to come to a compromise and use what is left ;-)

              If it's a matter of you being confused on "what the preferred method is", keep in mind that JBossWS suggest using the policy approach, but allows different methods if you can't go that way. Apache CXF in general simply has multiple configuration mechanisms and I can say that there's not an actual preference for the spring one as of today, they're really all at the same level.

               

               

              The problem is how to configure the server. Using JBossWS Native stack I could just use the pre and post handlers to add in proper soap handlers for ws-security, this was simple and straight forward and configurable from an admin perspective. The ws-security setup could be handled outside of the service configuration (add in the options in the web.xml file to specify the endpoint config name and config file). It would be perfect if we could add in interceptors also in this manner, but this option doesn't seem to exist (which is strange since in cxf interceptors are the preferred method).

              The client / endpoint pre-defined configurations can be used to add JAXWS handlers. WS-Security was implemented using handlers in native stack. However it's not implemented using jaxws handlers on cxf and we can't (and do not want to) change that.

              Any mechanism for allowing configuring a generic interceptor through descriptor would basically imply re-inventing the spring configuration approach (a jaxws handler definition is covered by jsr224/jsr109 specs instead).. so again, either the user go the spring way if he really wants to have fine grain control on the interceptor beans or he stay with the suggested configuration mechanism (policy engine + properties through @EndpointConfig) *or* direct cxf api/annotation usage.

               

               

              Its strange that CXF is the preferred web service stack in JBossAS, and the preferred way to configure CXF is using Spring configuration files, but JBossAS doesn't ship or include Spring. So we can't properly configure web services the way they were meant to be configured.

              Again, 1) it's not *the* way they're meant to be configured, just *one* of the possible ways 2) you *can* still configure the ws endpoints that way if you want, simply install Spring first (either using the jbossws build or manually copying the spring jars into modules/org/springframework/spring/main and creating a valid module.xml descriptor for the new module).