Develop Reference

WebServicesClientProtocol add EncodingType to Nonce in Security header

Similar question: How do I add an EncodingType attribute to the Nonce element of a UsernameToken in WSE 3.0 (.NET)
I'm trying to modify header that is send by WebServicesClientProtocol to service.
Unfortunately Microsoft's implementation of WSSE Username and Token Security Spec 1.1 isn't compatible with standard and isn't sending EncodingType with Nonce.
In similar question I've linked on top solution was to disable EncodingType validation on server, but I'm not able to modify anything.
I've imported WSDL as Web Reference, I've changed base class to WebServicesClientProtocol
Then inside my code I'm doing this:
var client = new QueryClient();
SoapContext requestContext = client.RequestSoapContext;
requestContext.Security.Timestamp.TtlInSeconds = 60;
var userToken = new UsernameToken(_userName, _password, PasswordOption.SendHashed);
requestContext.Security.Tokens.Add(userToken);
X509SecurityToken signatureToken = GetSecurityToken();
requestContext.Security.Tokens.Add(signatureToken);
MessageSignature sig = new MessageSignature(signatureToken);
requestContext.Security.Elements.Add(sig);
client.SetClientCredential(signatureToken);
client.SetClientCredential(new UsernameToken(_userName, _password, PasswordOption.SendHashed));
this creates request that is almost ideal, but Nonce hasn't got EncodingType:
<wsse:UsernameToken xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" wsu:Id="SecurityToken-096b3d09-bc08-4d9b-a561-c5c793dd7197">
<wsse:Username>ws_test_user</wsse:Username>
<wsse:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordDigest">XrFybEBGGqAIp2ybV6BbAdGa01U=</wsse:Password>
<wsse:Nonce>gXsJgA6vV/HwY4pew9pi9Q==</wsse:Nonce>
<wsu:Created>2017-02-03T12:17:57Z</wsu:Created>
</wsse:UsernameToken>
Nonce must have this attribute: EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary"
How can I add this attribute? I'd like to avoid manually creating request because I must specify Username, Password, BinarySecurityToken and Signature. Microsoft.Web.Services3 is creating all necessary elements for me, one thing missing is that attribute.
EDIT:
This is request I'm trying to create:
<soap:Envelope xmlns:dz="http://dom.query.api.com" xmlns:soap="http://www.w3.org/2003/05/soap-envelope" xmlns:xsd="http://dz.api.swd.zbp.pl/xsd">
<soap:Header>
<wsse:Security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
<wsse:UsernameToken wsu:Id="UsernameToken-E94CEB6F4708FB7C23148611494797612">
<wsse:Username>my_login</wsse:Username>
<wsse:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordDigest">XqEwZ/CxaBfFvh487TjvN8qD63c=</wsse:Password>
<wsse:Nonce EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary">JzURe0CxvzRjmEcH/ndldw==</wsse:Nonce>
<wsu:Created>2017-02-09T09:42:27.976Z</wsu:Created>
</wsse:UsernameToken>
<wsse:BinarySecurityToken EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary" ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509PKIPathv1" wsu:Id="X509-E94CEB6F4708FB7C2314861149479517">MIIKnDCCB.........nmIngeg6d6TNI=</wsse:BinarySecurityToken>
<ds:Signature Id="SIG-E94CEB6F4708FB7C23148611494795311" xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:SignedInfo>
<ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#">
<ec:InclusiveNamespaces PrefixList="dz soap xsd" xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#"/>
</ds:CanonicalizationMethod>
<ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
<ds:Reference URI="#id-E94CEB6F4708FB7C23148611494795310">
<ds:Transforms>
<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#">
<ec:InclusiveNamespaces PrefixList="dz xsd" xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#"/>
</ds:Transform>
</ds:Transforms>
<ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<ds:DigestValue>mlABQuNUFOmLqsDswxXxQ6XnjpQ=</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>lYhBHSQ/L...XL1HEbMQjJ/Q2Rvg==</ds:SignatureValue>
<ds:KeyInfo Id="KI-E94CEB6F4708FB7C2314861149479518">
<wsse:SecurityTokenReference wsse11:TokenType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509PKIPathv1" wsu:Id="STR-E94CEB6F4708FB7C2314861149479519" xmlns:wsse11="http://docs.oasis-open.org/wss/oasis-wss-wssecurity-secext-1.1.xsd">
<wsse:Reference URI="#X509-E94CEB6F4708FB7C2314861149479517" ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509PKIPathv1"/>
</wsse:SecurityTokenReference>
</ds:KeyInfo>
</ds:Signature>
</wsse:Security>
</soap:Header>
<soap:Body wsu:Id="id-E94CEB6F4708FB7C23148611494795310" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
<dz:query>
<dz:param>
<xsd:userQueryId>27467</xsd:userQueryId>
</dz:param>
</dz:query>
</soap:Body>
</soap:Envelope>
I've send my request to service creator and he confirm that all I need is that EncodingType attribute in Nonce

