LOGIN | REGISTER NOW | SUBSCRIBE
 
 
News on Monday
more>>
SharePoint Tech Report
more>>


   

 
 
Download Current Issue
ISSUE 7/1/2009 PDF

Need Back Issues?
DOWNLOAD HERE

Receive the print Edition?


 
Is the mystery Borland suitor Serena?
Borland software is considering an offer from another company after a preliminary deal with MicroFocus. Is Serena the new company?
06/30/2009 01:55 PM EST

Windows 7 - An eBayer's dream product?
Windows 7 pre-orders can make people money on eBay.
06/29/2009 03:48 PM EST

Know thine cloud provider
Cloud computing require companies to understand compliance and regulation. Third parties will play a big role in regulated industries.
06/29/2009 02:58 PM EST

 

Microsoft Worldwide Partner Conf.
7/13/2009 to 7/16/2009
New Orleans
Microsoft

OSCON (Open Source Convention)
7/20/2009 to 7/24/2009
San Jose
O'Reilly Media

XBRL Technology Workshop & Summit
7/28/2009 to 7/30/2009
Santa Clara
XBRL US

ACM SIGGRAPH
8/3/2009 to 8/7/2009
New Orleans
ACM SIGGRAPH

OpenSource World (formerly LinuxWorld)
8/12/2009 to 8/13/2009
San Francisco
IDG World Expo


 
print Printable version 
Most Read Latest News Blog Resources
Kapow automates website data retrieval
Kapow Technology's Web Data Server 7.0 can be used to create modules that navigate through...

COBOL’s future lies in the clouds
After 50 years of use in businesses, COBOL is still lingering around mainframes. But the s...

Oracle's Fusion 11g lays groundwork for ERP platform
Fusion's components are standards-based and integrated, but some abilities are lost if non...

Digg!  Digg
Reddit  Reddit
Slashdot  Slashdot
Share on facebook  Facebook
Share on Twitter  Twitter

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
 

Add comment


Name*
Email*  
Country     


  • Comment
  • Preview
Loading