WCF federated client with issued token doesn't send SAML assertion signature - wcf

Question

I have an application that authenticates directly against a WIF/WCF active STS. The application is also a passive STS, acting as a WS-Federation endpoint for website relying parties.
When a user logs into a website RP, they're redirected to the passive STS for authentication (username and password) and in a two-step process, the passive STS (acting as an active RP) sends an Issue RST to the STS, and receives a signed SAML token in return. For the second step, the passive STS sends a second Issue RST to the STS, authenticating with the token in received in the previous step.
The problem is that during the second step, the WCF client strips the <Signature> element from the SAML assertion before sending it back to the STS in the SOAP header. I've verified (by test-serializing the token passed to ChannelFactory<TChannel>.CreateChannelWithIssuedToken) that the token still has the signature present when I call IWSTrustContract.Issue on the generated channel.
This is the assertion XML as it should be provided to the STS:
<saml:Assertion MajorVersion="1" MinorVersion="1" AssertionID="_0a5efbe5-446c-459c-8aaa-dda87748bca2" Issuer="https://sts.environment.com/" IssueInstant="2014-01-30T21:48:56.673Z" xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion">
<saml:Conditions NotBefore="2014-01-30T21:48:56.673Z" NotOnOrAfter="2014-01-30T22:48:56.673Z">
<saml:AudienceRestrictionCondition>
<saml:Audience>https://login.environment.com/</saml:Audience>
</saml:AudienceRestrictionCondition>
</saml:Conditions>
<saml:AttributeStatement>
<saml:Subject>
<saml:SubjectConfirmation>
<saml:ConfirmationMethod>urn:oasis:names:tc:SAML:1.0:cm:holder-of-key</saml:ConfirmationMethod>
<KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
<trust:BinarySecret xmlns:trust="http://docs.oasis-open.org/ws-sx/ws-trust/200512"><!--Removed--></trust:BinarySecret>
</KeyInfo>
</saml:SubjectConfirmation>
</saml:Subject>
<saml:Attribute AttributeName="upn" AttributeNamespace="http://schemas.xmlsoap.org/ws/2005/05/identity/claims">
<saml:AttributeValue><!--Removed--></saml:AttributeValue>
</saml:Attribute>
</saml:AttributeStatement>
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
<SignedInfo>
<CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
<SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256" />
<Reference URI="#_0a5efbe5-446c-459c-8aaa-dda87748bca2">
<Transforms>
<Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" />
<Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
</Transforms>
<DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256" />
<DigestValue><!--Removed--></DigestValue>
</Reference>
</SignedInfo>
<SignatureValue><!--Removed--></SignatureValue>
<KeyInfo>
<X509Data>
<X509Certificate><!--Removed--></X509Certificate>
</X509Data>
</KeyInfo>
</Signature>
</saml:Assertion>
And this is what the STS receives, per the Service Trace Viewer:
<saml:Assertion MajorVersion="1" MinorVersion="1" AssertionID="_0a5efbe5-446c-459c-8aaa-dda87748bca2" Issuer="https://sts.environment.com/" IssueInstant="2014-01-30T21:50:27.842Z" xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion">
<saml:Conditions NotBefore="2014-01-30T21:50:27.841Z" NotOnOrAfter="2014-01-30T22:50:27.841Z">
<saml:AudienceRestrictionCondition>
<saml:Audience>https://login.environment.com/</saml:Audience>
</saml:AudienceRestrictionCondition>
</saml:Conditions>
<saml:AttributeStatement>
<saml:Subject>
<saml:SubjectConfirmation>
<saml:ConfirmationMethod>urn:oasis:names:tc:SAML:1.0:cm:holder-of-key</saml:ConfirmationMethod>
<KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
<trust:BinarySecret xmlns:trust="http://docs.oasis-open.org/ws-sx/ws-trust/200512"><!--Removed--></trust:BinarySecret>
</KeyInfo>
</saml:SubjectConfirmation>
</saml:Subject>
<saml:Attribute AttributeName="upn" AttributeNamespace="http://schemas.xmlsoap.org/ws/2005/05/identity/claims">
<saml:AttributeValue><!--Removed--></saml:AttributeValue>
</saml:Attribute>
</saml:AttributeStatement>
</saml:Assertion>
Of course, the STS can't validate the signature of the assertion because it's been stripped, and it can't authenticate the client and issue the bearer token for the website RP.
Why is the WCF federated client stripping the signature from the assertion, and how can I make it not do that?