The EncodingType flag is according to the WSSE Username and Token Security Spec 1.1, which is the spec required by the version of the Apache CXF framework that this Java Web Service is using. .NET does not meet that spec. Luckily there was a flag in CXF to turn off the requirement. We did that and are now able to communicate.

Whitespace is determining the validity of my digital signature

I have an XML digital signature, serialized with line breaks and indentation, as per the defaults in XmlSerializer. It fails the .net SignedXml.CheckSignature() test. If I strip out the line breaks and indentation, it passes. Is this the expected behaviour? Can the signature be considered robust and cross-platform if the default serialization, or a cosmetic change to the signature, breaks its validity? Should I be considering the binary pkcs formats for robustness. The signature, as serialized with line breaks, is below.
<?xml version="1.0"?>
<ds:Signature Id="SignatureID" xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:SignedInfo>
<ds:CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315" />
<ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" />
<ds:Reference URI="http://localhost/simondocs/images/succes.png">
<ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
<ds:DigestValue>Dv7mVn07JAKmm77J0PzqJ1N00SI=</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue Id="SignatureID">FHQiNBNrNVm/0yCNrvlifVpw9I10fyEQkXrAGslIOzBRtnPRBUDS3tE9RtvWbVxObQLhkn4Im5wcZoOtvl/K8fiAe45Pwvj3Q7trql+BCq3jDogYi83mlSaoW1ScU5Vmdl/jv6qfros0R7jelEqNiEkIF1n8dCZJBdzY/pY2vhkzM2MeiPxfHRYgMT3tgMUkhBGiU6EjGtitSWT840L/dz3HIRSXr4PCx7qAV108S8ICkXJPTp4Qs+32Tk1T7ha45BN7A+rHtyupd2xrCu7JCEHDn3k0XJL0/ARprqvZVpzqt2c/GLCjrX3fAJy7Yxs/3fOusA7jNm7qVHxFKHJAYA==</ds:SignatureValue>
<ds:KeyInfo>
<ds:X509Data>
<ds:X509Certificate>MIIFPjCCBCagAwIBAgIRAIzFm3K+lU+T8UNfa4YidgAwDQYJKoZIhvcNAQELBQAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xNTEyMDEwMDAwMDBaFw0xNjExMzAyMzU5NTlaMCQxIjAgBgkqhkiG9w0BCQEWE2Jic2ltb25iYkBnbWFpbC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDIKK/6gK0lX2PpRT+O5Ghh8JcKShLSyeZ9HTeCH24oponyvcSJwYsXGk0eXH79RNJJI3J6elcjfVISRnujZmCOiAuFd1mdRWnlqtduVjPljxarSIxPj2cUvhZU2ybrp34q+MQ6mQPORb8IxLzglDUwYyAQ+ygt0mNHitdozqSB31j9ynDv+CdWQnXx3K6dfmO9djBlha1nhbqamcnz+XiOIp8YtWHBuDQiRQG1p0HVADHOCGxHo4+6gYCTZkP+t0rG2SZeI3m1GoelEp8KHdwGGGFqINbv+L4er6ZqBLmoMaHyFRQlF5D7t6LlrtJl57D+C+BbjvJdz9Es1io01t8jAgMBAAGjggHxMIIB7TAfBgNVHSMEGDAWgBSSYWuC4aKgqk/sZ/HCo/e0gADB7DAdBgNVHQ4EFgQUzX5+StqAfFWq8akUIZOEr6/OqvYwDgYDVR0PAQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0lBBkwFwYIKwYBBQUHAwQGCysGAQQBsjEBAwUCMBEGCWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAEPzA9MDsGDCsGAQQBsjEBAgEBATArMCkGCCsGAQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0L0NQUzBdBgNVHR8EVjBUMFKgUKBOhkxodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9TSEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3JsMIGQBggrBgEFBQcBAQSBgzCBgDBYBggrBgEFBQcwAoZMaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPU0hBMjU2Q2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMB4GA1UdEQQXMBWBE2Jic2ltb25iYkBnbWFpbC5jb20wDQYJKoZIhvcNAQELBQADggEBACxK9UPMHxVhnBacp9nG9E4YK76GcQs3XbbX41VYYIwWgqVOSVfsY4bEQIs6j0JDY26KsIPMcvJL1XS5yT8UzZImL+GzmrPAKcts6jD2/KIXXpCC6FI3dQ+iOlMEJXlRQA6sY+a+viKgApzZHObL+SAh9DaALsaMdaYUKS+u9glS08BsT+LEqPagSwDkvV0molN8WDg1io4OfqY1k2nxx4cvMYHFXoC89d+Qq2+atqBfQZ9b6WzQagazdSZCdHF7dSM0r16SKUAW4XL1LQa+IHyFi8bfYEuqredeOtb9y5pOpTtaZqymCKCn/IeXQfTjSRXUmCR3Gtnsmd550XkSnRQ=</ds:X509Certificate>
</ds:X509Data>
<ds:KeyValue>
<ds:RSAKeyValue>
<ds:Modulus>yCiv+oCtJV9j6UU/juRoYfCXCkoS0snmfR03gh9uKKaJ8r3EicGLFxpNHlx+/UTSSSNyenpXI31SEkZ7o2ZgjogLhXdZnUVp5arXblYz5Y8Wq0iMT49nFL4WVNsm66d+KvjEOpkDzkW/CMS84JQ1MGMgEPsoLdJjR4rXaM6kgd9Y/cpw7/gnVkJ18dyunX5jvXYwZYWtZ4W6mpnJ8/l4jiKfGLVhwbg0IkUBtadB1QAxzghsR6OPuoGAk2ZD/rdKxtkmXiN5tRqHpRKfCh3cBhhhaiDW7/i+Hq+magS5qDGh8hUUJReQ+7ei5a7SZeew/gvgW47yXc/RLNYqNNbfIw==</ds:Modulus>
<ds:Exponent>AQAB</ds:Exponent>
</ds:RSAKeyValue>
</ds:KeyValue>
</ds:KeyInfo>
</ds:Signature>

