Columns

Securing XML

New standards tackle XML document security, furthering its enterprise possibilities.

• By Laura Wonnacott
• 10/01/2002

XML is on a roll, and with good reason: The incremental complexity it introduces in the form of parsers, bandwidth consumption, and developers' learning curves has been more than offset by gains in compatibility both between disparate programs and environments, and between different versions of the same program.

With XML's adoption accelerating at a geometric rate, security in and for XML documents is getting quite a bit of attention. The extent to which XML needs security, and the mechanism for providing it, is still a subject of debate and development.

Security Issues
There are a few key reasons why XML needs security. The first is the increasing use of XML in automated systems. Emerging Web services technologies all use XML as the underlying structure for transmitted data. To use Web services for mission- critical applications, the data they process and return must be trustworthy. The possibility that a malformed request or response could propagate across multiple Web services providers means requests and responses must be validated.

Another reason for XML security is the sheer convenience of having a single, canonical copy of any important information. Today, if someone can read an XML document, they can read the document in its entirety. This needlessly limits the usefulness of XML.

For example, if a company wanted to send out XML documentation of weekly personnel changes, much of the information would be useful to everyone (name, e-mail address, etc.). Salary information should only go to accounting, while personal information should only go to HR. In today's XML world, XSLT would probably be used to convert the single complete document into multiple, less-complete documents. This needless extra step creates a greater margin for error, either by corruption of the data itself or through versioning problems.

Standards in Sight
XMLEnc and XACML/SAML may solve the problem. As usual, there's a tradeoff between complexity and functionality; XMLEnc is simple and elegant, while the XACML/SAML approach is significantly more complex but probably offers greater flexibility.

XMLEnc is a clever approach. It works by encrypting parts of the actual XML document. However, it's more powerful than that sounds. Because different regions can be encrypted with different keys, a single XML document will yield different content to different users or systems, depending on which decryption key(s) they have.

In the previous example, a single document could be prepared with all of the information, and each department's personnel or automated systems would be able to read only the public data, along with any encrypted data for which they had the key. All the encrypted data is still there, so cryptography breakthroughs or leaks of keys could compromise the encrypted data.

XACML and SAML are complementary technologies. XACML is a schema for defining permissions on XML documents. The neat thing here is that, much like file system access lists we're all used to, XACML allows read and/or write permissions to be defined on a per-user or per-document basis. As such, it's quite a bit more flexible than XMLEnc: individual user permissions can be modified and write access is supported.

The SAML schema defines requests and responses whereby an application can inquire about access to an XML document or node. SAML requests are relayed using SOAP over HTTP to a system that evaluates the request and returns an appropriate response. In this system, tags are embedded in the original XML document to instruct parsers about where to send SAML requests.

The downside to XACML/SAML is its approach is only useful in a situation where the XML is hosted remotely. If a user had access to the raw XML file in its entirety, the security provisions would be useless. That's probably not a huge concern for most complex applications, but it does make the specification less useful for lower-end applications (like e-mailing an XML file). In that case, XMLEnc is the only real choice.

Both XMLEnc and XACML/ SAML probably have a place. XMLEnc is valuable because standalone XML files can benefit from it, while XACML/SAML allows for greater granularity of control—and read/write access. My guess is that they will both survive, and will be used in different situations.

Other Initiatives Underway
Those are the two main approaches being developed to allow for confidentiality—for XML documents. The field of security is much broader than that, and there are other initiatives underway in other areas. Most notably, the triumvirate of XML-Sig, XML-KISS and XML-KRSS, which use public key encryption to ensure that XML documents aren't tampered with.

XML-Sig and XMKS are complimentary to XMLEnc; they allow for a standalone file to offer some security features. Unlike XMLEnc, which aims to restrict access to some nodes, XML-Sig and XMKS serve to ensure that the file is cryptographically signed (that is, it hasn't been modified from the original).

The XML security debate continues today, and will go on for some time. It's very likely that more than a single protocol will prevail.