I’m facing an issue with a SOAP integration in Pega related to WS-Security signature validation. The Service SOAP is returning the following error:
Number of Targets in the message dont match number of Targets in receiver requirements
From my understanding, this seems related to a mismatch between the elements that are signed in the request and the elements expected by the receiver policy.
I´ve set WS-Security Profile InFlow with Signature
If request has only one signature (for Body), and there is one Signature in InFlow configured, it works fine. But the system that invoking us has two signatures parts (Body and BinarySecurityToken) and I don´t know if is it possible to configure in Pega or not?
We have encountered the same issue. To solve this we have created our own function that validates the security header. We stopped using the Inflow configuration.
The Outflow does work for us. We can can sign multiple parts in that configuration.
The error usually means the receiver expects a different signature structure than what Pega is sending. In Pega WS-Security, the inbound policy is not just counting “how many signature blocks exist,” it is validating the set of signed targets against what the receiver requirements expect
Confirm whether the receiver truly requires two signatures or whether it expects:
one signature that covers multiple signed parts or
one signature plus a BinarySecurityToken for key identification only.
In the WS-Security Profile inbound configuration, make sure the signature settings allow multiple signatures if the incoming message actually has more than one signature block.
Verify the receiver-side policy is aligned with Pega’s generated message structure. WS-Security failures often come from a mismatch between the policy’s expected signed elements and the actual signed elements in the SOAP envelope.
A BinarySecurityToken is not always something that must be signed as a separate target. In many WS-Security implementations, it is used as the key identifier / token reference, while the actual message parts being signed are the SOAP Body and any other required elements. So the key question is whether the target system wants:
the Body signed and the token referenced or
multiple independent signatures, one of which also signs the token element itself.
I would suggest:
Compare the receiver’s WS-Security policy with the exact request generated by Pega.
Check whether the second signature is required by the policy or simply being added by the client tool.
If the receiver does require multiple signed parts, enable the inbound profile to accept multiple signatures and ensure the signed elements match the expected targets exactly.
If the receiver only expects Body signing, then remove the extra signature from the sender side and keep the message structure aligned with the policy.
Ok, I’ve got it, thank you! Seems like Pega Platform 25.1.2’s WS-Security InFlow validation currently supports signature verification for the SOAP Body element only.