WCF Client With X.509 Certificate and Java Web Service

I'm currently trying to develop a client that interacts with a 3rd party web service. The third party web service is written in Java, and we have supplied them with a CA X509 certificate that is used to sign the messages. The 3rd party specifies WS-Security 1.1 (http://docs.oasis-open.org/wss/v1.1/wss-v1.1-spec-os-SOAPMessageSecurity.pdf).
We are able to successfully sign the message, send and get a response through SoapUI, but I am having trouble to get the same functionality to work in WCF (.NET 4.5). I've looked at the message being sent from the WCF client (via SvcTraceViewer and the message logs), and it appears the format is slightly different from that in SoapUI.
When I send the message, I get the following exception:
There was no endpoint listening at https://<service addres> that could accept the message. This is often caused by an incorrect address or SOAP action. See InnerException, if present, for more details.
The inner exception is Unable to connect to the remote server, and the inner exception for that is A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond XXX.XXX.XXX.XXX:443.
Since the endpoint is up and available, I'm thinking my binding is not set up entirely correctly.
I've checked questions here on SO, including Signing SOAP messages using X.509 certificate from WCF service to Java webservice and read Yaron Naveh's 12 common wcf interop confusions which have helped, but haven't gotten me all the way there yet.
Binding defintion:
<customBinding>
<binding name="myCustomBinding">
<textMessageEncoding messageVersion="Soap11" />
<security authenticationMode="MutualCertificate"
defaultAlgorithmSuite="Basic128Sha256Rsa15"
includeTimestamp="true"
messageSecurityVersion="WSSecurity10WSTrustFebruary2005WSSecureConversationFebruary2005WSSecurityPolicy11BasicSecurityProfile10"
securityHeaderLayout="LaxTimestampLast" />
<httpsTransport />
</binding>
</customBinding>
Method to create the proxy factory:
private Task<ChannelFactory<T>> CreateChannelFactory<T>(string bindingConfig, string address)
{
EndpointAddress endpoint = new EndpointAddress(new Uri(address), EndpointIdentity.CreateDnsIdentity(<identity name>));
ChannelFactory<T> proxy = new ChannelFactory<T>(new CustomBinding(bindingConfig), endpoint);
proxy.Credentials.ClientCertificate.SetCertificate(storeLocation, storeName, findByType, findByValue);
proxy.Credentials.ServiceCertificate.SetDefaultCertificate(storeLocation, storeName, findByType, findByValue);
return Task.FromResult<ChannelFactory<T>>(proxy);
}
The 3rd party actually has several services (one operation contract per service, essentially), so I generate ChannelFactory<T> objects for each service at client start using async/await, and the values storeLocation, storeName, findByType and findByValue for the certificate are stored globally in the client (in case any one was wondering).
When I send the message, I create a channel from the appropriate factory. And then I get the error.
Here is the relevant part of the message sent via SoapUI (that works):
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:view="http://<service namespace>">
<soapenv:Header>
<wsse:Security soapenv:mustUnderstand="1"
xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
<wsse:BinarySecurityToken EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary"
ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3"
wsu:Id="X509-F4F47BCAA968D14D08143033737254925">(data)</wsse:BinarySecurityToken>
<ds:Signature Id="SIG-F4F47BCAA968D14D08143033737254928"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:SignedInfo>
<ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#">
<ec:InclusiveNamespaces PrefixList="soapenv view"
xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#"/>
</ds:CanonicalizationMethod>
<ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
<ds:Reference URI="#TS-F4F47BCAA968D14D08143033737254624">
<ds:Transforms>
<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#">
<ec:InclusiveNamespaces PrefixList="wsse soapenv view"
xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#"/>
</ds:Transform>
</ds:Transforms>
<ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
<ds:DigestValue>hg5n7PfuAfYb/LEawatI4ZBK0wmy14+Y6DihGhgBMI4=</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>(data)</ds:SignatureValue>
<ds:KeyInfo Id="KI-F4F47BCAA968D14D08143033737254926">
<wsse:SecurityTokenReference wsu:Id="STR-F4F47BCAA968D14D08143033737254927">
<wsse:Reference URI="#X509-F4F47BCAA968D14D08143033737254925"
ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3"/>
</wsse:SecurityTokenReference>
</ds:KeyInfo>
</ds:Signature>
<wsu:Timestamp wsu:Id="TS-F4F47BCAA968D14D08143033737254624">
<wsu:Created>2015-04-29T19:56:12Z</wsu:Created>
<wsu:Expires>2015-04-29T19:56:17Z</wsu:Expires>
</wsu:Timestamp>
</wsse:Security>
</soapenv:Header>
<soapenv:Body>
<!-- Not relevant. Not signed -->
</soapenv:Body>
</soapenv:Envelope>
Here is the message produced by WCF with the specified bindings:
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:u="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
<s:Header>
<VsDebuggerCausalityData xmlns="http://schemas.microsoft.com/vstudio/diagnostics/servicemodelsink">uIDPo8j1TaWVCpRLgEy0S8UuwAcBAAAAAkQP7Rrb00auQ0G7/7Q0C1x7YNOf+kFOt9ioJVgbfFYACQAA</VsDebuggerCausalityData>
<o:Security s:mustUnderstand="1"
xmlns:o="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
<o:BinarySecurityToken>
<!-- Removed-->
</o:BinarySecurityToken>
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
<SignedInfo>
<CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"></CanonicalizationMethod>
<SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"></SignatureMethod>
<Reference URI="#_1">
<Transforms>
<Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"></Transform>
</Transforms>
<DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"></DigestMethod>
<DigestValue>8KAbTZRA1cC60emKdKIiIm3zvv1jPPfVaia3a9l1c3g=</DigestValue>
</Reference>
<Reference URI="#uuid-5cb02cb6-0ae6-486d-ad2b-f9f9107b4576-2">
<Transforms>
<Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"></Transform>
</Transforms>
<DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"></DigestMethod>
<DigestValue>zR0k1GizuQekuM9WcSzVGssZowuzj3Dza/WGYmMqjSo=</DigestValue>
</Reference>
</SignedInfo>
<SignatureValue>(data)</SignatureValue>
<KeyInfo>
<o:SecurityTokenReference>
<o:Reference ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3"
URI="#uuid-96e7c3a3-cbe9-409e-ad49-9dcc07ef4360-2"></o:Reference>
</o:SecurityTokenReference>
</KeyInfo>
</Signature>
<u:Timestamp u:Id="uuid-5cb02cb6-0ae6-486d-ad2b-f9f9107b4576-2">
<u:Created>2015-04-30T18:00:28.886Z</u:Created>
<u:Expires>2015-04-30T18:05:28.886Z</u:Expires>
</u:Timestamp>
</o:Security>
</s:Header>
<s:Body u:Id="_1"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
</s:Body>
</s:Envelope>
Here are differences/missing items from the WCF version compared to the SoapUI version:
<BinarySecurityToken> missing EncodingType, ValueType and Id
attributes.
<Signature> missing Id attribute.
'CanonicalizationMethodmissing
<Reference> two elements instead of 1. Not sure what the URI attribute is for (in the WCF version).
<KeyInfo> missing Id attribute.
<SecurityTokenReference> missing Id attribute.
Everything else seems to match up (with the exception of namespace prefixes and where they are assigned). I would prefer to do this via a custom binding, but I'm open to implementing IClientMessageInspector if I need to massage the outgoing request.

