CODEWITHSUNDEEP
cxfws-securityjboss-eap-7wss4j
Virginie
Virginie

Reputation: 949

XMLSecurityConfigurationException: NAMESPACE_ERR with WS-Security on JBoss EAP 7.2.x

We are migrating some applications from JBoss EAP 7.1.x to JBoss EAP 7.2.x.

A JAX-WS endpoint is deployed on a JBoss 7.2.x in standalone mode, using standalone-full.xml. This endpoint is secured with WS-Security, and its policies are declared in the wsdl.

When a request is sent to this endpoint by a client, an error message is received, informing that those policies cannot be satisfied.

   <soap:Body>
      <soap:Fault>
         <soap:Code>
            <soap:Value>soap:Receiver</soap:Value>
         </soap:Code>
         <soap:Reason>
            <soap:Text xml:lang="en">
These policy alternatives can not be satisfied: 
{http://schemas.xmlsoap.org/ws/2005/07/securitypolicy}TransportBinding
{http://schemas.xmlsoap.org/ws/2005/07/securitypolicy}TransportToken
{http://schemas.xmlsoap.org/ws/2005/07/securitypolicy}HttpsToken
{http://schemas.xmlsoap.org/ws/2005/07/securitypolicy}AlgorithmSuite
{http://schemas.xmlsoap.org/ws/2005/07/securitypolicy}Basic128
{http://schemas.xmlsoap.org/ws/2005/07/securitypolicy}Layout
{http://schemas.xmlsoap.org/ws/2005/07/securitypolicy}Lax
{http://schemas.xmlsoap.org/ws/2005/07/securitypolicy}IncludeTimestamp
{http://schemas.xmlsoap.org/ws/2005/07/securitypolicy}EndorsingSupportingTokens
{http://schemas.xmlsoap.org/ws/2005/07/securitypolicy}X509Token
{http://schemas.xmlsoap.org/ws/2005/07/securitypolicy}WssX509V3Token10
{http://schemas.xmlsoap.org/ws/2005/07/securitypolicy}Wss11
  </soap:Text>
         </soap:Reason>
      </soap:Fault>

Extract from server.log:

2019-10-09 09:41:31:633 FINE  [org.apache.cxf.ws.security.policy.WSSecurityPolicyLoader] (default task-1) Could not load or register WS-SecurityPolicy related classes. Please check that (the correct version of) Apache WSS4J is on the classpath: java.lang.ExceptionInInitializerError
       at org.apache.cxf.ws.security.wss4j.WSS4JStaxOutInterceptor.<init>(WSS4JStaxOutInterceptor.java:92)
       at org.apache.cxf.ws.security.wss4j.PolicyBasedWSS4JStaxOutInterceptor.<init>(PolicyBasedWSS4JStaxOutInterceptor.java:45)
       at org.apache.cxf.ws.security.policy.interceptors.WSSecurityInterceptorProvider.<init>(WSSecurityInterceptorProvider.java:65)
       at org.apache.cxf.ws.security.policy.WSSecurityPolicyLoader.registerProviders(WSSecurityPolicyLoader.java:300)
       at org.apache.cxf.ws.security.policy.WSSecurityPolicyLoader.<init>(WSSecurityPolicyLoader.java:108)
(…)
Caused by: org.apache.xml.security.stax.ext.XMLSecurityConfigurationException: NAMESPACE_ERR: An attempt is made to create or change an object in a way which is incorrect with regard to namespaces.
Original Exception was org.w3c.dom.DOMException: NAMESPACE_ERR: An attempt is made to create or change an object in a way which is incorrect with regard to namespaces.
       at org.apache.xml.security.stax.config.Init.init(Init.java:89)
       at org.apache.wss4j.stax.setup.WSSec.<clinit>(WSSec.java:62)
       ... 106 more

Investigation shows that the issue occurs because an exception is raised during the parsing of wss-config.xml, located in xmlsec-2.1.2.redhat-00001.jar. This issue can be reproduced by calling this line in a managed environment, even out of the JAX-WS/CXF context:

org.apache.xml.security.stax.config.Init.init(ClassLoaderUtils.getResource("wss/wss-config.xml", WSSec.class).toURI(), WSSec.class);

Line causing the exception in org.apache.xml.security.stax.config.Init from xmlsec-2.1.2.redhat-00001.jar:

saxParser.parse(uri.toURL().toExternalForm(), new XIncludeHandler(unmarshallerHandler));

This error specifically occurs on a 7.2.x instance in a Redhat Environment, and it does not occur:

Config:

Endpoint configuration:

@WebContext(transportGuarantee = TransportGuarantee.CONFIDENTIAL, //
              urlPattern = "/MyEndpoint")
@EndpointConfig(configFile = "WEB-INF/jaxws-endpoint-config.xml", configName = "MyEndpoint")
public class MyEndPoint implements IMyEndPoint {

jboss-deployment-structure.xml used:

<jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.3">
       <deployment>
              <dependencies>
                     <module name="org.apache.cxf" export="true"/>
                     <module name="org.apache.cxf.impl" export="true"/>
                     <module name="org.apache.ws.security" export="true"/>
              </dependencies>
       </deployment>
</jboss-deployment-structure>

Dependency declared in pom.xml:

<dependency>
       <groupId>org.apache.cxf</groupId>
       <artifactId>cxf-rt-ws-security</artifactId>
       <version>3.2.9</version>
       <scope>provided</scope>
</dependency>

What could be the cause of this issue?

Upvotes: 0

Views: 866

Answers (1)

Kevin Petrychyn
Kevin Petrychyn

Reputation: 13

I cannot say for sure that this is exactly the same problem or root cause as the question, but hopefully it may help someone.

In my case, I ran into the exception when attempting to call a WebService secured using WS Security. When running this inside JBoss 7.2 on Windows, the NAMESPACE_ERR exception was occurring before the intialization was complete, and the result was my outgoing calls did not contain the security information in the SOAP header, which was causing the calls to fail.

In the org.apache.xml.security.stax.config.Init class, I confirmed that the SAXParser was failing when trying to parse the file wss/wss-config.xml in the jar wss4j-ws-security-stax-2.2.2.redhat-00002.jar. More specifically, this file includes the file security-config.xml in the jar xmlsec-2.1.2.redhat-00001.jar, and it is actually when parsing this included file that the exception occurred. I confirmed this by modifying wss/wss-config.xml to not include security-config.xml, and this resolved the issue.

I ran the code that parses those files outside of JBoss. This ran successfully. After much investigation trying to determine the difference, I found that JBoss is effectively hijacking the XMLReaderFactory using its module class __redirected.__XMLReaderFactory, and creating its own instance of XMLReader that is used to parse the included file. Specifically, the instance that it was creating and using to parse the included file security-config.xml was created without the namespace aware feature. Because of this, the declaration at the top of that file

xmlns="http://www.xmlsecurity.org/NS/configuration"

was causing the exception, since the parser thinks this is overriding the default XML namespace of http://www.w3.org/2000/xmlns/.

My solution was to create a file META-INF/services/org.xml.sax.driver in our deployment telling JBoss' XMLReaderFactory which instance to create. I put in this file

com.sun.org.apache.xerces.internal.parsers.SAXParser

which is the default implementation used outside of JBoss (the class that Java's SAX parsing library will create by default), and importantly, will enable the namespace feature when a new instance is created.

Upvotes: 0

Related Questions