The article explains who to check an XML Signature which has been generated on the client side by Microsoft .NET.
What is good about the article is what is doesn't say. It does say that you can use XML Signature verification in order to test the integrity of incoming XML messages (i.e. check that they haven't been changed) and also to check that the signer was trusted. It does not say that you can use XML Signature checking to authenticate the client. Remember yesterday's post on replay attacks in Web Services. If you are only checking the XML Signature of incoming messages and deciding "if it's signed by a trusted client, we let it in", then an attacker could get a hold of a signed message and replay it. That is why, if you want to use XML Signature as part of an authentication system, you must include something which changes per message (like a timestamp or nonce) and then sign that also. You can't just sign the SOAP Body if you want to use XML Signature in an authentication context. This is well known and is in the WS-I Basic Security Profile document. But still, it's common to run into situations where a naive developer may think "I will authenticate clients to my Web Service by validating an XML Signature over the SOAP Body" [i.e. "I will perform some complex CPU intensive processing on every single incoming message, before I know if I should trust it or not"].
If you also include a Timestamp and sign it (as the Microsoft .NET WSE and WCF toolkits do), then at the XML Gateway side you can use a Filter, such as the filter shown below, to validate the Timestamp. This is shown in the Policy Studio for making policies to govern Web Services usage.
So remember, XML Signature used on its own is for integrity checking. If you want to use it for client authentication, you need to consider replay attacks and you need to implement a policy in line with the WS-I BSP guidelines (including a nonce or timestamp, signing these, etc).
0 comments:
Post a Comment