I was able to resolve this issue this morning. There were 2 issues at hand.
The first appears to be related to my company's VPN. I was able to send and receive responses yesterday in the office (as opposed to the day I posted the question, when I was on VPN). Last night on the VPN again I was getting the There was no endpoint listening at https://<service addres> that could accept the message. This is often caused by an incorrect address or SOAP action. See InnerException, if present, for more details. exception again, so I deployed the client to one of our dev servers and was able to communicate successfully again.
The second issue was discovered once I was able to send the message. I saw the response in the trace message logs, but I received a new exception:
Security processor was unable to find a security header in the message. This might be because the message is an unsecured fault or because there is a binding mismatch between the communicating parties. This can occur if the service is configured for security and the client is not using security.
The request is signed (by the client), but the response is unsigned. Setting the enableUnsecuredResponse attribute on the custom binding to true resolved this issue.
The final custom binding configuration looks like this:
<customBinding>
<textMessageEncoding messageVersion="1.1" />
<security authenticationMode="MutualCertificate"
defaultAlgorithmSuite="Basic128Sha256Rsa15"
enableUnsecuredResponse="true"
includeTimestamp="true"
messageSecurityVersion="WSSecurity10WSTrustFebruary2005WSSecureConversationFebruary2005WSSecurityPolicy11BasicSecurityProfile10"
securityHeaderLayout="LaxTimestampLast" />
<httpsTransport />
</customBinding>
No changes in the code for setting the certificates, with the exception of making the name passed into EndpointIdentity.CreateDnsIdentity configurable.

