Myth on Web Service Security
Mobile Comm
Global e-Business
News & Insights
Contact Us


Security breach at Target part 2
FIDO Alliance Seminar
Security Breach at Target
Myth on Web Service Security
End-to-End Security for Cloud Computing
Optimize Security Services in the Cloud
Data at Rest, Data at Risk
Data Security Best Practices
DOD Common Criteria
Need for Information Security Professionals
Protect Social Security Info
Virtual VPN Gateway
Don't Hack the Ox!
6 eSecurity Pitalls
Data Security at Risk
CCNA Certification
NAC Forum
eSecurity Market
eSecurity Philosophy
PC Security
eSecurity Facts
Encryption Tool
Checking Security
Identity Theft
Home PC Security
eSecurity Training
Security Software
eSecurity & You
Web Security
Browser Security
Spyware & Viruses
448 Bit Encryption
Vital PC Security
Spyware Security
What's PC Security
Optimize eSecurity
Delete Cookies
Basic SB Security
eSecurity 101
Email Security

The Big Myths on Web Services Security
By: Judy Silk, eSecurity Editor, Internet Journal

Is Web Services security too heavy to use? Can we keep it simple and secure for Web Services security? It is very secure when Web Services security is adopted?  Can Web Services interoperability be achieved automatically?  Do I need to understand Security Policy on Web Services?

Standard Approach on Web Services Security

Web Services is a standard approach for message exchanges. Secure Web Services messages  is the act of exchanging Web Services request and response  messages with one or more of the following security qualities: integrity, confidentiality, authenticity and authorization. There are many WS-* security standards exist today for the Web Services security, including WS-Security, SAML, WS-SecurityPolicy, WS-SecureConversation, WS-Trust, and more.

Other Web Services stacks need to work together with Web Services security. For example, Web Services Reliable Messaging (WS-ReliableMessaging, WS-RM) messages need to be protected with security. There is Reliable Secure Profile (RSP) 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.

About The Author
Judy Silk is the e-Security Editor of the of the
Internet Journal. Internet Journal provides the insights and analysis on Internet marketing, eCommerce, mobile communications, eSecurity, and global e-Business. If you have any comments about Internet Journal, please send email to  

[Home] [eMarketing] [eSecurity] [Mobile Comm] [Global e-Business] [News & Insights] [Contact Us]