SSL is meant for communicating between endpoints. In other words, it protects the confidentiality and integrity of messages between a client and a server communicating over the Internet. It does this by providing an encrypted tunnel, good only for a single session. This is ideal for protecting access from a browser to a Web site and back.
But Web services are transparent to the user and involve applications talking to each other behind the scenes. In addition, unlike a Web transaction, which lasts for a session and is gone, in Web services, these applications are talking continuously to each other. The exchange of keys and certificates for creating a single-use session key for SSL make it impractical for Web services. Also, SSL doesn't manage the access control required for Web services.
In summary, SSL works fine at the transport level, but not for message-level security.
Fortunately, there are a number of XML-based security options available for Web services. These offerings manage the encryption, access control, authentication and data integrity and privacy required for Web services. These product areas include XML encryption, XML digital signatures, XML Key Management Specification (XKMS), Security Assertion Markup Language (SAML), Web Services Security (WS-Security) and the ebXML message service.
In your situation, SAML and digital certificates could be used to secure your Web services implementation. But that doesn't mean SSL can't be used at all for securing Web services. The decision to stick with SSL or use a stronger XML-based method should be based on the size and scope of your application. If the Web services are used for a generic online Web application, then go with SSL. But if it involves complex workflows with Web services moving documents that need to be secured, then SSL won't do and the stronger XML solutions are in order.
For more information:
This was first published in February 2008