Can't figure out why SAMLMessageSignature.Verify is returning false

I have setup Shibboleth as an IdP, using its default credentials (the certificates bundled with the installer). I think it is using the idp-signing.crt certificate to sign SAML responses. Using the LowLevelAPI ShibbolethSP example project, I have been able to login through the Shibboleth IdP, as long as I comment out the "Verify the response's signature" code. I made sure I added in SHA-256 XML signature support in Global.asax.cs, Application_Start. The message signature verification always returns false, even when I copy the idp-signing.crt file into the example directory and load that as a X509Certificate2 object, passing that in:
bool retVal = SAMLMessageSignature.Verify(samlResponseXml, x509Certificate); // is false
It even returns false when I pass no second param in, using the key info included with the signature to perform the verification:
bool retVal = SAMLMessageSignature.Verify(samlResponseXml); // is false
I can't figure out why this verification is failing. Here is a SAML response that is posted back from Shibboleth (formatted by FOXE but otherwise unchanged):
<?xml version="1.0" encoding="UTF-8"?>
<saml2p:Response Destination="http://localhost:65231/SAML/AssertionConsumerService.aspx" ID="_b69dae7dd40119cff94ece076e338e82" InResponseTo="_031b0667-d6e5-4845-add1-f82748afe0e6" IssueInstant="2015-02-06T14:07:47.193Z" Version="2.0" xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol">
<saml2:Issuer xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">http://localhost:3380/idp/shibboleth</saml2:Issuer>
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:SignedInfo>
<ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
<ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
<ds:Reference URI="#_b69dae7dd40119cff94ece076e338e82">
<ds:Transforms>
<ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
</ds:Transforms>
<ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
<ds:DigestValue>kL7hYIdYRk+x27VboYeYmIzOSfokmY8iPfucnFzI5Nk=</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>
V/bRv+kjvXcTOQs3d2TjyB4d0fjW5xSl5/8RJzCf1K988DsUWVqZEswxo4iqPVsjQgkelppbcnPa
9UTjLJLIQLg6ztXrfaXYE6iHZcYw58upBcnTXgNGuKazvLm6j2wxBtm5RNe8I4vO0YtDvV3GNf6X
qVICZlhp7VC0bNiCMr7zVXcw0E4ZfCSJt3Tph9MGKK6KrSXzVSpsyagtvBnmDx2CpI+O0hW92ekk
CjjkPcvY0lfl3rYdN/xpUqsJgc6HfhnBeU+y+RgEyb0eLuN/aZBOfiWMSAtMkJhcaoESwBtlaFg/
m46jdarT6ZDGfU9J4JnOzkAHlr8nMlEKcEzD8g==
</ds:SignatureValue>
<ds:KeyInfo>
<ds:X509Data>
<ds:X509Certificate>MIIDIDCCAgigAwIBAgIVANgMuf9G9xkZYBghdEkxjLMPwHJhMA0GCSqGSIb3DQEBCwUAMBgxFjAU
BgNVBAMMDWlzYW1zLXdyay0wNjAwHhcNMTUwMjA0MTU0MjQ1WhcNMzUwMjA0MTU0MjQ1WjAYMRYw
FAYDVQQDDA1pc2Ftcy13cmstMDYwMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAq3l+
c0OfVj6Qex2Rwd+katoP9BLsrur/aR19mfepT5E2E/2TDWkl+dY87O4eS/J/NKTftS0MeL8qhoZB
Hf3y/zetOayoqhW5eCsrWwsY4HuVBhBBctuv0xdBmQPUP8Avmdr83Ps0xvCu2661aAz5SRA1SOlP
QbE/STLnDoFORhaoVAFHUq0zIscjCwUFrhHvEQZQWMTeaDCZdSP6jFmZ6SCWJCvjq7FIz5KbPh5p
IBhaWUVIoGEg3gwGKEt25sZ6y7RSFnqEzWgJhUoHE8HgL4inGulTIeeESxztQqdRK7lkTz1VwwO/
zulQdwcw1xWQc6JOMDh9wqJxcMQOZ2OlgQIDAQABo2EwXzAdBgNVHQ4EFgQUDAZa8uahYPYMrzbv
P8+PRP47IzEwPgYDVR0RBDcwNYINaXNhbXMtd3JrLTA2MIYkaHR0cHM6Ly9pc2Ftcy13cmstMDYw
L2lkcC9zaGliYm9sZXRoMA0GCSqGSIb3DQEBCwUAA4IBAQCLh6w9di9jggroTxCsX30eqVv+DSfG
vOy1Ajj9ZFbXz5N7lhnwiLnWkiC4sx9Ls4cObj9AmGCAw/G2VOv2DRfRujFt0QTRfervmT1dJADv
m2RsV4vq13Kbj5fh6ThCzTMU+XsRc6dY2KRiDMrR3ofdqIl90U4J4NeyFYvIwEKHSDrnLM2Fp6tu
pWso0hDDSszuIKlhTue0kKXLpiJMEvc06mCqA8XZCCj26D6DdTNUI24puTfUELWXSMflD2/lg0/w
L1k/5kVbgT4vqVci6Sz9ggi8mge2zjRtx4JkHIjXc20e43oRPh7LF/2wQVqiobmZQYzvMi5TPY1x
w0oA4g5A</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</ds:Signature>
<saml2p:Status>
<saml2p:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
</saml2p:Status>
<saml2:Assertion ID="_9d0be4db6f36fbd7026dc1efd7dfc224" IssueInstant="2015-02-06T14:07:47.193Z" Version="2.0" xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">
<saml2:Issuer>http://localhost:3380/idp/shibboleth</saml2:Issuer>
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:SignedInfo>
<ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
<ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
<ds:Reference URI="#_9d0be4db6f36fbd7026dc1efd7dfc224">
<ds:Transforms>
<ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
</ds:Transforms>
<ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
<ds:DigestValue>hR6KDOh+st3yunebqeUz4aqHMin/5rc6gHrkIwgypLc=</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>
V9BB0UEBqsBGsiUHbVH8mw8sG52pLI6ec/lGMCqeNGqTUYF8HwOPpjkViJ/Pz91HRFIgRoPlVqHy
dRGMAJFpYvakOh/vB1+GP3T0Jh20gF8I7JfzOfMwuF8A5ryEdoxB6JQp0AR6mEXi88RPFfWrAmB1
G/mTt6Q94uW0lrqfiyphp49K6HNhRvyIOCOLWtthBdnMQPLlCh6NAMaJAh+2dzx2CjeT4P58H9FP
ANJQxB+JR3J2cum5XVn+Rrrx6fiL640I514G0dDu2bi4InXMGH/mKXVCLQX4w/1g0fGv/icrdY9H
734JhawjfY/+NfO4Fj3+E6Yx3+k8ytku0qUZkw==
</ds:SignatureValue>
<ds:KeyInfo>
<ds:X509Data>
<ds:X509Certificate>MIIDIDCCAgigAwIBAgIVANgMuf9G9xkZYBghdEkxjLMPwHJhMA0GCSqGSIb3DQEBCwUAMBgxFjAU
BgNVBAMMDWlzYW1zLXdyay0wNjAwHhcNMTUwMjA0MTU0MjQ1WhcNMzUwMjA0MTU0MjQ1WjAYMRYw
FAYDVQQDDA1pc2Ftcy13cmstMDYwMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAq3l+
c0OfVj6Qex2Rwd+katoP9BLsrur/aR19mfepT5E2E/2TDWkl+dY87O4eS/J/NKTftS0MeL8qhoZB
Hf3y/zetOayoqhW5eCsrWwsY4HuVBhBBctuv0xdBmQPUP8Avmdr83Ps0xvCu2661aAz5SRA1SOlP
QbE/STLnDoFORhaoVAFHUq0zIscjCwUFrhHvEQZQWMTeaDCZdSP6jFmZ6SCWJCvjq7FIz5KbPh5p
IBhaWUVIoGEg3gwGKEt25sZ6y7RSFnqEzWgJhUoHE8HgL4inGulTIeeESxztQqdRK7lkTz1VwwO/
zulQdwcw1xWQc6JOMDh9wqJxcMQOZ2OlgQIDAQABo2EwXzAdBgNVHQ4EFgQUDAZa8uahYPYMrzbv
P8+PRP47IzEwPgYDVR0RBDcwNYINaXNhbXMtd3JrLTA2MIYkaHR0cHM6Ly9pc2Ftcy13cmstMDYw
L2lkcC9zaGliYm9sZXRoMA0GCSqGSIb3DQEBCwUAA4IBAQCLh6w9di9jggroTxCsX30eqVv+DSfG
vOy1Ajj9ZFbXz5N7lhnwiLnWkiC4sx9Ls4cObj9AmGCAw/G2VOv2DRfRujFt0QTRfervmT1dJADv
m2RsV4vq13Kbj5fh6ThCzTMU+XsRc6dY2KRiDMrR3ofdqIl90U4J4NeyFYvIwEKHSDrnLM2Fp6tu
pWso0hDDSszuIKlhTue0kKXLpiJMEvc06mCqA8XZCCj26D6DdTNUI24puTfUELWXSMflD2/lg0/w
L1k/5kVbgT4vqVci6Sz9ggi8mge2zjRtx4JkHIjXc20e43oRPh7LF/2wQVqiobmZQYzvMi5TPY1x
w0oA4g5A</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</ds:Signature>
<saml2:Subject>
<saml2:NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient" NameQualifier="http://localhost:3380/idp/shibboleth" SPNameQualifier="http://localhost:65231/SAML/metadata.xml">AAdzZWNyZXQxpeMWTEyWX1tgYmk7ixdbi775mfBFBHikiub8dsf7HLwD2Xo5yPhD2HL21GF3Hle9oYEQCMFJ3R2dxZ8y22FknvLoGmDZ++VdymaQB0WpEaMzy3Ox9g8X6ALYMdZWedk78uCbpSvjpqdCM4Lhi13VdAQqvAs=</saml2:NameID>
<saml2:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
<saml2:SubjectConfirmationData Address="127.0.0.1" InResponseTo="_031b0667-d6e5-4845-add1-f82748afe0e6" NotOnOrAfter="2015-02-06T14:12:47.236Z" Recipient="http://localhost:65231/SAML/AssertionConsumerService.aspx"/>
</saml2:SubjectConfirmation>
</saml2:Subject>
<saml2:Conditions NotBefore="2015-02-06T14:07:47.193Z" NotOnOrAfter="2015-02-06T14:12:47.193Z">
<saml2:AudienceRestriction>
<saml2:Audience>http://localhost:65231/SAML/metadata.xml</saml2:Audience>
</saml2:AudienceRestriction>
</saml2:Conditions>
<saml2:AuthnStatement AuthnInstant="2015-02-06T14:07:47.057Z" SessionIndex="_267b5fd351054d45e5961e83427483fe">
<saml2:SubjectLocality Address="127.0.0.1"/>
<saml2:AuthnContext>
<saml2:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:Password</saml2:AuthnContextClassRef>
</saml2:AuthnContext>
</saml2:AuthnStatement>
<saml2:AttributeStatement>
<saml2:Attribute FriendlyName="username" Name="urn:ecolint.ch:attribute-def:username" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
<saml2:AttributeValue>Jeremy.Morton</saml2:AttributeValue>
</saml2:Attribute>
</saml2:AttributeStatement>
</saml2:Assertion>
</saml2p:Response>
Can anyone tell me why the Verify method might always be returning false?

