I recently had to call a secured WebSphere service from a WCF client. Fine tuning all the settings was challenging so I turned on WCF tracing. The latter gave me detailed errors which helped me to see where I was wrong. But after fixing everything I knew of, I got this new error:
An element, ActivityId, with nsuri, http://schemas.microsoft.com/2004/09/ServiceModel/Diagnostics, is not protected by signing algorithm, sha1, and digest algorithm Rejected by filter; SOAP fault sent
Having no idea where this ActivityId element comes from , I took a quick look at the message my Wcf client was sending:
<s:Header>
<ActivityId CorrelationId="db5feb51-ae82-4c1b-bd68-1bdb2d09bbc6" xmlns="http://schemas.microsoft.com/2004/09/ServiceModel/Diagnostics">f5aada53-669f-46d7-acc5-8d45e437ed86</ActivityId>
</s:Header>Where does this
ActivityId come from?
Turns out this header is emitted by WCF when we turn tracing on. Wcf uses this header to color the message as it flows between various layers so it can later show a single view of it. In my case the WebSphere expected clients to sign all headers. This particular header was not signed (since WCF tracing just adds it as is) so WebSphere complained about a policy violation.
After turning off the WCF trace settings the integration worked like a charm. So you can say the whole issue was kind of a drug side affect.
{{ parent.title || parent.header.title}}
{{ parent.tldr }}
{{ parent.linkDescription }}
{{ parent.urlSource.name }}