When should I use WS-Security? What about SSL?
WS-Security is a standard ratified by OASIS (Organization for the Advancement of Structured Information Standards) to provide an interoperability framework for performing security functions through SOAP. WS-Security is used to guarantee confidentiality and integrity to SOAP messages using XML Encryption and XML Signature, and it provides a common mechanism for describing credentials so that a wide range of authentication mechanisms can be used (Kerberos, X.509, standard usernames and passwords).
Secure Sockets Layer
) is a protocol on top of HTTP that provides confidentiality, integrity and standardized credential (sound familiar?) using encryption, digital signatures (MACs or Message Access Codes) and digital certificates. Web sites that begin with https:// rather than http:// use SSL to secure the traffic and verify authenticity.
Given the overlapping nature of SSL and WS-Security, why is one a better choice?
There are two main problems with SSL that drove the development of WS-Security:
- SSL uses HTTP. Web Services not using HTTP cannot use SSL.
- SSL is point-to-point. It is not granular and messages must be decrypted at any intermediate waypoint.
So, if either of these issues impacts your architecture, use WS-Security. Otherwise, SSL is an option. SSL benefits include being easily configurable and mature. It isn't unsafe to use, just inflexible and inadaptable to larger, more complex security architectures. If you need to verify that only certain users can access a service, or that messages aren't being read or modified in transit, and you need a granular, interoperable way to do so, you should use WS-Security for your Web services.
Dig Deeper on Topics Archive