Chapter 2: Web Services Security
2.11 THE PERFORMANCE OF WEB SERVICES SECURITY
additional security contents in SOAP messages, the higher number of message exchanges to establish trust as well as extra processing time to process these additions. As the interaction between service providers and requesters occurs via XML-based SOAP messages, securing Web services tends to make these messages longer than they would be otherwise and consequently requiring interpretation by XML parsers on both sides, which reduces the performance of Web services (Menasce, 2002).
services with other middleware, such as CORBA and Java RMI. This study has shown that the performance of Web services is a major drawback. Another study (Jeckle, Melzer & Himsolt, 2004) also compared the same technologies and illustrated that the HTTP overhead causes higher response time for SOAP packages, which grows exponentially as the payload size increases.
The majority of the related studies have compared the performance of different toolkits. In (Machado & Ferraz, 2005), several SOAP toolkits have been evaluated with an objective of identifying and measuring SOAP inefficiency. Head et al. proposed a standard benchmark suite for quantifying and comparing the performance of the different SOAP implementations, such as gSOAP, AxisJava, XSUL and bSOAP (Head et al., 2005), and various XML parsers (Head et al., 2006).
Moreover, there have been several studies to benchmark the various aspects of performance by studying the effect of the implementation framework on the performance of Web services. For example, both studies by Sun Microsystems Inc. (2004) and Microsoft Corporation (2004) compared the performance of Web service technologies in two common middleware platforms: Java 2 Platform Enterprise Edition (J2EE) and .NET, that offer similar facilities for creating and using Web services. Similarly, Microsoft Corporation (2008) conducted a comparison of the performance of Web services applications deployed on two application servers (.NET 3.5/Windows Server 2008 vs. IBM WebSphere 6.1 ND/Red Hat Linux). Each of the previous studies claimed that its framework has theupperhandintermsofWebservices’performance; yet all the previous studies discussed the performance of plain-text services, without considering the security aspects of these services.
Early discussions of the security and performance trade-off (Vaughan-Nichols, 2002; Dodds, 2002) highlighted that SOAP-Web services suffer a performance hit when applying security measures. Because SOAP messages in their initial XML plain text are insecure, applying encryption and decryption on each message in the
service-side and client-side will increase the overhead of these messages and increase processing time in both ends.
In security related studies, Shirasuna et al. (2004) evaluated three security approaches, namely SSL, WS-Signature and WS-SecureConversation, for grid services. Their evaluation has shown that transport level security is faster than message level security, and should be used if there is no additional requirement to use message level security. Their results indicated that WS-SecureConversation should be used when several messages are exchanged between the service and the clients, where XML-Signature is slightly faster than WS-SecureConversation for one-time invocations. Nevertheless, WS-SecureConversation has a scalability concern if the Web service is invoked by a huge number of clients simultaneously. In a study of vertical scalability (i.e. adding capacity, such as processors and memory, to an existing system) of Tomcat Application Server, Guitart et al. (2005) examined the cost of security in Web services. However, its scope was restricted to the security of the communication channel, using SSL. Message layer security approaches were not considered in their tests.
Moralis et al. (2007) compared the performance of Web services with Kerberos Token Profile against X.509 Token Profile, while Liu, Pallickara & Fox (2005) conducted several tests for different operations (Signing vs. Verifying and Encryption vs. Decryption with several algorithms). Two studies by Tang et al. (2006) and Chen et al. (2007) compared the cost of WSS Signing and WSS Encryption. They indicated that using either the Username or X.509 tokens does not make a significant difference to the performance of Web services.
Sosnoski (2009) studied how using the WS-Security and WS-SecureConversation standards affect the performance of Java Web services implemented using the Apache Axis2 Web services stack. The aim was to provide a guideline on when and how to use WS-Security. He also suggested the usage of WS- SecureConversation for long-running exchanges of messages between clients and
service and its clients. Further work led by Sosnoski (2010) expanded that test to provide a performance comparison between the Apache Axis2 and Sun’s Metro Web services stacks. This experiment suggested that Metro is twice to three times faster than Axis2 when security configurations (i.e. signature, encryption and username tokens) are applied, even though they perform similarly without security.
Aiming at providing a general guideline for selecting appropriate security mechanisms, the work by Novakouski et al. (2010) compared different WS- Security mechanisms (i.e. Password Only, Sign Only, Encrypt Only. Sign Then Encrypt, Encrypt Then Sign, and WS-SecureConversation) in details. It examined the impact of applying these mechanisms on the performance of SOAP-based Web services, measured in terms of: Round Trip Time (RTT), message size and resource usage. The study established that to minimise the huge penalty of applying security on the performance of Web services, a good understanding of the requirements and expectations is required, as there is no supreme standard that can provide security and performance in all applications and systems.
The previously discussed studies, however, considered the performance of the security standards that can be applied on Web services, such as the usage of encryption and digital signature, and the type security tokens. Alternatively, our study focuses on the overall performance of the security profiles, which simplify the security usage. Each profile predefines a set of security features to be implemented when securing a Web service. This approach shields the developers of Web services from the complexity of making a technical decision and allows them to focus on addressing the requirements of the security system.