org.apache.cxf.binding.soap.SoapFault: MustUnderstand headers: [{http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd}Security] are not understood.

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

org.apache.cxf.binding.soap.SoapFault: MustUnderstand headers: [{http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd}Security] are not understood.

johnhd_at_zen
We've been up and down this issue for some time. My gateway (CONNECT 4.7 binary distributable) is receiving an inbound XCPD request. Here it is, no PHI:inbound_xcpd_causing_mustunderstand_error.xml

I have control over both gateways involved in this, the sender and receiver. Both are CONNECT 4.7 which are more or less out-of-the-box stock configured right now, they're effectively clones of each other. Right now I'm focussing on the receiver.

Immediately upon receipt of that XCPD, we throw this stacktrace:

11:03:30,056 WARN  [org.apache.cxf.phase.PhaseInterceptorChain] (default task-13) Interceptor for {urn:gov:hhs:fha:nhinc:entitypatientdiscovery}EntityPatientDiscovery has thrown exception, unwinding now: org.apache.cxf.binding.soap.SoapFault: MustUnderstand headers: [{http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd}Security] are not understood.
	at org.apache.cxf.binding.soap.interceptor.MustUnderstandInterceptor.checkUltimateReceiverHeaders(MustUnderstandInterceptor.java:150) [cxf-rt-bindings-soap-2.7.3.jar:2.7.3]
	at org.apache.cxf.binding.soap.interceptor.MustUnderstandInterceptor.handleMessage(MustUnderstandInterceptor.java:96) [cxf-rt-bindings-soap-2.7.3.jar:2.7.3]
	at org.apache.cxf.binding.soap.interceptor.MustUnderstandInterceptor.handleMessage(MustUnderstandInterceptor.java:49) [cxf-rt-bindings-soap-2.7.3.jar:2.7.3]
	at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:271) [cxf-api-2.7.3.jar:2.7.3]
	at org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121) [cxf-api-2.7.3.jar:2.7.3]
	at org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:239) [cxf-rt-transports-http-2.7.3.jar:2.7.3]
	at org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:218) [cxf-rt-transports-http-2.7.3.jar:2.7.3]
	at org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:198) [cxf-rt-transports-http-2.7.3.jar:2.7.3]
	at org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:137) [cxf-rt-transports-http-2.7.3.jar:2.7.3]
	at org.apache.cxf.transport.servlet.CXFNonSpringServlet.invoke(CXFNonSpringServlet.java:158) [cxf-rt-transports-http-2.7.3.jar:2.7.3]
	at org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:243) [cxf-rt-transports-http-2.7.3.jar:2.7.3]
	at org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:163) [cxf-rt-transports-http-2.7.3.jar:2.7.3]
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:707) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final]
	at org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:219) [cxf-rt-transports-http-2.7.3.jar:2.7.3]
	at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:86) [undertow-servlet-1.1.8.Final.jar:1.1.8.Final]
	at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) [undertow-servlet-1.1.8.Final.jar:1.1.8.Final]
	at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.1.8.Final.jar:1.1.8.Final]
	at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.8.Final.jar:1.1.8.Final]
	at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) [undertow-servlet-1.1.8.Final.jar:1.1.8.Final]
	at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57) [undertow-servlet-1.1.8.Final.jar:1.1.8.Final]
	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.8.Final.jar:1.1.8.Final]
	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) [undertow-core-1.1.8.Final.jar:1.1.8.Final]
	at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) [undertow-servlet-1.1.8.Final.jar:1.1.8.Final]
	at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.1.8.Final.jar:1.1.8.Final]
	at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) [undertow-servlet-1.1.8.Final.jar:1.1.8.Final]
	at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) [undertow-core-1.1.8.Final.jar:1.1.8.Final]
	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.8.Final.jar:1.1.8.Final]
	at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.8.Final.jar:1.1.8.Final]
	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.8.Final.jar:1.1.8.Final]
	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:261) [undertow-servlet-1.1.8.Final.jar:1.1.8.Final]
	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:248) [undertow-servlet-1.1.8.Final.jar:1.1.8.Final]
	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:77) [undertow-servlet-1.1.8.Final.jar:1.1.8.Final]
	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:167) [undertow-servlet-1.1.8.Final.jar:1.1.8.Final]
	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:199) [undertow-core-1.1.8.Final.jar:1.1.8.Final]
	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:761) [undertow-core-1.1.8.Final.jar:1.1.8.Final]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [rt.jar:1.8.0_151]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [rt.jar:1.8.0_151]
	at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_151]

As far as I can tell it's complaining specifically about a problem with the wsse header (I think it thinks it's missing?)

