[CXF-4715] WS-security encrypted elements with XPath . CXF generates wsu:Id attribute, XSD validation on Metro fails

• Type: Bug
• Status: Closed
• Priority: Minor
• Resolution: Fixed
• Affects Version/s: 2.6.1, 2.7.1
• Fix Version/s: 2.5.8, 2.6.5, 2.7.2
• Component/s: WS-* Components

Environment

JDK 1.7.0_02
Windows 7
Tomcat 6.0.29
Metro 1.5 / 2.2 server

• Estimated Complexity: Unknown
• Assignee: Daniel Kulp
• Reporter: Franck WIELGUS
• Created: 20/Dec/12 15:18
• Updated: 14/Mar/16 11:31
• Resolved: 20/Dec/12 20:18

Description

The problem is related to WS-security policies enforcement by a CXF client and the generated message compared to what is expected by a Metro server when XSD validation is turned on.

The following policy is used :
<wsp:Policy wsu:Id="chiffr_elt_policy">
<wsp:ExactlyOne>
<wsp:All>
<sp:EncryptedElements
xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702">
<sp:XPath>
//*[local-name()='inputToEncrypt']
</sp:XPath>
</sp:EncryptedElements>
</wsp:All>
</wsp:ExactlyOne>
</wsp:Policy>

CXF client encrypts the element matching the XPath expression, but it seems to add a "wsu:Id" attribute that is not allowed by Metro (not allowed by the XSD of "inputToEncrypt" element). When the server analyzes the request and tries to validate the message against the XSD, the following error appears :

javax.xml.ws.WebServiceException: org.xml.sax.SAXParseException; cvc-complex-type.3.2.2 : L'attribut 'wsu:Id' n'est pas autorisé dans l'élément 'inputToEncrypt'.
at com.sun.xml.ws.util.pipe.AbstractSchemaValidationTube.doProcess(AbstractSchemaValidationTube.java:242)
at com.sun.xml.ws.util.pipe.AbstractSchemaValidationTube.processRequest(AbstractSchemaValidationTube.java:211)
at com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:598)
at com.sun.xml.ws.api.pipe.Fiber._doRun(Fiber.java:557)
at com.sun.xml.ws.api.pipe.Fiber.doRun(Fiber.java:542)
at com.sun.xml.ws.api.pipe.Fiber.runSync(Fiber.java:439)
at com.sun.xml.ws.server.WSEndpointImpl$2.process(WSEndpointImpl.java:243)
at com.sun.xml.ws.transport.http.HttpAdapter$HttpToolkit.handle(HttpAdapter.java:471)
at com.sun.xml.ws.transport.http.HttpAdapter.handle(HttpAdapter.java:244)
at com.sun.xml.ws.transport.http.servlet.ServletAdapter.handle(ServletAdapter.java:135)
at com.sun.xml.ws.transport.http.servlet.WSServletDelegate.doGet(WSServletDelegate.java:129)
at com.sun.xml.ws.transport.http.servlet.WSServletDelegate.doPost(WSServletDelegate.java:160)
at com.sun.xml.ws.transport.http.servlet.WSServlet.doPost(WSServlet.java:75)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:637)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:857)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:588)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:489)
at java.lang.Thread.run(Thread.java:722)
Caused by: org.xml.sax.SAXParseException; cvc-complex-type.3.2.2 : L'attribut 'wsu:Id' n'est pas autorisé dans l'élément 'inputToEncrypt'.
at com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.createSAXParseException(ErrorHandlerWrapper.java:198)
at com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.error(ErrorHandlerWrapper.java:134)
at com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:437)
at com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:368)
at com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:325)
at com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaValidator$XSIErrorReporter.reportError(XMLSchemaValidator.java:449)
at com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaValidator.reportSchemaError(XMLSchemaValidator.java:3228)
at com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaValidator.processAttributes(XMLSchemaValidator.java:2705)
at com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaValidator.handleStartElement(XMLSchemaValidator.java:2047)
at com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaValidator.startElement(XMLSchemaValidator.java:737)
at com.sun.org.apache.xerces.internal.jaxp.validation.DOMValidatorHelper.beginNode(DOMValidatorHelper.java:276)
at com.sun.org.apache.xerces.internal.jaxp.validation.DOMValidatorHelper.validate(DOMValidatorHelper.java:243)
at com.sun.org.apache.xerces.internal.jaxp.validation.DOMValidatorHelper.validate(DOMValidatorHelper.java:189)
at com.sun.org.apache.xerces.internal.jaxp.validation.ValidatorImpl.validate(ValidatorImpl.java:109)
at javax.xml.validation.Validator.validate(Validator.java:124)
at com.sun.xml.ws.util.pipe.AbstractSchemaValidationTube.doProcess(AbstractSchemaValidationTube.java:240)
... 26 more

The workaround is to delete @SchemaValidation in the service class on Metro server to disable XSD validation.
A Metro client with the same policy does not have this behavior and the XSD validation is fine.