|
|
||||||||||||||||||||
| Home > SOA News > The pros and cons of securing Web services with SSL | |
| SOA News: |
|
||
Pankaj Kumar has an eye for security. With more than 14 years of software development experience to his credit, the Hewlett-Packard Co. technical architect is now developing Web services-based technology for HP's OpenView platform. Kumar has been involved with the Java Specification Requests standards JAX-RPC and JSR-109 and is author of J2EE Security for Servlets, EJB and Web Services. In an e-mail interview with SearchWebServices.com, Kumar talked about the strengths and weaknesses of Secure Sockets Layer and the emerging role of this popular protocol in securing Web services. Where is SSL finding traction in securing Web services?
SSL is great for securing the transport pipe. It has been around for quite some time, most people understand it and the interoperability among various implementations have improved significantly. And although it is not as easy as direct HTTP interactions, moving from HTTP to HTTP over SSL or HTTPS requires, in most cases, simple deployment time configuration changes only, avoiding costly redesign or source-code level changes. Given the array of security areas that get addressed by SSL, privacy, integrity and authentication of end points, use of SSL is indeed very attractive. For category (a) Web services, the security needs are minimal to start with and are usually satisfied with moving the transport from simple HTTP to HTTPS. Same for most of the category (b) uses. Category (c) is interesting. Most of the publicly available Web APIs in this category don't support even SSL (though, they can without much change). I suspect that most of these are still at experimental stage and the need for security hasn't been very strong. Category (d) is an entirely different story. Applications conforming to standards such as ebXML are more demanding and would require message-level security support. Is SSL suitable for B2B Web service transactions between suppliers or partners, or is it solely a B2C proposition? But because the message-level security technologies -- such as XML DSig, XML Encryption, WS-Security and many others -- tend to be complex to deploy and hence are yet to get wide adoption, there is a tendency to use SSL as a starting point. What kinds of hacker attacks is SSL well suited to hold off? Which would it fail against? If the application requires the data to be stored on disk before processing, then SSL can't protect against attacks on that data. This could be a significant consideration for certain Web services-based applications. However, there are a number of attacks against which SSL -- or for that matter, any technology -- is going to be ineffective. These include attacks based on software vulnerabilities that allow a hacker to take control of the machine. Similarly, it is hard to fend off against social engineering-based attacks. Can SSL be used alone with Web services, or are digital signatures or some other secure authentication method required?
On the other hand, if you have a workflow solution that uses Web services to move around documents, and you need document-centric security, then you should be thinking about XML digital signatures and XML encryption. Is SSL too bandwidth- or CPU-intensive for Web services? Do the benefits justify the expense? Not many people realize that SSL allows negotiation of the key size for encryption and the cryptographic algorithms at runtime. So you can actually adjust the security level, and hence the computing power needs, to meet your application demands. The increase in message size due to SSL is not very significant, and is rarely a concern. Does SSL scale well enough for Web services transactions? Are there any emerging XML security technologies that can address Web services security requirements that are not provided by SSL? However, most of these standards are new, and it will be while before they get widely deployed. How would an organization address the fact that SSL often lacks authentication for Web services? Well, if you use mutual-authentication feature of the SSL, then you do get client authentication. However, client-side authentication through SSL is not widely used due to the difficulty in managing client certificates. Some people address this by using HTTP-Basic or a token embedded in the XML message and then transmitting the message over HTTPS. This is great because SSL makes sure that sensitive information, such as account identification and password, is not transmitted in clear text over the Internet.
'); // -->
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| About Us | Contact Us | For Advertisers | For Business Partners | Site Index | RSS |
|
|
|
|||||||