Assertions from Testshib are encrypted.
I use the low level api from component space. We are an SP for many clients and support numerous idP's
The SAMLResponse class has three methods I use testing the assertions from an idP.
First I try .GetAssertions().
If that doesn't return the assertions, I try .GetSignedAssertion(certificate).
If that doesn't return the assertion, I try .GetEncryptedAssertions()
The last is always where I get the assertions for Testshib.
Then, if you are using X509Certificate2, when you load your pfx file, you have to create that object with X509KeyStorageFlags.Exportable. If not the private key will always be null.
I do something like this:
var key = pfxCertificate.PrivateKey;
if (key==null)
{
throw new NullReferenceException("pfx private key is null");
}
foreach (var encryptedAssertion in encryptedAssertions)
{
assertions.Add(encryptedAssertion.Decrypt(key, null));
}
if (assertions.Count > 0)
{
samlAssertion = assertions[0];
}
Finally, if you alter your SP metadata certificate you MUST upload it again to Testshib on their registration tab. The encrypted assertions use your certificate to encrypt. So, you use your private key to decrypt. If this doesn't match what was uploaded to Testshib, it will never decrypt. Make sure the file name of your SP metadata is unique in the world, something like
CrazyLikelyUniqueInTheWorld2939596.xml Otherwise, someone else will overwrite your SP test metadata on Testshib if you name it something like spmetadata.xml

