from WS-I for WS-RM plus security. In addition, there are requirements for Web Services Atomic Transaction (WS-AtomicTransaction, WS-AT) plus security and MTOM plus security, etc. Many vendors
provide out of the box security solution that supports many standards on Web Services security, and also supports security with other standards together, including WS-RM plus Security and MTOM plus security. All these
security features are driven by the policy, including the standard of WS-Policy and WS-SecurityPolicy.
However, from the security architecture point of view, having support for multiple Web Services
security standards is not equal to have a secure implementation on SOA/Web Services. How to use those WS-* security standards all together on deployment that meets individual system's requirements and yet provide
secured solution will be a big challenge.
KISS – Keep It Simple and Secure
Many people think Web Services security is too heavy to use and keep it simple will be more secure. In many
cases, the users want to do just a portion of the WS-Security, and not other required protections. They think keeping it simple will be better.
For example, many uses just want to send the Web Services
message with Username Token Profile for authentication only. They just want to keep it simple, and don't want to add other message protection features into the Web Services request message. In fact, the Username Token
Profile will put the user's password in pain text format and send it across the network. Any one will see the password in clear text. This kind of misuse of WS-Security will introduce security vulnerability
The truth is: we want to keep it simple, but more important is that we want to keep it secure. The KISS principle here is "Keep in simple and secure", instead of "keep in simple but not secure."
It is very secure when Web Services security is adopted?
Many people think the Web Service security is too complicated for hacker to hack into. Once the standard based Web Services security is adopted
and deployed, the application will be very secure. We don't need to worry the security issue any more.
The truth is that using WS-Security alone will not make your application completely safe. Just like
all other security solutions, the hacker is looking into the weakest link in the whole defense line. Also, standards in WS-Security are more focus on interoperability, instead of preventing hacker attacks. Using
standard based solution on Web Service security alone, will not guarantee the end-to-end over all security. All connection points in the link need to be scrutinized for getting more secure.
Interoperability can be achieved automatically
Many people think by definition, Web Services are cross-platform, and it is the best technology for solving cross-platform interoperability problems. When
using standard based Web Service security solution, the interoperability between different platforms will be achieved automatically.
However, different versions of Web Service standards, such as
WS-Security and WS-SecurityPolicy, will create interoperability problems In fact, these are not just WS-Security problems, all WS-* protocols have interoperability problems when two sides have different versions
of standards.
For example, knowing that a web service supports WS-ReliableMessaging is not nearly enough. Is that WS-ReliableMessaging 1.0, 1.1 or 1.2? Is SOAP 1.1 or 1.2? Does it use WS-Addressing
1.0 or the WS-Addressing 2004/08 vendor submission? Is the security defined using WS-SecurityPolicy 1.1, 1.2, or 1.3? WS-Security 1.0 or 1.1? SAML 1.1 or SAML 2.0? WS-SecureConversation 1.2 or 1.3? Which version of
WS-ReliableMessagingPolicy? Are those policies based on WS-Policy 1.2 or 1.5? Or are some of the service's policy files based on 1.5 and others on 1.2?
Unfortunately every one of those specification
versions is valid and in almost any combination. But application server products typically support a subset of these spec versions and no two application servers support exactly the same set at the same time. Moreover,
in a large distributed network, it is impossible to update all the clients and Web Services, and bring everyone to the same version of standards at the same time. How can clients and web services interoperate?
The truth is that using standards will not achieve interoperability automatically. All those WS-* specifications from different platforms, from different vendors and their multiple versions is that web
service interoperability has become a giant M*N problem. When using standard based Web Services to talk to different platforms, there are many interoperability problems need to overcome. More over, in WS Security
case, the versioning will not only creates interoperability problems, but also will create security holes. All supported versions of standards need to be tested on interoperability, before deploy it into production
environment.
No need to understand Web Services security policy
Nowadays, Web Services are protected through defining the security policy of each service, and the policy will then be
enforced at the service end-point. Many people think WS-SecurityPolicy is too complicated, and normal users don't need to know the details of the security policy. They don't know that the Web Services security is driven
by the security policy, and hackers will look into the advertised security policy to find the vulnerabilities to attack.
For example, using WS-SecurityPolicy standard, if a wrong security policy is
selected to secure the Web Services messages will introduce unnecessary complications and result in over-engineering, bad interoperability, poor performance, and even threaten the security of the Web Service messages.
On the other hand, using the right policy will meet the security requirements of the individual system/services, and prevent hacker attacks.
The truth is that The WS-SecurityPolicy under OASIS WS-SX TC is
one of most rich SOA/Web Services specifications. In order to select the right policy to meet the requirements, the user has to understand the details of WS-SecurityPolicy and how security policy can be hacked or
misused and the results of the misuse. Security risks and threats associate to those security policies must be studied. .
Security Strategy for Cloud Computing
As enterprises move from
perimeter and infrastructure protection to protecting the messages over the cloud computing environments, the Web Services security is more important to the messaging exchanges. The need to protect Web Services messages
cuts across companies large and small and within every industry.
Strategies and solutions that enable enterprises to implement the necessary controls to protect Web Services message must be in place.
Security Architects need to have deeply understanding of issues and risks on the Web Services security for getting the better strategies and solutions.