I have a debugger attached but I'm encountering problems trying to step through the code because it's within the *org.apache.cxf.binding.soap.interceptor.MustUnderstandInterceptor* class, which is a dependency and not the project's code itself.

I found the source code for this MustUnderstandInterceptor class HERE. I'm not sure it's the same version, but line 150 looks like a match.

If I'm reading it right, it's complaining that I'm missing a header, most likely something declared by the declared wsse namespace, the XSD for which is http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd. I think this defines what elements are required in my header, but I'm a little outside my area of expertise here.

Any advice on how to tell specifically what's missing from the header? Google & SO answers are almost all "configure to ignore mustUnderstand", or "set mustUnderstand=false on the inbound message", which I see as undesirable workarounds, I'd like to solve the actual problem.

I'm a little concerned because this came out of another CONNECT 4.7 so it's almost a "can't eat it's own dogfood" situation.

Any input appreciated.
Ask The Experts! Free 15 minute live Q&A sessions with one of Zen's Expert Integrators @ https://consultzen.com/integration-service-desk-solutions/

www.consultzen.com
Reply | Threaded
Open this post in threaded view
|

Re: org.apache.cxf.binding.soap.SoapFault: MustUnderstand headers: [{http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd}Security] are not understood.

Minh
Administrator
Hi John,

After quick scan your xml, your sender gateway sends request to http://172.24.32.231:8080/Gateway/PatientDiscovery/1_0/EntityPatientDiscovery which is unsecure endpoint in CONNECT.  You don't even need to send secure soapHeader.  Without your custom EntityPatientDiscovery wsdl and schema, it is hard to see what happen.  

Maybe you try to send to https://172.24.32.231:<portnumber>/Gateway/PatientDiscovery/1_0/NhinService/NhinPatientDiscovery instead.  If so, please check your uddiconnection.xml
Minh-Hai Nguyen
CONNECT Product Team Member
Reply | Threaded
Open this post in threaded view
|

Re: org.apache.cxf.binding.soap.SoapFault: MustUnderstand headers: [{http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd}Security] are not understood.

johnhd_at_zen
Mihn,

Minh wrote
which is unsecure endpoint in CONNECT
Yes, this is intentional. We're two CONNECT gateways on an internal network we're using as a proof-of-concept, we don't intend to be using security features for this phase (HTTPS / SOAP security header).

Minh wrote
Without your custom EntityPatientDiscovery wsdl and schema, it is hard to see what happen.  
I'm not sure I understand this observation, we set up both CONNECTs "out of the box" and have not set up a custom schema. With some guidance on where/how to find these, I can provide them here if it helps?

Minh wrote
<portnumber>/Gateway/PatientDiscovery/1_0/NhinService/NhinPatientDiscovery instead.  If so, please check your uddiconnection.xml
I can try this although I based this test off of the (still working) SOAP UI tests which use the EntityPatientDiscovery endpoints.

Let me know your thoughts when you can?
Ask The Experts! Free 15 minute live Q&A sessions with one of Zen's Expert Integrators @ https://consultzen.com/integration-service-desk-solutions/

www.consultzen.com
Reply | Threaded
Open this post in threaded view
|

Re: org.apache.cxf.binding.soap.SoapFault: MustUnderstand headers: [{http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd}Security] are not understood.

Minh
Administrator
Hi John,
Have you found the answer that you are looking for?
Minh-Hai Nguyen
CONNECT Product Team Member
Reply | Threaded
Open this post in threaded view
|

Re: org.apache.cxf.binding.soap.SoapFault: MustUnderstand headers: [{http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd}Security] are not understood.

johnhd_at_zen
The complaint was that the SAML header was missing. CONNECT (4.7) assumes it will be present and errors if it isn't.

Is there a way to disable SAML Validation in CONNECT 4.7 or even 5.1?
Ask The Experts! Free 15 minute live Q&A sessions with one of Zen's Expert Integrators @ https://consultzen.com/integration-service-desk-solutions/

www.consultzen.com
Reply | Threaded
Open this post in threaded view
|

Re: org.apache.cxf.binding.soap.SoapFault: MustUnderstand headers: [{http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd}Security] are not understood.

Minh
Administrator
Hi John,
Since it is not saml validation, it is wsse:Security for soap header. So we can not turn it off.  CXF stack is failing to determine what to do with the security header that you provided since it has "mustunderstand=true".  
Can you tell us more about your use case that you are trying to accomplish? If you are still try to use entity layer, CONNECT offers both unsecure and secure entity layer.  
Here is sample endpoint for secure entity layer http://<IP>:8181/Gateway/PatientDiscovery/1_0/EntityService/EntityPatientDiscoverySecured
Minh-Hai Nguyen
CONNECT Product Team Member