Sign SOAP Request using X509 from WCF Client

I have a requirement where I have to call 3rd Party web service using wcf client. The third party service which I have to call is secure web service and uses https so for ex. https://kavyen.com/md. The service provider has provided me both server and client certificates.
I have to create a wcf client which Signs the SOAP Request but doesn't encrypt, so in other words I need to have Signing information in SOAP Header but doesn't want entire body to be encrypted.
Below is the sample of SOAP envelop which I must have to send from wcf client.
<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Header>
<wsse:Security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" soapenv:mustUnderstand="1">
<wsse:BinarySecurityToken xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary" ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3" wsu:Id="CertId-639F96823FC161A915140921867132422">MIICmDCCAYACEGkpMaS8nUlq58nKTzVZubIwDQYJKoZIhvcNAQEFBQAwRjELMAkGA1UEBhMCSUUxHjAcBgNVBAoTFVJldmVudWUgQ29tbWlzc2lvbmVyczEXMBUGA1UEAxMOREVWUEtJMSBTdWIgQ0EwHhcNMTMwOTI0MDgwNTQxWhcNMTUwOTI0MDgwNTQxWjBTMQswCQYDVQQGEwJJRTEXMBUGA1UEChMOVEVTVCBDT01QQU5ZIDUxEjAQBgNVBAsTCTYxOTEyODc1NzEXMBUGA1UEAxMOVEVTVCBDT01QQU5ZIDUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMiliAb+XYJpkEMkwPAG4IObXlwnMdnQ04jNWrholmjmY/PgiPV4/oe1opScyHxI26sq+u4U+aBKyx2mgRDLqn2rpgVsEsq60mzFwuYBYRHLUS0rrQki13jbvoOvPWlAMgR42iF0V3GKr34Zm6i4lw4vLJzju+Xwup9UJhP8NM1nAgMBAAEwDQYJKoZIhvcNAQEFBQADggEBAEOrsjUXMgMUQlnsupvl3e07/SA6r7idXCXZ/cbIi6ZzyAkPZOsUJQ7nUIckUF04jJTNJWfVYzs7+sY1c67G7r1MjypyfVH4JIckDFmF2Q5MmyePTGICm2ZeNm+3sJI8ApfbMNYDfXSSY7UXJVt1jhE+M3d2JGXirG+XrZC29/dcqIYixTkiBfDEP16LUTPcHseA/DKzGP43O92r5VP1oa07HA1nHt7W2CbT4MMqEpurBMC0EWkc/LzK0LKGUomZSDUHTOKisHPG5AKrV71EFJnR46eq+Ro6C781dbztkuHj8HH+8CdFuknq2+B7XCVVJTv1F3PVrCC5x8gsoR79oAo=</wsse:BinarySecurityToken>
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#" Id="Signature-8">
<ds:SignedInfo>
<ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
<ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
<ds:Reference URI="#Id-762175305">
<ds:Transforms>
<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
</ds:Transforms>
<ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<ds:DigestValue>WAtX3NtBp52Y5beBeL28QtPq6LE=</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>
OibCc5mrk6noqbukfcxy8Tt/d8+/JlOm9Nmx3nrD1i00HWjqi3v55sbnUowCPGA+fztRcIXhuWYF
GlQyrRxxPLhnvM6vfk9zEZYbS/34dudp9H8gswPh+wsWa0/nowgSoo+eK5I0AbYNqCIHD3EUAfzG
/Br+gMqtRuZyZbhtKbg=
</ds:SignatureValue>
<ds:KeyInfo Id="KeyId-639F96823FC161A915140921867132623">
<wsse:SecurityTokenReference xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" wsu:Id="STRId-639F96823FC161A915140921867132624">
<wsse:Reference URI="#CertId-639F96823FC161A915140921867132422" ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3"/>
</wsse:SecurityTokenReference>
</ds:KeyInfo>
</ds:Signature>
</wsse:Security>
</soapenv:Header>
<soapenv:Body xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" wsu:Id="Id-762175305">
<TestMessage>This is a test.</TestMessage>
</soapenv:Body>
</soapenv:Envelope>
The service provider

Use this binding:
<customBinding>
<binding name="NewBinding0">
<textMessageEncoding messageVersion="Soap11" />
<security authenticationMode="MutualCertificate" includeTimestamp="false"
messageSecurityVersion="WSSecurity10WSTrustFebruary2005WSSecureConversationFebruary2005WSSecurityPolicy11BasicSecurityProfile10">
<secureConversationBootstrap />
</security>
<httpTransport />
</binding>
</customBinding>
Also decorate your contracts with this attribute:
[System.ServiceModel.ServiceContractAttribute(ConfigurationName=..., ProtectionLevel=System.Net.Security.ProtectionLevel.Sign)]
The contract is in reference.cs.