|
Security is a very large subject. I could easily write a book on this topic, but I'll try to be brief. I recommend that you read the Web services security white papers produced by IBM, Microsoft, and Verisign. See http://www.verisign.com/wss.
From a technical point of view, SOAP poses pretty much the same type of security issues as most distributed computing technologies, such as CORBA, RMI, or MOM. (DCOM poses much higher security risks caused by the insecurity issues associated with dynamic invocation through the COM registry, but I won't go there.) The point is, if you are going to expose business process functionality through an open, public API, you ought to make sure that you perform the appropriate authentication and authorization tests before you
allow the request to proceed. The question is, do SOAP developers implement the necessary security routines in their applications.
Consider these points:
- A SOAP service provides an API to business functionality
- SOAP is simple enough for almost any programmer to use
- A lot of programmers don't know how to build adequate security
routines
- Most SOAP services are accessible through HTTP on port 80
- Most firewalls don't block communications on port 80
I see a lot of potential for security breaches that you just wouldn't have to deal with when working with CORBA or MOM.
A lot of people are under the false assumption that you can secure SOAP simply by sending your messages using HTTPS and SSL. SSL encrypts the SOAP messages while they travel on the wire. But sometimes you need to route the message between multiple intermediaries, and you don't want (1) to have to decrypt and encrypt the message for each intermediary and (2) the intermediary to be able to see the confidential information in the message.
And, by the way, SSL doesn't help you accomplish authentication and
authorization.
To properly secure SOAP, you need to implement your security at the application level rather than at the transport level. It's not hard to add security to SOAP. You can pass authentication information in a SOAP header, and you can intercept each call before processing to perform authorization tests. (You should be able to set this up in your SOAP server to perform automatically so that the developer doesn't need to write any extra code.)
But if you want to ensure interoperability, you need to define standards for how you represent authentication credentials. Unfortunately, we haven't defined SOAP security standards yet. (The new OASIS Web Services Security (WSS) technical committee (see https://www.oasis-open.org/committees/wss/) will define these standards -- the first meeting will be in September 2002.)
There are a few other challenges, which I'll name, but I won't go into here:
- Cross-domain security and credential mapping
- Partial encryption of SOAP messages
- Relaying encryption key information
The first point is a policy problem, not a technical problem. WSS will address the last two points.
Many (not all) SOAP implementations support some type of authentication mechanism, but not every implementation supports the same type of authentication. Very few SOAP implementations support authorization. Systinet WASP is the only SOAP implementation that currently provides a comprehensive, automatic, built-in security framework. IBM's WSTK provides a bunch of excellent security features. AmberPoint Management Foundation and VordelSecure provide add-on security facilities for a number of SOAP implementations.
|
