Kuali Rice Development
  1. Kuali Rice Development
  2. KULRICE-5109

Upgrade Apache CXF from 2.3.8 to 2.7.0 and wss4j from 1.5.x to 1.6.7

    Details

    • Type: Task Task
    • Status: Closed Closed
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 2.1.3
    • Security Level: Public (Public: Anyone can view)
    • Labels:
      None
    • Similar issues:
      KULRICE-8479Upgrade Jetty from Apache CXF 2.7.0 upgrade
      KULRICE-8472Include information on CXF upgrade in release notes
      KULRICE-8466Number of classes using Apache CXF StringUtils instead of Apache Commons StringUtils
      KULRICE-6352Upgrade from apache cxf 2.3.6 to 2.3.7
      KULRICE-14164Upgrade Apache CXF from 2.7.12 to 3.0.3
      KULRICE-3377Upgrade CXF version from 2.1.3 to 2.1.5 for KS
      KULRICE-8826Back level version of Jetty for Integration Tests configured
      KULRICE-1225Verify CXF is a valid library to use
    • Rice Module:
      Rice Core, KSB
    • Application Requirement:
      Rice
    • KAI Review Status:
      Not Required
    • KTI Review Status:
      Not Required

      Description

      A new significant version of cxf has been released (currently 2.4.0). We should update this before rice 2.0 is released otherwise we might not be able to safely update it and ensure version compatibility (this hasn't been proven one way or another though). There is added risk to updating cxf after rice 2.0 because all of our soap services are using cxf and our wsdls are generated using cxf.

        Issue Links

          Activity

          Hide
          Travis Schneeberger added a comment -

          As a part of this upgrade the following jetty version should have been upgraded in: https://svn.kuali.org/repos/rice/trunk/it/pom.xml

          see:

              <!-- decrease jetty version for it tests because we are using an old version of cxf -->
              <jetty.version>7.4.5.v20110725</jetty.version>
          

          The 2.7.0 version of the cxf-rt-transports-http-jetty lib uses version 8.1.7.v20120910 of jetty.

          Show
          Travis Schneeberger added a comment - As a part of this upgrade the following jetty version should have been upgraded in: https://svn.kuali.org/repos/rice/trunk/it/pom.xml see: <!-- decrease jetty version for it tests because we are using an old version of cxf --> <jetty.version>7.4.5.v20110725</jetty.version> The 2.7.0 version of the cxf-rt-transports-http-jetty lib uses version 8.1.7.v20120910 of jetty.
          Hide
          Eric Westfall added a comment -

          By the way, the work here was done because of production issues being had at IU which necessitated an upgrade to wss4j 1.6.x. Information and email thread here:

          From: Colm O hEigeartaigh
          Sent: Thursday, September 20, 2012 6:01 AM
          To: users@ws.apache.org
          Subject: Re: Issuer name getting truncated
          
           
          
          
          Does the message contain the truncated Issuer Name? If so the error is on the outbound side (which I assume is also WSS4J). WSS4J 1.5.x uses the XMLX509IssuerSerial class in Santuario 1.4.x to constuct the Issuer name, which calls the now denigrated getIssuerDN:
          
          https://svn.apache.org/repos/asf/santuario/xml-security-java/branches/1.4.x-fixes/src/org/apache/xml/security/keys/content/x509/XMLX509IssuerSerial.java
          
          You could check to see if the following code results in the truncated String:
          
          RFC2253Parser.normalize(x509certificate.getIssuerDN().getName());
          
          A workaround is simply to use another way of referencing the certificate on the client side, such as ThumbprintSHA1. I strongly encourage you to upgrade to the latest WSS4J 1.6.x release, where this bug should be fixed.
          
          Colm.
          
          
          On Wed, Sep 19, 2012 at 10:24 PM, Bennett III, James William wrote:
          
          Hello everyone,
          
           
          
          I work with an application which uses WSS4j version 1.5.11 and we get an exception fairly regularly which seems to truncate the end of the issuer name when it signs a request.  We end up seeing these exceptions thrown on the server when we make a web service call:
          
           
          
          java.lang.IllegalArgumentException: improperly specified input name: CN=Foo Bar,OU=Baz,O=Org,L=City,ST=IN,
          
                  at javax.security.auth.x500.X500Principal.<init>(X500Principal.java:150)
          
                  at javax.security.auth.x500.X500Principal.<init>(X500Principal.java:102)
          
                  at org.apache.ws.security.components.crypto.CryptoBase.createBCX509Name(CryptoBase.java:283)
          
                  at org.apache.ws.security.components.crypto.CryptoBase.getAliasForX509Cert(CryptoBase.java:335)
          
                  at org.apache.ws.security.components.crypto.CryptoBase.getAliasForX509Cert(CryptoBase.java:300)
          
                  at org.apache.ws.security.message.token.SecurityTokenReference.getX509IssuerSerialAlias(SecurityTokenReference.java:562)
          
                  at org.apache.ws.security.message.token.SecurityTokenReference.getX509IssuerSerial(SecurityTokenReference.java:541)
          
                  at org.apache.ws.security.processor.SignatureProcessor.verifyXMLSignature(SignatureProcessor.java:377)
          
                  at org.apache.ws.security.processor.SignatureProcessor.handleToken(SignatureProcessor.java:116)
          
                  at org.apache.ws.security.WSSecurityEngine.processSecurityHeader(WSSecurityEngine.java:328)
          
                  at org.apache.ws.security.WSSecurityEngine.processSecurityHeader(WSSecurityEngine.java:245)
          
                  at org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.handleMessage(WSS4JInInterceptor.java:219)
          
                  at org.kuali.rice.ksb.security.soap.CXFWSS4JInInterceptor.handleMessage(CXFWSS4JInInterceptor.java:93)
          
                  at org.kuali.rice.ksb.security.soap.CXFWSS4JInInterceptor.handleMessage(CXFWSS4JInInterceptor.java:41)
          
                  at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:255)
          
                  at org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:113)
          
                  at org.apache.cxf.transport.servlet.ServletDestination.invoke(ServletDestination.java:102)
          
                  at org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:464)
          
                  at org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:188)
          
                  at org.kuali.rice.ksb.messaging.servlet.CXFServletControllerAdapter.handleRequest(CXFServletControllerAdapter.java:47)
          
                  at org.springframework.web.servlet.mvc.SimpleControllerHandlerAdapter.handle(SimpleControllerHandlerAdapter.java:48)
          
                  at org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:900)
          
                  at org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:827)
          
                  at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:882)
          
                  at org.springframework.web.servlet.FrameworkServlet.doPost(FrameworkServlet.java:789)
          
                  at javax.servlet.http.HttpServlet.service(HttpServlet.java:641)
          
                  at org.kuali.rice.ksb.messaging.servlet.KSBDispatcherServlet.service(KSBDispatcherServlet.java:138)
          
                  at javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
          
                  at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
          
                  at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
          
                  at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:225)
          
                  at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:169)
          
                  at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472)
          
                  at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:168)
          
                  at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:98)
          
                  at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:927)
          
                  at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
          
                  at org.apache.catalina.ha.session.JvmRouteBinderValve.invoke(JvmRouteBinderValve.java:219)
          
                  at org.apache.catalina.ha.tcp.ReplicationValve.invoke(ReplicationValve.java:333)
          
                  at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407)
          
                  at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:999)
          
                  at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:565)
          
                  at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:307)
          
                  at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
          
                  at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
          
                  at java.lang.Thread.run(Thread.java:662)
          
          Caused by: java.io.IOException: empty AVA in RDN ""
          
                  at sun.security.x509.RDN.<init>(RDN.java:132)
          
                  at sun.security.x509.X500Name.parseDN(X500Name.java:918)
          
                  at sun.security.x509.X500Name.<init>(X500Name.java:148)
          
                  at javax.security.auth.x500.X500Principal.<init>(X500Principal.java:148)
          
                  ... 45 more
          
           
          
          I checked the keystore and the issuer name is “CN=Foo Bar,OU=Baz,O=Org,L=City,ST=IN,C=US” so it appears that it is truncating the country off of the end but not removing the last comma which causes the name to be invalid.  Has anyone seen anything like this before?  If there’s any other information I can provide please let me know.
          
           
          
          Thanks,
          
          James 
          
          Show
          Eric Westfall added a comment - By the way, the work here was done because of production issues being had at IU which necessitated an upgrade to wss4j 1.6.x. Information and email thread here: From: Colm O hEigeartaigh Sent: Thursday, September 20, 2012 6:01 AM To: users@ws.apache.org Subject: Re: Issuer name getting truncated Does the message contain the truncated Issuer Name? If so the error is on the outbound side (which I assume is also WSS4J). WSS4J 1.5.x uses the XMLX509IssuerSerial class in Santuario 1.4.x to constuct the Issuer name, which calls the now denigrated getIssuerDN: https: //svn.apache.org/repos/asf/santuario/xml-security-java/branches/1.4.x-fixes/src/org/apache/xml/security/keys/content/x509/XMLX509IssuerSerial.java You could check to see if the following code results in the truncated String : RFC2253Parser.normalize(x509certificate.getIssuerDN().getName()); A workaround is simply to use another way of referencing the certificate on the client side, such as ThumbprintSHA1. I strongly encourage you to upgrade to the latest WSS4J 1.6.x release, where this bug should be fixed. Colm. On Wed, Sep 19, 2012 at 10:24 PM, Bennett III, James William wrote: Hello everyone, I work with an application which uses WSS4j version 1.5.11 and we get an exception fairly regularly which seems to truncate the end of the issuer name when it signs a request. We end up seeing these exceptions thrown on the server when we make a web service call: java.lang.IllegalArgumentException: improperly specified input name: CN=Foo Bar,OU=Baz,O=Org,L=City,ST=IN, at javax.security.auth.x500.X500Principal.<init>(X500Principal.java:150) at javax.security.auth.x500.X500Principal.<init>(X500Principal.java:102) at org.apache.ws.security.components.crypto.CryptoBase.createBCX509Name(CryptoBase.java:283) at org.apache.ws.security.components.crypto.CryptoBase.getAliasForX509Cert(CryptoBase.java:335) at org.apache.ws.security.components.crypto.CryptoBase.getAliasForX509Cert(CryptoBase.java:300) at org.apache.ws.security.message.token.SecurityTokenReference.getX509IssuerSerialAlias(SecurityTokenReference.java:562) at org.apache.ws.security.message.token.SecurityTokenReference.getX509IssuerSerial(SecurityTokenReference.java:541) at org.apache.ws.security.processor.SignatureProcessor.verifyXMLSignature(SignatureProcessor.java:377) at org.apache.ws.security.processor.SignatureProcessor.handleToken(SignatureProcessor.java:116) at org.apache.ws.security.WSSecurityEngine.processSecurityHeader(WSSecurityEngine.java:328) at org.apache.ws.security.WSSecurityEngine.processSecurityHeader(WSSecurityEngine.java:245) at org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.handleMessage(WSS4JInInterceptor.java:219) at org.kuali.rice.ksb.security.soap.CXFWSS4JInInterceptor.handleMessage(CXFWSS4JInInterceptor.java:93) at org.kuali.rice.ksb.security.soap.CXFWSS4JInInterceptor.handleMessage(CXFWSS4JInInterceptor.java:41) at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:255) at org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:113) at org.apache.cxf.transport.servlet.ServletDestination.invoke(ServletDestination.java:102) at org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:464) at org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:188) at org.kuali.rice.ksb.messaging.servlet.CXFServletControllerAdapter.handleRequest(CXFServletControllerAdapter.java:47) at org.springframework.web.servlet.mvc.SimpleControllerHandlerAdapter.handle(SimpleControllerHandlerAdapter.java:48) at org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:900) at org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:827) at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:882) at org.springframework.web.servlet.FrameworkServlet.doPost(FrameworkServlet.java:789) at javax.servlet.http.HttpServlet.service(HttpServlet.java:641) at org.kuali.rice.ksb.messaging.servlet.KSBDispatcherServlet.service(KSBDispatcherServlet.java:138) at javax.servlet.http.HttpServlet.service(HttpServlet.java:722) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:225) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:169) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:168) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:98) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:927) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118) at org.apache.catalina.ha.session.JvmRouteBinderValve.invoke(JvmRouteBinderValve.java:219) at org.apache.catalina.ha.tcp.ReplicationValve.invoke(ReplicationValve.java:333) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407) at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:999) at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:565) at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:307) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang. Thread .run( Thread .java:662) Caused by: java.io.IOException: empty AVA in RDN "" at sun.security.x509.RDN.<init>(RDN.java:132) at sun.security.x509.X500Name.parseDN(X500Name.java:918) at sun.security.x509.X500Name.<init>(X500Name.java:148) at javax.security.auth.x500.X500Principal.<init>(X500Principal.java:148) ... 45 more I checked the keystore and the issuer name is “CN=Foo Bar,OU=Baz,O=Org,L=City,ST=IN,C=US” so it appears that it is truncating the country off of the end but not removing the last comma which causes the name to be invalid. Has anyone seen anything like this before? If there’s any other information I can provide please let me know. Thanks, James
          Hide
          Gayathri Athreya added a comment - - edited

          Hello, I am trying to get KC running with Rice 2.1.3 revision 36235 and I get the following stack trace

          Caused by: java.lang.NoClassDefFoundError: org/apache/jcp/xml/dsig/internal/dom/XMLDSigRI
          	at org.apache.cxf.ws.security.wss4j.WSS4JOutInterceptor$WSS4JOutInterceptorInternal.handleMessage(WSS4JOutInterceptor.java:176)
          	at org.apache.cxf.ws.security.wss4j.WSS4JOutInterceptor$WSS4JOutInterceptorInternal.handleMessage(WSS4JOutInterceptor.java:136)
          	at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:271)
          	at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:531)
          

          I think this is because of the WSS4j upgrade and it looks like 1.6.7 has a direct dependency on the XMLDSigRI class. We do not have a direct dependency to wss4j so should this dependency be added to the Rice POM? This error is thrown as soon as the first web service client call (which is to the service registry getAllOnlineServices()) is made. I think it has trouble signing the message. Am I missing something? Is this something that needs to go into the POM on our end?

          Show
          Gayathri Athreya added a comment - - edited Hello, I am trying to get KC running with Rice 2.1.3 revision 36235 and I get the following stack trace Caused by: java.lang.NoClassDefFoundError: org/apache/jcp/xml/dsig/internal/dom/XMLDSigRI at org.apache.cxf.ws.security.wss4j.WSS4JOutInterceptor$WSS4JOutInterceptorInternal.handleMessage(WSS4JOutInterceptor.java:176) at org.apache.cxf.ws.security.wss4j.WSS4JOutInterceptor$WSS4JOutInterceptorInternal.handleMessage(WSS4JOutInterceptor.java:136) at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:271) at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:531) I think this is because of the WSS4j upgrade and it looks like 1.6.7 has a direct dependency on the XMLDSigRI class. We do not have a direct dependency to wss4j so should this dependency be added to the Rice POM? This error is thrown as soon as the first web service client call (which is to the service registry getAllOnlineServices()) is made. I think it has trouble signing the message. Am I missing something? Is this something that needs to go into the POM on our end?
          Hide
          Travis Schneeberger added a comment - - edited

          You should run the mvn dependency:tree command on the KC project to see what dependencies are being resolved. My guess is an incorrect version is leaking in from another dependency.

          Show
          Travis Schneeberger added a comment - - edited You should run the mvn dependency:tree command on the KC project to see what dependencies are being resolved. My guess is an incorrect version is leaking in from another dependency.
          Hide
          Gayathri Athreya added a comment -

          Thanks for that suggestion Travis, I should have done that earlier. So turns out the XMLDSigRI class is part of xmlsec which KC does directly add as a dependency and Rice meanwhile brings in 2 different versions of its own. When I took the xmlsec dependency out of KC, I could start fine.

          Show
          Gayathri Athreya added a comment - Thanks for that suggestion Travis, I should have done that earlier. So turns out the XMLDSigRI class is part of xmlsec which KC does directly add as a dependency and Rice meanwhile brings in 2 different versions of its own. When I took the xmlsec dependency out of KC, I could start fine.

            People

            • Assignee:
              Eric Westfall
              Reporter:
              Travis Schneeberger
            • Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Structure Helper Panel