Authenticated Web Services: A WS-Security Based Implementation ? Vincenzo Auletta1 , Carlo Blundo1 , Stelvio Cimato2 , Emiliano De Cristofaro1 , and Guerriero Raimato1 1
Dipartimento di Informatica e Applicazioni, Universit` a degli Studi di Salerno Via Ponte Don Melillo - I-84084 Fisciano (SA), Italy. {auletta, carblu, emidec, raimato}@dia.unisa.it 2 Dipartimento di Tecnologia dell’Informazione, Universit` a di Milano
[email protected]
Abstract. Web Services technology provides software developers with a wide range of tools and models to produce innovative distributed applications. After the initial diffusion of the standard technology the attention of the developers has focused on the ways to secure the information flows between clients and service providers. For this purpose several standards have been proposed and adopted. Another important issue is how to count the number of accesses to a given service in order to develop standard business models, in which the providers get paid for the offered resources. In this paper we propose an implementation, based on WS-Security, of an existing framework for authenticated Web metering, and compare it with an ad-hoc implementation. Our analysis shows that WS-Security is mature enough to provide a flexible and dynamic layer to underlie complex and interactive applications which require security management, without the need of developing ad-hoc solutions for each provided feature.
1
Introduction
Web Services technology is often presented as an efficient solution to the increasing request for flexible connection and dynamic cooperation of distributed systems over the Internet. More in general, such technology offers a new set of standards and techniques which has having a very significant impact on IT organizations and is collecting a large amount of interest concretized in common research projects and money investments. Indeed, interoperability, cross platform communication, and language independence are only a part of the appealing characteristics of Web Services. The standardization and the flexibility introduced by Web services in the development of new applications translate into increased productivity and gained efficiency. Development costs are also reduced ?
The work of the authors has been supported in part by the European Commission through the IST program under Contract IST-2002-507932 ECRYPT and under contract FP6-1596 AEOLUS
since the use of standard interfaces, enabling the integration among applications and the reuse of existing solutions, may shorten the total development cycle. Actually there are many examples in which Web Service technology has been employed, typically in enterprise application integration, development of B2B integration initiatives and Service Oriented Architecture projects. As soon as companies provide business services and release new products and tools Web services enabled, a problem which in our opinion will become more and more challenging, is the need of methodologies to accurately measure the number of accesses to a given service. Metering techniques have been developed in the context of measuring accesses to Web pages, where it is important to have a statistics on the exposure of advertising [13, 10]. Recently, several directions for designing efficient and secure metering schemes have been proposed. Many proposals are based on various cryptographic techniques, as secure function evaluations, threshold cryptography, and secret sharing. For instance, see [14, 7, 11]. In the context of Web services usage, such metering techniques can be helpful in the development of new business models, where an audit agency is in charge of registering clients accessing the services, and of paying the servers claiming for payment, after that a valid proof of the number of serviced requests is presented. In metering schemes, a proof is a value that the server can compute only if a fixed number of clients have visited it or a client has visited it a certain number of times. Such a value is sent to the audit agency at fixed time intervals. The widespread use of Web Service for providing business level solutions put a great emphasis on security issues of the developed applications. The goal is to provide software developers with standard security techniques, enabling the creation of business models in which service providers get paid for the offered resources. In this sense, it is important to combine authentication techniques with mechanisms which allow to count the number of accesses for a given service in a secure way. Up to a few years ago, the most diffused approach for handling authentication credentials was to use custom SOAP headers to transmit user credentials. In last years, many supplemental standards for guaranteeing security features in Web Services have been proposed and collected under the WS-Security specification [12]. This specification (whose last version has been released at the beginning of the 2006) is the result of the work by the OASIS Technical Committee [4] and proposes a standard set of SOAP extensions that can be used when building secure Web services to provide confidentiality (messages should be read only by sender and receiver), integrity and authentication (the receiver should be guaranteed that the message is the one sent by the sender and has not been altered), non repudiation (the sender should not be able to deny the sending of the message, and compatibility (messages should be processed according to the same roles by any node on the path message). Such mechanisms provide a building block that can be used in conjunction with other Web service extensions and higher-level applications to accommodate a wide variety of security models and security technologies. Some other related standard proposals are also available, such as SAML [5], XKMS [6], and so on. Each proposal refers to a particular aspect of securing the information flow and pro-
tecting the data exchange between the client and the service provider. Although WS-Security (as well as the other secure related specification) is relatively new, only recently, it has been widely adopted and (almost) completely supported by multiple toolkits. In this work, we consider the problem of implementing a secure, authenticated, and efficient metering system. In [8] a Web Services-based framework is described that implements the metering scheme presented in [9] for Authenticated Web Services. This implementation is characterized by static invocations of the Web Services using custom SOAP headers to provide authentication. In this paper, we describe a novel implementation of the framework given in [8], based on WS-Security. The SOAP header contains the authentication token which can be used when accessing a restricted web service, where the authentication token is embedded in the message using the mechanisms provided by WS-Security. We compare our implementation with the one presented in [8] and analyze its performance. This analysis shows that WS-Security is mature enough to provide a flexible and dynamic layer to underlie complex and interactive applications which require security management, without the need of developing ad-hoc solutions for each provided feature. Moreover, the available implementations of the standard allow to solve standardization and compatibility issues, achieving a completely standard and dynamic solution. In particular, we show how WSSecurity can be used to overcome the addition of customized information inside the SOAP header to provide authentication in metering schemes. Furthermore, we present a thorough performance analysis that display that the implementation based on WSS performs better than the one presented in [8], despite the latter provides a dedicated solution. The rest of the paper is organized as follows. In Section 2, we present the scheme for Authenticated Metering. In Section 3, we recall the framework and its implementation presented in [8]. In Section 4, we propose our implementation based on WS-Security. Finally, in Section 5, we give a thorough performance analysis to compare the two implementations.
2
Authenticated Metering Scheme
Metering systems monitor services accesses either for statistical or billing goals. An audit agency is in charge of counting the number of clients accessing the services, so that service providers can be payed according to the number of visits received. Because it measures the interactions between many servers (service providers or Web site hosts) and clients (Web surfers), the audit agency needs a mechanism that ensures the validity and accuracy of usage measurements by preventing fraudulent actions by servers or clients. In this work we refer to the software infrastructure presented in [9] and the framework given in [8] that implements this infrastructure. The metering system consists of n clients, say C1 , ..., Cn interacting with an audit agency A and a server S. The audit agency is in charge of keeping trace of the number of times the clients accesses a service provided by the server S. The scheme is
tightly based on registration and authentication of clients and it relies on three phases: Initialization The initialization phase starts when a client C contacts the audit agency A and requests access to the provided service. A number of subsequent operations are started by each of the players: – The audit agency A calculates a random seed, say w0 , and computes the value of the k-th application of a cryptographic hash function H, that is wk = Hk (w0 ) = H(Hk−1 (w0 )), where H2 (w0 ) = H(H(w0 )). Then, A stores the tuple [idC , k, w0 ] holding the client identifier idC , the number of guaranteed accesses k, and the seed w0 . Finally, it sends the two tuples [idC , k, w0 ] and [idC , wk ] to the client C and the server S, respectively. – The client C stores the tuple sent by A and retrieves the initial seed w0 and the number k of accesses it registered for. Then, C generates and stores the k values3 w1 = H(w0 ), w2 = H(w1 ), . . . , wk = H(wk−1 ). The client will use the token wk−j to access an authenticated service the j-th time. The client keeps trace of the last access and maintains an access counter. – The server S stores the tuple received from A in its database of registered clients, associating it with a counter LC initially set to 0. Interaction Interaction happens when the client C visits the server site S and wants to access the restricted services offered by S. Suppose that C is accessing the service for the j-th time. – The client C, within a service request, sends the token wk−j = Hk−j (w0 ) to S, and it updates the access counter for the authenticated service decrementing its value. – The server S, on the reception of the token, performs an access control, verifying that the value resulting from the application of the hash function H to the received token matches the last stored value for the client C, that is H(wk−j ) = wk−j+1 . If the two values match, then he updates its stored values with the new received token wk−j and increments the client counter LC . Verification The verification phase begins when the server S claims the payment after a certain number of visits received by a client C in a certain period of time previously agreed with the agency A. – The server S sends to the audit agency A the tuple (idC , W, LC ), where idC is the client’s identifier, W is last stored authentication token for C, and LC is the client’s counter. – The audit agency A verifies that the value sent by S for C equals to Hk−LC (w0 ). In this case, S may claim a payment from A for the services granted to C. 3
The values w0 , w1 , . . . , wn are referred to as hash chain with seed w0 .
3
The framework
In [8], a framework has been designed to carry out the operations discussed in Section 2. In this framework the three entities, client, server, and audit agency, expose their services as Web Services. The time diagram of the interactions is presented in Figure 1. As depicted, the four interactions are carried out in the following way:
Fig. 1. Architecture of the framework in [8].
– Client/Audit Agency. Client registers himself with the audit agency in order to get a valid authentication token. To this aim, the audit agency exposes the returnClientToken service. The SOAP request contains the number of requested accesses; while, the SOAP response is composed by a univocal client identifier idC , the number of obtained accesses k, and the initial seed w0 used to calculate the authentication tokens (i.e., the values in the hash chain). – Audit Agency/Server. The server exposes the clientRegister service in order to receive from the audit agency the data associated with the newly registered client. The SOAP request invoked by the audit agency contains the client identification idC and the last value of the hash chain Hk (w0 ). – Client/Server. This stage handles the client access to the restricted service. Therefore, a dedicate handler must come into play in order to provide authentication. The server uses the authentication information (idC , hashV alue) sent by the client C and its stored information associated to C to verify whether the client C has the right to access the requested service. If so, it grants access, otherwise it raises a SOAP fault. A Synchronization service is also provided in case the client sends a wrong hash value through having the right one. The server, as challenge for the client C, provides the hash value currently associated to C, say wj , as well as the counter LC . The client replies with the pre-image of the hash value, namely wj−1 . Due to the oneway property of the hash function, this is possible only if the client knows the hash chain. Indeed, from LC and w0 the client can compute wj−1 as Hk−LC −1 (w0 ).
– Server/Audit Agency. The last interaction is performed when the Server has to require to the Audit agency the payment for the C’s accesses. In this case, it has to provide to the audit agency a proof of the number of served requests. The audit agency exposes the Audit service. Server’s SOAP requests contain the client’s identifier, the last stored authentication token for that client, and the number of registered accesses. The audit verifies that the values sent by S match the stored values, and acts consequently. 3.1
Implementation based on Ad-hoc SOAP headers
The implementation of the framework presented in [8] has been developed within the Java platform, using Tomcat as the Servlet Container, and Axis [1] as the SOAP engine. One of the crucial points of the framework is the submission of the authentication credentials of the Client to the Server. The Client sends an authentication token (composed of idC , hashV alue) in a SOAP Header. This header is created by a SOAP Handler, which is in charge of intercepting SOAP requests, adding client’s authentication information to the header and attach it to the SOAP message before sending it to the Web Service, as showed in Figure 2. The Java class has to implement the java.xml.rpc.handler.Handler interface and, in particular, the handleRequest method.
Fig. 2. Intervention of the handler to add authentication information.
The core of this method can be summarized as follows. Recover message envelope. Create a SOAP header named authHeader. Attach the idClient and the hashValue. On the server-side, there is a dedicated handler (AuthenticateHandler ) that is in charge of intercepting the Authentication Header and verifying the correctness of the authentication token before the service is invoked. This implementation was based on Java2WSDL and WSDL2Java tools. Starting from the Java classes of the services, they obtain the correspondent WSDL files using the Java2WSDL tool. After that, the tool WSDL2Java creates from the WSDL files all the stubs, skeletons, and data types needed to the framework.
4
Implementation based on WS-Security
In this section, we give a new implementation of the framework proposed in [8]. The main differences of this implementation are dynamic invocations of the services and the use of WS-Security to execute the authentication operations.
In static invocation, the clients generate proxy stubs at development time, using the WSDL of the Web Service. The clients invoke the methods in the proxy stub, which in turn invokes the methods in the Web Service. Therefore, if the WSDL changes, these proxy stubs have to be re-generated. Then, our implementation instead is based on dynamic invocations. Proxy stubs are generated at run-time, using the dynamic invocation APIs. The advantage is that any change to the WSDL file will not affect the Web Service invocation. To provide client authentication, we use WSS4J [2], the standard implementation of WSSecurity provided by the Apache Software Foundation. This package implements WS-Security mechanisms and also achieves interoperability between JAX-RPC [3] based and .NET based client/servers. WS-Security has been designed as a flexible set of mechanisms that can be used to build several security protocols. WS-Security gives an appropriate profile to provide authentication: the User Name Token allows users to authenticate themselves by sending as credentials a Username and eventually a Password. Together with the password, some extra information can be set, such as the type of the password (PasswordText or PasswordDigest), a Nonce to avoid replay attacks or a TimeStamp. In this way, the management of authentication information is no longer carried out by ad-hoc and customized handlers, but through WSS4J built-in handlers, named WSDoAllSender and WsDoAllReceiver. These handlers are transparent to user applications and operate according to standard specifications. Figure 3 shows the interaction scheme of the UsernameToken profile as implemented by WSS4J.
Fig. 3. The interaction scheme of the UsernameToken profile as in WSS4J.
1. The SOAP message created by the client application is intercepted by WSDoAllSender and processed before it is sent to the server. Programmers do not have to modify this handler, since it gets the information needed to build the UsernameToken header by the security header in the SOAP message
through a standard class, named PWCallBack. Application developers take care of this class, which must implement the javax.security.auth.CallBackHandler interface, according to the application needs. 2. The SOAP message is sent to the service. The WSDoAllReceiver intercepts the message and processes the authentication information stored in the message. Once again, the handler makes use of a callback class, named ServerPWCallback. This must implement the javax.security.auth.callback.CallbackHandler interface to verify whether the client has the right to access the service. 3. If the verification is passed, the handler returns the control to the application otherwise a WSSecurityException is thrown. 4.1
Framework implementation with WSS4J
As seen in Section 2, authentication tokens are used in the interaction phase, when clients have to send credentials to the server to access the service. We have seen in the previous section that this can be achieved by using the WSS4J UsernameToken, where the idClient is the username and the hashValue is the password. On the server-side, the UsernameToken profile is processed by the WSDoAllReceiver handler, which has to be included in the Axis service request flow chain. This is specified in the Web-Service Deployment Descriptor file and done using the Axis services deployment tool. On the client-side, instead, the UsernameToken profile is built by the WSDoAllSender handler, which has to be included in the Axis service request flow chain. To do this, application developers could perform a static deploy of the service on the client-side. However, we discard this solution for two reasons. First, the username field is assigned dynamically by the audit agency to any newly registered client and changes if the logged user changes. Second, the handler would be globally inserted in the client’s requestFlow and be called for any invoked service. We decided to dynamically provide to WSS4J the username of the UsernameToken profile, using the dynamic configuration of the Axis Engine. The code for the org.apache.axis.configuration.SimpleProvider class was written to implement the org.apache.axis.EngineConfiguration interface. This solution is graphically presented in Figure 4 and has been implemented in a dedicated infrastructure that hides all the details related to the handler and to the dynamic configuration. To this aim, a Java package, CHM (Client
Fig. 4. The dynamic configuration of Axis Engine.
Handler Manager) has been released.
Users just have to dynamically provide username and password, by querying them from a database. We have implemented repositories as MySQL databases, accessed through the JDBC API. The data held by the Server, the Audit, and the Client have been stored in separate databases holding one table for each subject. MySQL has been chosen, being open-source and cross-platform. Classes contained in the CHM package extend the Axis Client API, thus achieving transparency and compatibility. The core class of the infrastructure is the Service class. It implements the dynamic configuration which allows to use the UsernameToken profile by providing dedicated methods to set username and password (in our case the client’s identifier and the hash value, respectively) to bind to the configuration. It is within this classthat the dynamic configuration is carried out through the use of the EngineConfiguration interface. Other two classes have been extended: the Call and the PWCallback classes. The former essentially sets the password property with a dynamic input value and sets the callback class PWCallBack that will be invoked by WSDoAllSender. This is in charge of providing to WSDoAllSender the password associated to username given to WSS4J.
5
Performance Analysis
In this section we compare performances of our dynamic WS-security based implementation against the static ad-hoc solution given in [8]. The experiments were held on the following test bed: – – – – –
PC IBM ThinkCentre 50 - Pentium 4 2,6 GHz with 760 MB RAM. Linux Suse 10 - Kernel 2.6.16. Sun Java VM version 1.4.2 13 SDK. Apache Tomcat 5.5.28 as Servlet Container. Axis 1.3 as the SOAP Engine.
Our first experiment compared times taken by the client to build the header with the security information. Tests were repeated 100 times with 100 different accesses. Figure 5 shows times for the 100 requests in both the implementations. With the ad-hoc SOAP headers based on WSDL4Java, we obtained an average construction time of 93,69 ms. Whereas, with the WSS4J-based implementation, the average time to build the header for the SOAP request was 51,65 ms. In both tests we witness almost uniform times, with some periodical peaks basically due to internal operations of the Java virtual machine, such as garbage collection. The difference between the two implementations is remarkable. The WSS4J-based implementation performs better thanks to the smaller number of involved objects in order to build the header. With WSDL2Java a set of stubs are requested in order to insert the handler in the chain and to serialize information. In the second test, we measured times taken by the server to process the header with the security information. Figure 6 shows processing times for each request with both the implementations. Also in this case the WSDL4Java-based implementation has worse performances. In fact, the implementation described
Fig. 5. Time to build client header with the WSDL4Java and WSS4J implementations.
in [8] reports an average response time of 81 ms for 100 accesses. Our implementation instead obtains an average response time of 61 ms. In the third test, we have compared the entire round trip times, i.e. the total times required for an invocation of a service. To this aim, we used a very simple application (Echo), so that performance analysis is not affected by computation or overhead bounded to the service. The comparison between the two implementations should only be related to the managing of authentication information. Results of this test are summarized in Figure 7. Also in this case, the WSS4J-based implementation has better performances. As discussed in section 4, besides relying on the WS-Security standard, our implementation makes the programmer task easier by the dynamic invocations of deployed Web Services for all the provided features. Despite this greater work assigned to the SOAP engine, performance experiments showed that no increase occurs in running times of any service. The client, in the Initialization phase,
Fig. 6. Time to process headers with the WSDL4Java and WSS4J implementations.
contacts the audit agency to request a certain number of accesses. Tests were ran with a growing number of requested accesses, in order to evaluate different performances with more and more hashing operations. We saw that times grow gracefully according to the number of requested accesses. The time required for the client’s registration of the two implementations is essentially equivalent. Therefore, achieving dynamic invocations does not lead to a performance worsening. In conclusion, performance evaluations showed that WS-Security can be used to implement the scheme of Authenticated Web-Services. Therefore, we can conclude that WS-Security is mature enough to provide a flexible and dynamic layer to underlie complex and interactive applications which require security management, without the need of developing ad-hoc solutions for each provided feature.
Fig. 7. Round Trip Time for the two implementations.
References 1. Apache Axis. http://ws.apache.org/axis/. 2. Apache Web Services Security For Java. http://ws.apache.org/wss4j/. 3. Java API for XML-based Remote Procedure Call (JAX-RPC). http://java.sun.com/webservices/jaxrpc/. 4. Organization for the Advancement of the Structured Information Standards (OASIS). http://www.oasis-open.org/home/index.php. 5. SAML. http://www.oasis-open.org/committees/security/. 6. XML Key Management Specification (XKMS). http://www.w3.org/TR/xkms/. 7. S. G. Barwick, W. Jackson, and K. Martin. A general approach to robust web metering. Designs, Codes, and Cryptography, 36(1):5–27, 2005. 8. C. Blundo and S. Cimato. A framework for authenticated web services. In Proceedings of Europen Conference on Web Services (ECOWS 04), Lecture Notes in Computer Science. 9. C. Blundo and S. Cimato. A software infrastructure for authenticated web metering. IEEE Computer, 37(4):28–33, 2004. 10. M. K. Franklin and D. Malkhi. Auditable metering with lightweight security. Journal of Computer Security, 6(4):237–256, 1998. 11. S. S. Kim, S. K. Kim, and H.-J. Park. New approach for secure and efficient metering in the web advertising. In Proceedings of International Conference on Computational Science and Its Applications (ICCSA 2004), Lecture Notes of Computer Science, volume 3043, pages 215–221. Springer-Verlag, Berlin, 2004. 12. A. Nadalin, C. Kaler, P. Hallam-Baker, and R. Monzillo. Web Services Security: SOAP Message Security 1.1. OASIS. http://www.oasis-open.org/committees/download.php/16790/wss-v1.1-spec-osSOAPMessageSecurity.pdf, 2006. 13. M. Naor and B. Pinkas. Secure and efficient metering. In Proceedings of Advances in Cryptology - Eurocrypt ’98, Lecture Notes in Computer Science, volume 1403, pages 576–590, 1998. 14. W. Ogata and K. Kurosawa. Provably secure metering scheme. In Proceedings of ASIACRYPT 00, Lecture Notes in Computer Science, volume 1976, pages 388–398. Springer-Verlag, Berlin, 2000.
