XML Digital Signatures in Mustang

By Allen Hollub

May 15, 2005 —

This column continues my look at the new features slated for the Java 6 (“Mustang”) release.

The dark underbelly of XML on the Web has always been security, a topic about which most programmers are woefully ignorant. Too often, programmers assume that a firewall will solve all their security problems. Unfortunately, they also look at the firewall as a nuisance, and they’ve worked diligently to make firewalls completely ineffective. (I blame ignorant IT departments who refuse to open up legitimate “holes” in the firewall for this state of affairs.) Vast quantities of network traffic that has nothing to do with serving Web pages now funnel through port 80. It’s as if the firewall isn’t even there.

Returning to XML, an XML-based Web service is really a way to circumvent the firewall by allowing someone from outside to execute code inside your app server via port 80. Once a hacker is in the app server, he or she can wreak havoc. The real vulnerability in most systems is in the code itself, not the means of getting to the code. Hackers exploit bugs.

Though there have been lots of XML security standards in the works, none of them has been sufficiently solid to be put into common use. Since nobody has been rolling his or her own security solutions, Web services have been very vulnerable to attack. The situation is compounded by tools that make XML/SOAP “easy” by automatically generating all the insecure wrapper code that you need to penetrate the firewall. None of this machine-generated code could know about a roll-your-own security system, for example.

To make XML transactions really secure, you need to deal with several aspects of the security equation. The three big ones are confidentiality (encryption), authentication (of both the end user and the server) and access control. All three are complicated by the fact that the Web service may be distributed, and not all parts of the service may be under your control. (For example, you may be using a third-party credit-card processing service.)

JSR 105 (XML Digital Signature API), slated for inclusion in Java 6, handles the authentication part of the equation. (Download the proposed final draft from jcp.org/en/jsr/detail?id=105). In particular, JSR 105 allows the requester of an XML service to “sign” the request, thereby guaranteeing that the request comes from a trusted source. The server could simply refuse to execute the service if the requester isn’t trusted, for example. Similarly, the reply can be signed by the server, so that the requester can know that it’s a legitimate response to the request.

The proposed spec has most of the strengths and weaknesses of the existing crypto classes. On the plus side, the new APIs integrate well with the existing Java Cryptography Architecture (JCA) in that they’re built around an easily managed “Provider” architecture. It’s easy to plug new versions of the code that actually does the work into your system.

There’s a lot on the minus side, though. First, the APIs are built around the DOM APIs, so you’ll have to manufacture a DOM from externally provided XML in order to sign anything. Next, the APIs are too complicated. There are many more steps than are required by the existing digital-signature APIs, and these steps will be very confusing to someone who doesn’t know the Java crypto APIs cold (i.e., most programmers who use XML transport). The documentation is also, as usual, inadequate. There are, at least, a few examples, but there’s precious little discussion of the APIs at the architectural level.

The biggest problem with JSR 105 is that it’s just too low-level—a weakness acknowledged in the JSR itself. In order to be really useful, the digital signing and verification process should be completely transparent. Ideally, you will make a Java call to a Web service and the signing would be a side effect of the call. On the receiving end, an exception should be thrown if the initiator of the request isn’t authorized to make the request. All of the APIs in JSR 105 should be completely hidden.

The other main omission is integration to an authentication system. Simply verifying that a request is signed is insufficient if you cannot also verify that the request came from a trusted sender. To do that, you need to integrate the verification process with some sort of authentication system. At minimum, I’d like to know that a valid certificate for the signing entity exists in a trusted key store on the receiving server.

So, the JSR 105 APIs give you the wherewithal to do the real work, but they are so complicated that I doubt that they will get used, and none of the real infrastructure required to validate an XML request is currently supported (or even imagined). It’s a start, but doesn’t go nearly far enough.

Allen Holub is an architect, consultant and instructor in C/C++, Java and OO Design. Reach him at www.holub.com.

Share this link: http://www.sdtimes.com/link/28605

Altova upgrades MissionKit to handle large XML files With 64-bit versions of its tools, the upgraded suite is able to handle much larger files, the company says

Efficient XML Interchange gets W3C green light Specification that saves bandwidth is now a candidate recommendation

InterSystems adds binary XML messaging to Ensemble SOAP messages in Ensemble will be smaller thanks to this format change, according to the company. The update also throws in WS-Security 1.1 for transactions and support for more integration protocols.

Add comment

Name*
Email*
Country

Comment
Preview

News on Monday
more>>
SharePoint Tech Report
more>>

Download Current Issue
ISSUE 3/15/2010 PDF

Need Back Issues?
DOWNLOAD HERE

Receive the print Edition?

Google Code turns 5
Google Code Turns 5, and adds a Paxos Algorithm to make the system more stable and reliable.
03/17/2010 11:16 AM EST

Test your Visual Studio 2010 know-how
Microsoft is offering free beta certification exams for Visual Studio 2010.
03/17/2010 11:08 AM EST

Microsoft lifts the hood on IE9
Microsoft is previewing IE9.
03/16/2010 01:10 PM EST