WS-Security overhead when using message security
Following is a message logged with Microsoft Trace Viewer. I believe it represents a single call to a parameterless method that has an integer return value in 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'm puzzled by the amount of overhead in the title. Has anyone seen this before? I'm not even sure if I'm looking at this correctly. I had planned to use this on every call, and I was hoping that the overhead would be reduced on subsequent method calls on the same service, but that doesn't seem to be the case.
I am tempted to create a single method Login()
over SSL instead that authenticates the user and returns a GUID to be passed to authenticate subsequent requests, with an expiration policy for each GUID, etc. Intuitively, I think it might be bad, but I'm a safety dummy so I'm not sure.
Any guidance is appreciated.
<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope">
<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">http://tempuri.org/IWsAppointmentService/GetTest</a:Action>
<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">urn:uuid:d83df40a-979b-440c-9292-7a5a84a64ecd</a:MessageID>
<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">
<a:Address>http://www.w3.org/2005/08/addressing/anonymous</a:Address>
</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">http://localhost:8731/service/ws</a:To>
<o:Security s:mustUnderstand="1" xmlns:o="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
<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">
<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">
<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">
<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">
<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#">
<e:DataReference URI="#_1"></e:DataReference>
<e:DataReference URI="#_6"></e:DataReference>
</e:ReferenceList>
<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/2000/09/xmldsig#hmac-sha1"></SignatureMethod>
<Reference URI="#_0">
<Transforms>
<Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"></Transform>
</Transforms>
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"></DigestMethod>
<DigestValue>NnVRkY+ZVgWd4qfBs3jtjxAf9m4=</DigestValue>
</Reference>
<Reference URI="#_2">
<Transforms>
<Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"></Transform>
</Transforms>
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"></DigestMethod>
<DigestValue>+DXYZ0w5aRfe1m+owuJXfYnT4TU=</DigestValue>
</Reference>
<Reference URI="#_3">
<Transforms>
<Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"></Transform>
</Transforms>
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"></DigestMethod>
<DigestValue>OCiMrL9/sZLY3qMANeBgpmmPTHQ=</DigestValue>
</Reference>
<Reference URI="#_4">
<Transforms>
<Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"></Transform>
</Transforms>
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"></DigestMethod>
<DigestValue>l6mMmQ2LE9VFtjaA6Qc4GKBXURw=</DigestValue>
</Reference>
<Reference URI="#_5">
<Transforms>
<Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"></Transform>
</Transforms>
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"></DigestMethod>
<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#"></Transform>
</Transforms>
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"></DigestMethod>
<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">
<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">
<GetTest xmlns="http://tempuri.org/"></GetTest>
</s:Body>
</s:Envelope>
source to share
No one has ever argued that using wsHttpBinding is a great idea! ;-)
wsHttpBinding implements a number of these WS- * standards - and they don't come cheap!
Generally, if you are behind a corporate firewall, I would recommend using netTcp. Most of the time, when you are faced with internet access to public services, you would be better off with basicHttpBinding or webHttpBinding (REST).
You can tweak wsHttpBinding of course - disable sessions, disable security features, etc.
But at the end of the day, you really have to ask yourself: is this an attempt to create such a login scheme by managing the lifetime of these "GUIDs" and in all different ways it can go wrong (GUID will expire soon, GUID gets fake, etc.) etc.) is really worth it? Yes, of course - the message is several kb in size, but is it valid ? Jokes aside?
Don't jump to optimizations in the wrong place - with today's technology, many of these "gut optimizations" really aren't worth the hassle, and the effort to "optimize" those few kilobytes on each call can be well above any performance penalty for transferring a few kilobytes back and forward.
Think about it!
Mark
source to share