RSA strives to keep Web services safe |
 |
By Eric B. Parizo, News Editor
09 Oct 2002 | SearchWebServices.com |
|
|
It's no secret that security worries are preventing companies from developing outside-the-firewall Web services; it's too easy to tamper with XML messages. While standards bodies mull over the problem, RSA Security Inc. of Bedford, Mass., has released a new software development kit (SDK) intended to help C programmers secure Web services messages utilizing a standard already adopted by the World Wide Web Consortium (W3C). RSA's senior product manager, Kathy Kriese, explained to SearchWebServices.com how her company's new product works and why XML digital signatures keep Web services safe.
You've got a new SDK for adding digital signatures to XML Web services messages called SecurXML-C. Who is it for and what does it do?
Kriese: It's a product for C developers. Web services have traditionally been a very much Java-focused arena. We already have a product that's available for Java developers that's been shipping for a year. There's nothing wrong with Java, but there are a bunch of programmers that are developing in the C languages and they don't have any tools for doing digital signature work.
If you had to describe the ideal user for your products, who would that user be?
Kriese: It would be a C developer that's interested in adding security functionality to their XML Web services. It seems like XML is being used most frequently internally -- within organizations -- and not as much between companies, and one reason we've heard that folks aren't going externally is because security is a concern. They want to make sure info isn't changed when it's going over the Internet.
How would a developer use your SDK?
Kriese: A developer would call into the API of our SecurXML-C product from their software application, and be able to access whatever the function is from a library. So say someone has a purchasing application. If they wanted to send a purchasing requisition from one party to another, they could use our software to have a "click here to sign" section in their application. The user would click, have a digital signature generated with that XML purchase requisition message, and it would get sent to another person at another company. [The recipient] could then use a "click to verify" feature and verify that it's a requisition from the person they expected to receive one from and nothing was changed over that Internet transmission.
To play devil's advocate, why would a developer need a new SDK to develop this functionality?
Kriese: We have lots of expertise to draw upon. It's not to say developers couldn't invent a product similar to this themselves, but if they don't have the background in securing XML, which a lot of developers don't have, it's doing to take them a long time to do it. So rather than have them spend all their time on security development, they can add features to their own products that will differentiate them and essentially outsource their security functionality to us. Unfortunately, there're a lot of security flaws out there because people don't implement security correctly. Using our product is one way to avoid those problems.
On a scale of 1 to 10, how secure do you think Web services are today?
Kriese: If you're using digital signatures, you do have some level of security. I'd be more comfortable when XML encryption is available. It's a pretty basic thing to have that privacy in a message, and XML encryption standards will definitely add that. So we're probably at a "3" right now with just the XML digital signature standard.
The WS-I is pushing its WS-Security spec as the de facto way to add security tags to SOAP headers. Does your product use WS-Security, or do you use your own or a different spec?
Kriese: The SecurXML-C product is based on the W3C standard, RFC3275, for XML digital signatures. We are also following other standards in the XML arena to see how they migrate through the standards bodies. Right now, this is just dealing with XML digital signatures so it doesn't relate directly to WS-Security at the moment.
Does that mean anyone using a Web service that incorporates your product must also be compliant with the RFC3275 standard?
Kriese: People would have to follow the W3C standard to get a document and be able to verify it, which is one of the advantages of standards. XML is flexible, but it can lead to problems if people aren't aware of each other's formatting.
For developers who haven't done it before, how difficult is it to build a secure Web service?
Kriese: Our development cycle (for SecurXML-C) was almost a year. It was a challenge for our development staff to work on this product because it is for the C development languages and because Web services are so focused on Java, there aren't a lot of tools for developers to use to create products and check their work. So we had to build a lot of things ourselves, not just the product but also the testing structure. Given how long it's taken here with people who do understand XML and security, I would think it would take at least that long if someone's not familiar with XML or security.
How long would it take developers who are experienced with XML and security?
Kriese: It should only be a couple of days. Developers are real familiar with SDKs and calling into APIs, and that's not anything different that what they've done before. We've tried to keep it as standardized as possible, so it wouldn't be an involved project by any means.
Pricing for SecurXML-C varies based on several factors, including number of licenses purchased and royalty scenarios.
FOR MORE INFORMATION:
CLICK for a Tech Tip on using digital signatures with care
CLICK for an exclusive from Preston Gralla on XML Signature
CLICK for more articles by News Editor Eric B. Parizo
|
|
|
|
