XML Security and Web Services Security - the same thing?
It's common to see the terms "XML Security" and "Web Services Security" used interchangably. So it's reasonable to ask - Are they the same thing? The answer is no.
XML Security refers to the security of XML documents themselves. Specifications such as XML Signature and XML Encryption come under the heading of "XML Security". XML Signature is used for the integrity of an XML document, or portion thereof. XML Encryption is used for the confidentiality of an XML document, or portion thereof. In addition, the XML Security umbrella covers defense against threats such as DTD entity-expansion and XML parser clogging attacks. Finally, "XML Security" includes the "XML-ization" of security tokens - such as licenses (XRML) or assertions (SAML) [but not digital certificates which still remain in ASN.1-land].
When XML is sent from A to B (and on to C and D etc.) it adds a new dimension to XML Security. In the tutorials I give on XML and Web Services Security, I start with an intro to XML and then I talk about XML Security. Often, when I show an XML Security example such as an XML Signature or XML Encryption, I am asked questions about the "XML Message" on the screen - what if it is replayed? where is the timestamp? how can we be sure that that certificate is trusted? Where does that XRML license come from? how do I know who sent this XML message? When that phrase "XML Message", as opposed to "XML Document", is used, we've moved on from "XML Security" and we are into "Web Services Security" territory.
Web Services Security standards and specifications, such as the recently-ratified WSS from OASIS, address the security questions which arise when XML messages are sent - such as timestamping and message-based authentication. Part of this task involves describing how XML Security applies to SOAP messages. The wider Web Services Security roadmap from IBM and Microsoft describes how XML security tokens are passed around, exchanged for tokes of a different type, and used as input to access control decisions. The Liberty Alliance framework describes how Web Services Security maps to individual identity, without compromising privacy and anonymity. Many higher-level Web Services Security specifications address problems which go well beyond XML Security - into the realm of identity and trust. Finally, "Web Services Security" also encompasses the application of Web Services to some of infosec's more knotty interoperability problems: PKI (XKMS) and RBAC (XACML) spring to mind.
So, where are the practical implications of the difference between "XML Security" and "Web Services Security". To use an analogy; applying XML Security to XML documents is like installing an X-Ray screener at company headquarters and then passing each received courier and mail package through it. You can find out if the package includes anything threatening, if it doesn't look like it should, or if it's been tampered with. This is what XML Firewalls do - they do Schema validation, they block application-layer attacks such as SQL Injection, and they detect invalid XML that's designed to clog a parser. They raise alerts if anything suspicious is found in the XML documents. You might think "Isn't that enough?". However, let's take the analogy further. What if one of the packages received at the company headquarters is a courier package containing an invoice. You look at the invoice, and you see that it's appropriately formatted [Schema Validation], is sent to a valid recipient [the Accounting Department], doesn't contain any outragous values [content-validation] or have any extra attached pages [SOAP Attachments] which shouldn't be present. Does that mean you automatically enter the invoice into your accounting system? Of course not. You must trust the originator of the invoice. This is where identity and trust come into play. The security of the document itself is only part of the picture. The entire security context (sender, recipient, security token validity, authorization against company policy stores) goes beyond the document itself. This is also how Web Services Security goes beyond XML Security.
Or to put it another way: A document which passes XML Security checks (validity, integrity, scanning for XML-level threats) may still fail Web Service Security checks because it is not from a trusted originator. And remember, the originator is not necessarily the same as the entity which passed you the message.
One of the great ironies of Web Services Security is that an organization often has more to fear from valid XML documents than from an invalid XML documents, because the valid XML documents will successfully run the target Web Services.
The X-Ray scanner is not a perfect example, because many organizations do not have such a natural "Gateway" into their XML networks, and in any case, experience has shown that many attacks originate internally. This is why the firewall analogy applies for XML security, but breaks down for Web Services Security. Of course you need both XML Security and Web Services Security if you're transacting XML. The only exception is if you're exposing a public Web Service with no authentication and authorization - in that case you can argue that you only strictly need XML Security. But if you care about who is running your Web Services, you need more than just XML Security at the perimeter.
|
|
