WS-Security overhead when using message security

Question

The following is a message logged in Microsoft Service Trace Viewer. I believe it represents a single call to a parameterless method that has an integer return value on a WCF Service (with WsHttpBinding). I am using message level security (with username credentials) and created a development server certificate to get this to work. I am baffled by the amount of overhead in the header. Has anyone seen this before? I am not even sure if I am looking at the right thing. I was planning to use this on every call, and I was hoping the overhead would be reduced on subsequent method calls on the same service, but this does not seem to be the case.

I am tempted to create a single Login() method over SSL instead that authenticates a user and returns a GUID that will be passed to authenticate subsequent requests, with an expiration policy per GUID etc. Intuitively I think this may be a bad idea but I am a security dummy so I am not sure.

Any advise is appreciated.

<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope"&gt;
<s:Header>
<a:Action s:mustUnderstand="1" u:Id="_2" xmlns:u="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" xmlns:a="http://www.w3.org/2005/08/addressing"&gt;http://tempuri.org/IWsAppointmentService/GetTest&lt;/a:Action&gt;
<a:MessageID u:Id="_3" xmlns:u="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" xmlns:a="http://www.w3.org/2005/08/addressing"&gt;urn:uuid:d83df40a-979b-440c-9292-7a5a84a64ecd&lt;/a:MessageID&gt;
<a:ReplyTo u:Id="_4" xmlns:u="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" xmlns:a="http://www.w3.org/2005/08/addressing"&gt;
<a:Address>http://www.w3.org/2005/08/addressing/anonymous&lt;/a:Address&gt;
</a:ReplyTo>
<a:To s:mustUnderstand="1" u:Id="_5" xmlns:u="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" xmlns:a="http://www.w3.org/2005/08/addressing"&gt;http://localhost:8731/service/ws&lt;/a:To&gt;
<o:Security s:mustUnderstand="1" xmlns:o="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"&gt;
<u:Timestamp u:Id="uuid-169b0950-217e-48af-9057-ea832e0c7e19-14" xmlns:u="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"&gt;
<u:Created>2009-09-08T14:08:36.224Z</u:Created>
<u:Expires>2009-09-08T14:13:36.224Z</u:Expires>
</u:Timestamp>
<c:SecurityContextToken u:Id="uuid-95cdaf11-3974-4cc0-93a8-a3d2191bbef4-5" xmlns:c="http://schemas.xmlsoap.org/ws/2005/02/sc" xmlns:u="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"&gt;
<c:Identifier>urn:uuid:3b6a325b-a4e1-478a-92a7-108dd3f94adb</c:Identifier>
</c:SecurityContextToken>
<c:DerivedKeyToken u:Id="uuid-169b0950-217e-48af-9057-ea832e0c7e19-9" xmlns:c="http://schemas.xmlsoap.org/ws/2005/02/sc" xmlns:u="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"&gt;
<o:SecurityTokenReference>
<o:Reference ValueType="http://schemas.xmlsoap.org/ws/2005/02/sc/sct" URI="#uuid-95cdaf11-3974-4cc0-93a8-a3d2191bbef4-5"></o:Reference>
</o:SecurityTokenReference>
<c:Offset>0</c:Offset>
<c:Length>24</c:Length>
<c:Nonce>
<!-- Removed-->
</c:Nonce>
</c:DerivedKeyToken>
<c:DerivedKeyToken u:Id="uuid-169b0950-217e-48af-9057-ea832e0c7e19-10" xmlns:c="http://schemas.xmlsoap.org/ws/2005/02/sc" xmlns:u="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"&gt;
<o:SecurityTokenReference>
<o:Reference ValueType="http://schemas.xmlsoap.org/ws/2005/02/sc/sct" URI="#uuid-95cdaf11-3974-4cc0-93a8-a3d2191bbef4-5"></o:Reference>
</o:SecurityTokenReference>
<c:Nonce>
<!-- Removed-->
</c:Nonce>
</c:DerivedKeyToken>
<e:ReferenceList xmlns:e="http://www.w3.org/2001/04/xmlenc#"&gt;
<e:DataReference URI="#_1"></e:DataReference>
<e:DataReference URI="#_6"></e:DataReference>
</e:ReferenceList>
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#"&gt;
<SignedInfo>
<CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"&gt;&lt;/CanonicalizationMethod&gt;
<SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#hmac-sha1"&gt;&lt;/SignatureMethod&gt;
<Reference URI="#_0">
<Transforms>
<Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"&gt;&lt;/Transform&gt;
</Transforms>
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"&gt;&lt;/DigestMethod&gt;
<DigestValue>NnVRkY+ZVgWd4qfBs3jtjxAf9m4=</DigestValue>
</Reference>
<Reference URI="#_2">
<Transforms>
<Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"&gt;&lt;/Transform&gt;
</Transforms>
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"&gt;&lt;/DigestMethod&gt;
<DigestValue>+DXYZ0w5aRfe1m+owuJXfYnT4TU=</DigestValue>
</Reference>
<Reference URI="#_3">
<Transforms>
<Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"&gt;&lt;/Transform&gt;
</Transforms>
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"&gt;&lt;/DigestMethod&gt;
<DigestValue>OCiMrL9/sZLY3qMANeBgpmmPTHQ=</DigestValue>
</Reference>
<Reference URI="#_4">
<Transforms>
<Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"&gt;&lt;/Transform&gt;
</Transforms>
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"&gt;&lt;/DigestMethod&gt;
<DigestValue>l6mMmQ2LE9VFtjaA6Qc4GKBXURw=</DigestValue>
</Reference>
<Reference URI="#_5">
<Transforms>
<Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"&gt;&lt;/Transform&gt;
</Transforms>
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"&gt;&lt;/DigestMethod&gt;
<DigestValue>gwaCnZv9JZtGrNhF6q8l2qIptMU=</DigestValue>
</Reference>
<Reference URI="#uuid-169b0950-217e-48af-9057-ea832e0c7e19-14">
<Transforms>
<Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"&gt;&lt;/Transform&gt;
</Transforms>
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"&gt;&lt;/DigestMethod&gt;
<DigestValue>i6m9Hb2aKQPRshhSqEpESJJASQg=</DigestValue>
</Reference>
</SignedInfo>
<SignatureValue>lo3sUvYlRiCCfag3kesKx9LFpHU=</SignatureValue>
<KeyInfo>
<o:SecurityTokenReference xmlns:o="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"&gt;
<o:Reference ValueType="http://schemas.xmlsoap.org/ws/2005/02/sc/dk" URI="#uuid-169b0950-217e-48af-9057-ea832e0c7e19-9"></o:Reference>
</o:SecurityTokenReference>
</KeyInfo>
</Signature>
</o:Security>
</s:Header>
<s:Body u:Id="_0" xmlns:u="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"&gt;
<GetTest xmlns="http://tempuri.org/"&gt;&lt;/GetTest&gt;
</s:Body>
</s:Envelope>

Answer 1

Nobody ever claimed using wsHttpBinding was a great idea! ;-)

wsHttpBinding implements a whole slew of those WS-* standards - and they don't come cheap!

Typically, if you're behind a corporate firewall, I'd recommend using netTcp. Most of the time, when you're dealing with internet facing public services, you'll be better off with basicHttpBinding or webHttpBinding (REST).

You can tweak wsHttpBinding, of course - turn off sessions, turn off security features etc.

But in the end, you really have to ask yourself: is the effort to create such a login scheme, managing lifetime of these "session GUIDs", and all the various ways this can go wrong (GUID expires to soon, GUID gets spoofed etc.) really worth it? Yes, of course - the message is a few kb in size - but does it really matter? Seriously?

Don't go optimizing in the wrong place - with today's technologies in place, many of these "gut-feeling optimizations" are really not worth the trouble and the development effort to "optimize" away those few kb on each call might be massively higher than any performance penalty from transmitting a few kb back and forth.

Think about it !

Marc