Error sending to 9915:b - Soap Body is not SIGNED #205
Comments
|
@evgenywork : Thanks for reporting this. We will analyze and would take respective action after analyzing case. |
|
Also reported by "Peppol France PoC" Oxalis user. Probably they are also sending to AP which is using same implementation as used by Austrian Central AP . We will go through Peppol AS4 specification and will take necessary action. |
|
From what I see, https://www.erechnung.gv.at/as4 returns unencrypted and unsigned response in pure SOAP Envelope: I hardly imagine how it can be correct, as business errors should be signed. An unsigned response can be generated if the protocol requirements are not satisfied, but here we have a case where the document is considered invalid by Schematron (although I do not understand this neither, as the test document is valid by Peppol BIS3 schematron validation rules...). So my point here is that the implementation from Austrian Central AP rejects invalid documents without signature - although it is possible to generate a signed rejection document! Here is an example of Oxalis response on an invalid payload - it includes Header\Security tag with signatures and non-empty Body: |
|
Looking into OASIS AS4 Profile of ebMS 3.0 Version 1.0 specification: http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/profiles/AS4-profile/v1.0/os/AS4-profile-v1.0-os.html#__RefHeading__26446_1909778835 5.1.4 Signing Messages a) AS4 MSH implementations are REQUIRED to use Detached Signatures as defined by the XML Signature Specification [XMLDSIG] when signing AS4 user or signal messages. Enveloped Signatures as defined by [XMLDSIG] are not supported by or authorized in this profile. b) AS4 MSH implementations are REQUIRED to include the entire eb:Messaging SOAP header block and the (possibly empty) SOAP Body in the signature. The eb:Messaging header SHOULD be referenced using the “id” attribute. I am not sure what was meant under "AS4 Error Message" - as ebMS specification defines only 4 types of messages:
And I would say that Signal Message Error should be signed... |
|
Finally, both eDeliveryAS4Policy.xml and eDeliveryAS4Policy_BST.xml (BST stays for BinarySecurityToken) specify that Header/Messaging should be signed: Oxalis-AS4/src/main/resources/eDeliveryAS4Policy.xml Lines 44 to 55 in ff21c65 |
|
Hi guys, Ebms Core 3.0 specification mentions a lot about signing etc., but it never mentions "signed Errors". It only mentions "Signed Receipts" - e,g, in http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/core/os/ebms_core-3.0-spec-os.html#7.12.2.Persistent%20Signed%20Receipt|outline The advanced features also only mentions "Signed Receipt" as in http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/part2/201004/cs01/ebms-v3.0-part2-cs01.html#__RefHeading__435897_822242408 So my conclusion, crosschecking with a spec lead at that time was, that hth, Philip |
|
Hello Philip, thank you for your comment! What do you think about this part of the spec:
AS4 MSH implementations are REQUIRED to include the entire eb:Messaging SOAP header block and the (possibly empty) SOAP Body in the signature. The Error messages in this discussion are those, which have Error tag as |
|
Well, according to one of the spec leads, there is no specific statement if errors should be signed or not. But you must always consider the case, that a PMode was not found on the receiver side so you don't know if and how you should sign - from a generic AS4 perspective. For Peppol we could always know it. As neither OpenPeppol AS4 specification nor CEF eDelivery makes a statement about this, both versions (signed and unsigned) are correct I would say. |
|
Maybe I add something here. Consider the "default AS4" case, where you have bilateral agreement between 2 exchanging parties. In that case it might be that for one party you respond with a signed Receipt, in others you don't. In case you cannot find the matching PMode on the receiver side, you don't know whether you should sign or not. I assume that is the reason, why there is no "SHOULD" or similar statement in the AS4 specification. The best way forward, from my point of view, would be to file a request for change to the Peppol Service Desk, elaborating the problem and requesting to also sign Error Messages. I don't see any technical issue hindering always signed Receipts in the context of Peppol only. |
|
Hello, We have the same issue, is there any workaround it can be used to avoid this problem or a fix is the only way to overcome this problem? Thanks |
|
I suggest to add to the discussion at #210 - this is the issue only |
|
Hello @Legione85 , could you please file a change request at Peppol Service Desk to fix TestBed so that it signs errors too like it is suggested by @phax in above comment #205 (comment) ? As a workaround to see the actual error message you can look into suggestions at #212 (comment) But it is mostly errors like here (if you work with TestBed) - #212 (comment) ( Unable to correlate request with Document's Identifier [POP000581-2-20230703T135007] ) It could be also that the sent payload is not valid. |
|
In general, Oxalis should be able to handle unsigned errors - it is used in the network. |
|
Hello Philip @phax, as I see it, Domibus 5.0 also does not trust unsigned rejections: Checked it by sending from Domibus to a static URL which always returns and also to the access point in this issue. Stacktrace is quite similar to Oxalis, because Domibus is also based on Apache CXF. |
|
In general, I would say that trusting unsigned responses - including rejections - looks wrong from the security point of view. Signed response guarantee, that it was generated by the correct party, as it includes information who signed it. Unsigned rejections open a way to easily interfere into communication channel (let's ignore https for a moment) and make sender to believe that the payload was rejected, as it is only 2 dynamic parts in the response XML - Timestamp and RefToMessageId, and RefToMessageId can be extracted from unencrypted part of request XML. In a general AS4 implementation there can be cases when an endpoint, which serves different standards by the same URL, can have not enough information to detect the security policy requirements, but in case of Peppol network (and Oxalis-AS4 is implementation of only PEPPOL AS4 pMode) it is always known... I would say that each access point in Peppol network should do the best to sign errors, so the sender can trust them... In terms of "AS4 Profile of ebMS 3.0 Version 1.0", I would say that rejection is just a type of Signal Message - Error, and it is required to be signed: BTW, do you know any other Peppol-compliant access point implementations which trust unsigned responses? |
Hi @dladlk , Thanks for the suggestions, unfortunately the workaround doesn't seem to work. |
aaron-kumar
added
Interoperability
|
Oxalis is following specification. It is further clarified with specification group. |
|
Fyi I implemented potential Error Message signing in phase4 2.7.0. Nevertheless you still need to be able to deal with unsigned Error Messages, because in some cases signing is NOT possible. |
|
@aaron-kumar I have emailed you regarding the same issue i just found here and in #210 |
|
You can try this one: https://github.com/dladlk/oxalis-as4-unsigned-error |
|
@ViaductAB : as discussed, fix is already there in phase4 2.7.0. Hopefully OpenPeppol Testbed will deploy this soon. Cases where it will be still unsigned message will be related to certificate, see : phax/phase4#188 |
aaron-kumar
changed the title
We are trying to send invoices to Austrian Central AP ("9915:b" Participant ID), but getting error message (see below). Sending to many other countries and access points works fine.
We are using Oxalis AS4 5.0.1 and also tested on oxalis 5.5.0.
We also contacted Austrian support and received following message:
"The problem is most likely, that we are rejecting your invoice with an AS4 Error Message.
AS4 Error Messages cannot, unlike AS4 Receipts, be signed (see the OASIS AS4 1.0 specification for details).
Hence, please contact your Oxalis vendor and get your application fixed, so that it does handle the error message correctly."
How can we configure our Oxalis installation to handle AS4 Error Messages? And why does this problem only occur with the Austrian access point, shouldn't the standard be the same for everyone and work universally?
Error message:
2023-04-26 18:49:09,275 WARN [org.apache.cxf.ws.policy.AssertionBuilderRegistryImpl] No assertion builder for type {http://oxalis.network/custom/security-policy}Basic128GCMSha256MgfSha256 registered. 2023-04-26 18:49:11,300 ERROR [org.apache.cxf.ws.policy.PolicyVerificationInInterceptor] Inbound policy verification failed: These policy alternatives can not be satisfied: {http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}X509Token: The received token does not match the token inclusion requirement {http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}SignedParts: Soap Body is not SIGNED 2023-04-26 18:49:11,303 WARN [org.apache.cxf.phase.PhaseInterceptorChain] Interceptor for {oxalis.network/}outbound-service#{http://cxf.apache.org/jaxws/dispatch}Invoke has thrown exception, unwinding now org.apache.cxf.ws.policy.PolicyException: These policy alternatives can not be satisfied: {http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}X509Token: The received token does not match the token inclusion requirement {http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}SignedParts: Soap Body is not SIGNED at org.apache.cxf.ws.policy.AssertionInfoMap.checkEffectivePolicy(AssertionInfoMap.java:179) at org.apache.cxf.ws.policy.PolicyVerificationInInterceptor.handle(PolicyVerificationInInterceptor.java:102) at org.apache.cxf.ws.policy.AbstractPolicyInterceptor.handleMessage(AbstractPolicyInterceptor.java:44) at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308) at org.apache.cxf.endpoint.ClientImpl.onMessage(ClientImpl.java:829) at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponseInternal(HTTPConduit.java:1696) at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponse(HTTPConduit.java:1570) at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1371) at org.apache.cxf.ext.logging.LoggingOutputStream.postClose(LoggingOutputStream.java:53) at org.apache.cxf.io.CachedOutputStream.close(CachedOutputStream.java:228) at org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:56) at org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:671) at org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:63) at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308) at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:530) at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:441) at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:356) at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:314) at org.apache.cxf.endpoint.ClientImpl.invokeWrapped(ClientImpl.java:349) at org.apache.cxf.jaxws.DispatchImpl.invoke(DispatchImpl.java:322) at org.apache.cxf.jaxws.DispatchImpl.invoke(DispatchImpl.java:241) at network.oxalis.as4.outbound.As4MessageSender.invoke(As4MessageSender.java:105) at network.oxalis.as4.outbound.As4MessageSender.send(As4MessageSender.java:89) at network.oxalis.as4.outbound.As4MessageSenderFacade.send(As4MessageSenderFacade.java:20) at network.oxalis.api.outbound.MessageSender.send(MessageSender.java:59) at network.oxalis.outbound.transmission.DefaultTransmitter.perform(DefaultTransmitter.java:149) at network.oxalis.outbound.transmission.DefaultTransmitter.transmit(DefaultTransmitter.java:93) at eu.sendregning.oxalis.TransmissionTask.performTransmission(TransmissionTask.java:166) at eu.sendregning.oxalis.TransmissionTask.call(TransmissionTask.java:94) at eu.sendregning.oxalis.TransmissionTask.call(TransmissionTask.java:48) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at java.lang.Thread.run(Thread.java:748) 2023-04-26 18:49:11,318 ERROR [eu.sendregning.oxalis.Main] Execution failed: network.oxalis.as4.lang.OxalisAs4TransmissionException: Failed to send message java.util.concurrent.ExecutionException: network.oxalis.as4.lang.OxalisAs4TransmissionException: Failed to send message at java.util.concurrent.FutureTask.report(FutureTask.java:122) at java.util.concurrent.FutureTask.get(FutureTask.java:192) at eu.sendregning.oxalis.Main.main(Main.java:225) Caused by: network.oxalis.as4.lang.OxalisAs4TransmissionException: Failed to send message at network.oxalis.as4.outbound.As4MessageSender.invoke(As4MessageSender.java:108) at network.oxalis.as4.outbound.As4MessageSender.send(As4MessageSender.java:89) at network.oxalis.as4.outbound.As4MessageSenderFacade.send(As4MessageSenderFacade.java:20) at network.oxalis.api.outbound.MessageSender.send(MessageSender.java:59) at network.oxalis.outbound.transmission.DefaultTransmitter.perform(DefaultTransmitter.java:149) at network.oxalis.outbound.transmission.DefaultTransmitter.transmit(DefaultTransmitter.java:93) at eu.sendregning.oxalis.TransmissionTask.performTransmission(TransmissionTask.java:166) at eu.sendregning.oxalis.TransmissionTask.call(TransmissionTask.java:94) at eu.sendregning.oxalis.TransmissionTask.call(TransmissionTask.java:48) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at java.lang.Thread.run(Thread.java:748) Caused by: javax.xml.ws.soap.SOAPFaultException: These policy alternatives can not be satisfied: {http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}X509Token: The received token does not match the token inclusion requirement {http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}SignedParts: Soap Body is not SIGNED at org.apache.cxf.jaxws.DispatchImpl.mapException(DispatchImpl.java:285) at org.apache.cxf.jaxws.DispatchImpl.invoke(DispatchImpl.java:330) at org.apache.cxf.jaxws.DispatchImpl.invoke(DispatchImpl.java:241) at network.oxalis.as4.outbound.As4MessageSender.invoke(As4MessageSender.java:105) ... 14 common frames omitted Caused by: org.apache.cxf.ws.policy.PolicyException: These policy alternatives can not be satisfied: {http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}X509Token: The received token does not match the token inclusion requirement {http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}SignedParts: Soap Body is not SIGNED at org.apache.cxf.ws.policy.AssertionInfoMap.checkEffectivePolicy(AssertionInfoMap.java:179) at org.apache.cxf.ws.policy.PolicyVerificationInInterceptor.handle(PolicyVerificationInInterceptor.java:102) at org.apache.cxf.ws.policy.AbstractPolicyInterceptor.handleMessage(AbstractPolicyInterceptor.java:44) at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308) at org.apache.cxf.endpoint.ClientImpl.onMessage(ClientImpl.java:829) at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponseInternal(HTTPConduit.java:1696) at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponse(HTTPConduit.java:1570) at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1371) at org.apache.cxf.ext.logging.LoggingOutputStream.postClose(LoggingOutputStream.java:53) at org.apache.cxf.io.CachedOutputStream.close(CachedOutputStream.java:228) at org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:56) at org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:671) at org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:63) at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308) at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:530) at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:441) at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:356) at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:314) at org.apache.cxf.endpoint.ClientImpl.invokeWrapped(ClientImpl.java:349) at org.apache.cxf.jaxws.DispatchImpl.invoke(DispatchImpl.java:322) ... 16 common frames omitted Total time spent: 3s Attempted to send 0 files Failed transmissions: 1The text was updated successfully, but these errors were encountered: