Building Autonomic and Secure Service Oriented Architectures with MAWeS Valentina Casola1, Emilio Pasquale Mancini2 , Nicola Mazzocca1 , Massimiliano Rak3 , and Umberto Villano2 1
3
Dipartimento di Informatica e Sistemistica, Universit` a degli studi di Napoli Federico II {casolav,n.mazzocca}@unina.it 2 RCOST and Dip. di Ingegneria, Universit` a del Sannio {epmancini, villano}@unisannio.it Dipartimento di Ingegneria dell’Informazione, Seconda Universit` a di Napoli
[email protected]
Abstract. Service-oriented architectures (SOA) and, in particular, Web Services designs are currently widely used for the development of open, large-scale interoperable systems. In those systems performance, security and trustability are challenging open issues. As regards performance, in Web Services designs, abstraction layers completely hide the underlying system to all users, and classical techniques for system optimization (such as ad-hoc tuning, performance engineered software development, ...) are not applicable. As far as security is concerned, the need of trust mechanisms in open environments is a well-known problem, widely discussed in the literature, but few techniques for security evaluation are available. In this paper we propose an integrated solution to optimize performance and to guarantee security of Web Services architectures. The proposed solution is based on a framework, MAWeS, which adopts simulation in order to predict system performances and adopts policies for security description and evaluation.
1
Introduction
Service-oriented architectures (SOA) and, in particular, Web Services designs are currently widely used for the development of open, large-scale interoperable systems. As a matter of fact, many enterprises rely on them to interconnect critical services and to provide added quality to their customers [1,2,3,4]. However, reliability, availability, performance and security of these architectures are completely open issues. As regards performance, in Web Services designs abstraction layers completely hide the underlying system to all users, and classical techniques for system optimization (such as ad-hoc tuning, performance engineered software development, ...) are not applicable. As far as security is concerned, the need of trust mechanisms in open environments is well-known problem, widely discussed B. Xiao et al. (Eds.): ATC 2007, LNCS 4610, pp. 82–93, 2007. c Springer-Verlag Berlin Heidelberg 2007
Building Autonomic and Secure Service Oriented Architectures
83
in the literature. Different approaches to define and assess trust have been proposed [5,6,7,8]. In particular, the concept of trust includes different aspects such as access control, reputation, security and service level agreements [9,6,10,11]. The object of this paper will be to study an integrated solution to performance and security of Web Services architectures, which is based on the use of an autonomic framework exploited to auto-configure and to auto-tune the system, guaranteeing optimal performance and fulfillment of given security levels. Autonomic computing [12,13,14,15], whose name derives from the autonomic nervous system, aims to bring automated self-management capabilities into computing systems. Autonomic capabilities are usually classified in four different categories: Self-configuring. The system can dynamically adapt to changing environments; Self-healing. The system can discover, diagnose and react to disruptions; Self-optimizing. The system can monitor and tune resources automatically; Self-protecting. The system can anticipate, detect, identify and protect itself against threats. Most of the times, the optimizations carried out by a “self-optimizing” system are related to one or several performance metrics (i.e., response time, throughput, quality of service, ...). However, optimizations are not necessarily linked only to system performance, as the object of optimization could also be to obtain a given security level, or to reconfigure for performance, but in such a way that the desired security level is guaranteed. For example, given a web application that relies on several component web services, replicated and variously distributed on multiple servers, an optimization step may be to find out the best-performing configuration of component services, in the current or predicted load conditions, such that the composed service guarantees an acceptable security level. In previous papers, we have introduced MAWeS (MetaPL/HeSSE Autonomic Web Services)[16], a framework whose aim is to support the development of self-optimizing autonomic systems for Web service architectures. It adopts a simulation-based methodology, which allows to predict system performance in different status and load conditions. The predicted results are used for a feedforward control of the system, which self-tunes before the new conditions and the subsequent performance losses are actually observed. In this paper we describe an extension of the MAWeS framework and its use for the development of autonomic SOA applications that optimize themselves in a proactive way, both for performance and security. In addition to the existing tools, adopted by MAWeS to simulate multiple system configurations and to choose the optimal one, a new security evaluation component has been developed that provides information on the security level of the various system configurations. This component is based on a a policy-based approach, and relies on the methodology previously published in [17]. The combination of security and performance predicted figures for multiple possible system configurations are exploited by the MAWeS optimization engine. This performs the feedforward control of the system taking into account the system state, the future load
84
V. Casola et al.
conditions and the possible behaviors of the service to be carried out. So the system autonomically self-tunes before the new load conditions are actually observed, settling in a configuration that guarantees optimal performance without decreasing the system security level. The remainder of the paper is structured as follows. Sections 2 and 3 describe the security and performance evaluation issues in Web Services Architectures and introduce the HeSSE/MetaPL prediction methodology and the security evaluation methodology. In Section 4 we describe the MAWeS framework with the new security extension, explaining how it can be used to choose the best configuration in terms of both performance and security requirements. Then we present a detailed description of the framework components, of the integration with the security evaluation component, of their behavior and of their usage. Finally, some conclusions are drawn and the directions of our future work are outlined.
2
Security and Trustability in Web Services
The need of trust mechanisms in open environments is a common problem, widely discussed in the literature. Different approaches to define and assess trust have been proposed [5,6,7,8]. In particular, the concept of trust includes different aspects such as access control, reputation, security and service level agreements [6,9,10,11]. In this paper we are interested in trustability concepts in open and distributed systems and, in particular, in Service Oriented Architectures, often implemented by means of Web Services technologies. IBM and Microsoft have recently proposed a reference architecture specification and a “roadmap for developing a set of Web Service Security specifications” [18]. The proposed architecture stems from the OASIS WS-security specification, which aims at describing enhancements to SOAP messaging and providing quality of protection through message integrity and message confidentiality. The reference architecture arranges available specifications on security and trust in layers. The WS-Security framework [19] defines the specifications for the construction of Trusted Domains (TDs). A TD is “an administered security space in which the source and the target of a request (i.e., requester and provider agents) can determine and agree whether particular sets of credentials from a source satisfy the relevant security policies of the target”. Inside a TD, when a requester R requests a service to a provider P, WS-Security provides the information needed to establish if both R and P have the needed credentials and respect their policies. The WS specifications need to be implemented to build a secure system and grant secure and trusted communications. The resulting trust communication model is illustrated in [19]; note that each Server Provider (Web Service) publishes its own security policy and implements access control mechanisms, and the Service Requester needs to hold the specified credentials. Security credentials are enveloped in security tokens that are managed by a Trusted Third Party (the Security Token Service). We explicitly note that the policy contains not only security provisions but also non-functional requirements, as quality of service or
Building Autonomic and Secure Service Oriented Architectures
85
Service Level Agreements. It is manually evaluated by the requesters when they need to choose a service for cooperation and to extend their trust to it. In a service oriented scenario, a Requester exploits component services in order to complete its task. In general, the component services are variously distributed and, possibly, offered by different providers with a different security level, i.e., the amount of security being provided (as defined in [8]). State of the art WS Specifications allow to find a service that offers requested functionalities but currently no automatic tool is available to evaluate if the chosen service is able to guarantee minimal security requirements. It is a common approach to describe security requirements through a policy, but current solutions make the user responsible for policy comparison and for deciding whether to trust or not a provider on the basis of its exposed policy. So, the general trustability problem can be related to the problem of comparing the exposed policies and classifying the related security levels. Anyway, due to the complexity of a real-world policy, the process of policy comparison may be very complex and error prone. Furthermore, the need for human intervention in a web services transaction is an undesirable condition as far as the interoperability requirements of third generation Web Services is concerned. To this aim, we have developed a security evaluation methodology to formalize policies, and to evaluate the security level associated to the corresponding service, as shown in next sections.
3
Self Optimization and Trusting
In a typical real-world scenario, a web application exploits component services in order to complete its task. Component services could be atomic or composed of other services, and they could be variously distributed and, possibly, offered by different providers with a different security level and with different load conditions. Figure 1 tries to summarize the problem that we address; it shows two main actors, a service requester (R) (the web application or the composed service) looking for a specific component service, and a set of service providers (Pi) offering such service. The requester searches for a service that fulfills a set of desired security requirements expressed by means of a policy, the Requested Policy (RP), and optimizes the overall response time. On the other hand, each service provider offers the service with different security levels, exposing them through published policies, the Offered Policies (OPs). On the other side, performance parameters are not included in the policy but need to be evaluated or predicted with external tools. The main questions to be answered are: 1. Does a service exist with an associated OPi that respects the security requirements needed by R? 2. If multiple configurations are available for such a service, which is the best in terms of performance and security?
86
V. Casola et al.
Fig. 1. The problem of trusted security requests
As regards the first point, we proposed an evaluation methodology for characterizing a policy and defining a metric to evaluate the security level associated to a service [17]. As for the second point, we implemented MAWeS, a framework for the choice of the best configuration of web services to optimize the overall performance parameters. In this paper, we will present an enhancement of MAWeS able to choose the best configuration that also guarantees that the minimal security requirements are fulfilled. In the following subsections we will briefly summarize the adopted security and performance evaluation methodologies. 3.1
The Security Evaluation Methodology
The methodology core is the Reference Evaluation Model (REM), defined as the following triplet: REM = < F ormalization; T echnique; Ref erenceLevels > where: Formalization represents the formal representation of the policy. A formalized policy may be expressed by a tag language (an XML schema or a DTD) or by a mathematical representation (such as a matrix of given dimension). We will adopt the standard WS-Policy language to describe the security features of each service. Technique represents the evaluation technique that can be applied to compare policies; it strictly depends on the policy formal representation. We will adopt a distance criterium to numerically evaluate and compare policies. Reference Levels are different policies, which represent different security levels. Applying the REM, we are able to obtain the so-called Global Security Level (GSL), which is a value associated to the overall security provided by a system implementing the policy. The detailed description of the methodology is out of the scope of this paper, but we will implement a security evaluation component to ascertain if a service provider is able to guarantee a required security level. The interest reader is referred to [17] for details.
Building Autonomic and Secure Service Oriented Architectures
3.2
87
The Performance Evaluation Methodology
In previous papers [16,20] we presented a framework, MAWeS, able to build selfoptimizing Web Services-based applications. The focus in the original framework was on time-related metrics for optimization (application response time, system throughput, ...), while the security problem was not dealt with. The MAWeS Framework is based on two existing technologies: the MetaPL language and the HeSSE simulation environment [16]. MetaPL is an XMLbased metalanguage for parallel programs description, which, similarly to other prototype-based languages, can be used when applications are in the design phase or when they are not completely available. It is language-independent, and can be adopted to support different programming paradigms; it is structured in layers, with a core that can be extended through Language Extensions, implemented as XML DTDs. These extensions introduce new constructs into the language. Starting from a MetaPL program description, a set of extensible filters makes it possible to produce different program views. Filters can be used to generate views for program comprehension or documentation purposes, but also to produce traces of program activity annotated with timing information. These traces are amenable to direct simulation in HeSSE, thus making it possible to obtain fairly reliable predictions of program performance, even at the very first steps of code development. HeSSE is a simulation tool that allows to simulate the performance behavior of a wide range of distributed systems for a given application, under different computing and network load conditions. It makes it possible to describe Distributed Heterogeneous Systems by interconnecting simple components, which reproduce the performance behavior of a section of the complete system (for instance a CPU, a network . . . ). The MAWeS framework relies on MetaPL descriptions, describing the software structure, and on HeSSE configuration files, describing the hardware/software execution environment, to run HeSSE simulations and to obtain performance data. Through the execution of multiple simulations, corresponding to different parameterized configurations, MAWeS can choose the parameter set that optimizes the software execution according to one or several criteria (e.g., shortest response time). The MAWeS framework makes it possible to optimize Web Services applications at two different, non exclusive, levels: Application Level. The autonomic system affects user applications, modifying their resource use and the order of the actions they perform. Examples of use of MAWeS for application-level optimizations are presented in [16]. Service Level. The autonomic system affects the service provider, i.e., the optimization actions have impact on the tuning of service parameters and on the workload management policies of the set of offered services. Examples are presented in [16,20].
88
V. Casola et al.
4
Security MAWeS Architecture
In the following, we will describe the new architecture of the framework, dealing with both self-optimization and trusting features in an integrated way.
Fig. 2. The MAWeS Framework Basic Architecture
As shown in Figure 2, the Framework underlying architecture is structured in three layers: Frontend: Made up of the software modules used by the requester (i.e. web applications or other services) to access the MAWeS services; Core: Composed of the software that makes optimization decisions; Evaluation Services: The services that perform the system evaluation in order to make decisions. The layers will be described in detail in the following subsections. 4.1
MAWeS Frontend
The MAWeS FrontEnd has not been changed, as compared to the one in the previous versions of the framework. Hence, for brevity’s sake, here we will give only some essential information about it. Self-optimization services may be offered, as previously pointed out, at application or service level. In the first case (application level optimization) the web application searches for a set of composing services which, granting the security level requested, minimizes its response time. This means that it adapts itself
Building Autonomic and Secure Service Oriented Architectures
89
predicting the performance of the composing services. The MAWeS Frontend, in this case, is a standard client which can be integrated into the web application, and sends to the MAWeS core all the application-related information (performance metrics, behaviour, security requirements, . . . ) needed to perform the simulations. Details about this kind of optimization can be found in [16]. In Service level optimizations, the MAWeS core aims at minimizing the response time of a self-optimizing service. In this case, the MAWeS frontend is integrated in the service, which invokes the MAWeS core in order to optimize its execution. Invocations can take place in two modalities: for each service (Service Call Approach) invocation, or in correspondence with particular events (Reactive Approach). Details about this kind of optimization can be found in [20]. In both cases, the MAWeS Frontend produces a MetaPL application description embedded with information useful for self-optimization (i.e., the optimization target, the application parameters that can possibly be modified, the target configurations, . . . ) and sends it to the MAWeS core. 4.2
MAWeS Core
The MAWeS Core exploits environment services (i.e., the services offered by the environment to monitor and possibly to configure itself) and the Evaluation Web Services to find out optimal execution conditions (in terms of both performance and security). The MAWeS Core is subdivided in three logical components: Interface Unit, which receives the MetaPL document and retrieves the optimization information, the Decision Unit, which controls the execution of the evaluation processes in order to make decisions, and the Evaluation Clients, which invoke the Evaluation Services. The MAWeS core can work on-line, i.e., when the application/service requests the optimization, and off-line, i.e., independently of the execution of the applications or services. Furthermore, MAWeS is invoked off-line, in order to publish the available configurations or new available services; it collects the information needed to perform the optimizations. Interface Unit. The task of the Interface Unit (IU) is to find the parameters that may affect the application performance and to pass this information to the Decision Unit. In order to do so, it extracts from the MetaPL application description all information that may possibly be used to optimize the application. The MetaPL description explicitly declares the optimization target by means of the Target element, whose attribute kind specifies if the target is to maximize a performance metric (default), or to guarantee a desired minimal security level (GSLmin). A single MetaPL description may contain more than one Target. Furthermore, the service requester (web application or composed service) needs to indicate explicitly the type of security credentials that it intends to adopt. This information will be also used to choose the most suitable configuration. To include such credential information, MetaPL has been enriched with
90
V. Casola et al.
a new element, credential, whose attribute kind specifies the kind of credential. At the state of the art, the working prototype supports login/password credentials (pwd value), digital certificate, or no credential (nothing). Evaluation Clients. Evaluation Clients are a set of clients that let the MAWeS core to interoperate with the Evaluation Services, which perform performance predictions and policy evaluations. They are the MH Client and the SEC Client. The M/H (MetaPL/HeSSE) Client is a software unit that implements a client for the MetaPL/HeSSE web services. Its implementation is threaded, in that each client instance runs as a new thread. This makes it possible for the MAWeS core to start in parallel as many M/H clients as necessary. Each client invokes the services needed to perform the simulation and analysis for each different configuration, and gets the corresponding results. The Decision Unit collects all the results, compares them and makes its decisions. The SEC Client is a software unit that implements a client for the Security Evaluation web service; it is usually invoked off-line to evaluate the GSL of each published service that will be stored in the SIU. Decision Unit. The Decision Unit (DU) contains all the framework autonomic intelligence. It applies the optimization rules defined by the framework administrator to optimize the target applications by means of the feedforward approach described in the introduction. The DU is made out of two different units: the System Information Unit (SIU) and the Optimization Unit (OU). The former maintains information about the system status, i.e., the list of valid configurations with their GSLs. The latter requests to the MetaPL/Hesse client to simulate all admissible configurations and compare them. When MAWeS manages a new request, the SIU extracts the list of configurations whose GSL is greater than GSLmin, while the OU invokes the MetaPL/HeSSE clients in order to obtain performance predictions. In particular, the Optimization Unit analyzes all possible configurations after their evaluation, and chooses the one with maximum performance among the ones that meet the minimal security requirements. The OU requests to the SIU all available configurations that are accessible with user provided credentials, and whose GSL is greater than the requested GSLmin. It asks to the MetaPL/Hesse WS (through the MH client) the evaluation of all admissible configurations and, after that, it chooses the best configuration. It should be noted that in the current version of the framework we assume that all service policies are published and evaluated off-line by the System Information Unit. This uses a Security Evaluation Service to perform the GSL of each available service, as explained later in this section. The System Information Unit holds all system and status information, as follows: – available simulator configurations (which correspond to the different real system configurations);
Building Autonomic and Secure Service Oriented Architectures
91
– security policies related to different configurations and the corresponding security level (GSL); – associations between policies and configurations. Furthermore, the SIU includes a Monitoring and Discovery Unit that updates the temporal parameters for the simulator. Moreover, it invokes the Security Evaluation Client to evaluate the GSL of each policy to be maintained. 4.3
Evaluation Components
Evaluation components include a set of Web Services that make it possible to obtain performance predictions and security evaluation of the submitted configuration. Simulation and performance prediction services that implement the HeSSE simulator and apply the MetaPL filters are described in detail in [16,20]. The security Evaluation service implements the novel security evaluation methodology proposed in [17] and previously summarized, that allows to evaluate the Security Level provided by a service or by a system from its published policy. It receives the policy, described according to WS-Policy language, applies the formalization process (as described in [21]), applies the evaluation technique, and returns the GSL. 4.4
The MAWeS Execution Flow
In conclusion, MAWeS performs on-line the optimization on request from the application or services, but collects the information about configuration off-line. Figure 3 illustrates how MAWeS works “on-line”: (1) the MAWeS Frontend submits the request to the core, attaching the MetaPL document containing the GSLmin, the types of credential and the application description. (2) The interface unit extracts from MetaPL the GSLmin, the credentials, the performance optimization target, the application parameters and the application description and forwards them to the DU. (3) The DU optimization unit gets the parameters from IU and requests the available configurations to the SIU. The SIU extracts from the local database the list of valid configurations whose GSL, evaluated off-line, is greater than GSLmin. (4) The SIU returns the list of valid configurations. (5) The optimization Unit starts the cycle of simulations, submitting the configuration and the MetaPL application description to the MH clients, which generate the traces and simulate them on the target configuration (5a and 5b). (6) The MH client returns the set of performance measurements for valid configurations. (7) The optimization unit chooses the best configuration and returns it to the IU. (8) The final results are sent to the Frontend. The grey box describes the “off-line” publication of configurations and policies, together with the policy evaluation process. When the new couple configuration/policy is published, the SIU forwards the policy to the SEC client, which performs the GSL evaluation and returns the value. The SIU stores the GSLs ordered by growing GSL values.
92
V. Casola et al.
Fig. 3. The MAWeS execution Flow
5
Conclusions
In this paper we have proposed an innovative approach to the development of self-optimizing autonomic systems for Web Services architectures with trust requirements, based on the adoption of simulation for performance prediction and feedforward control and a security evaluation methodology to guarantee the security level of the adopted services. The approach relies on the autonomic framework MAWeS, now enriched with security features. We have shown the new framework architecture and how it works. The proposed framework opens a new way for the development of autonomic and trusted systems, which, in a way transparent to users and easily manageable by developers, let services and applications to self-optimize, maintaining a given security level.
References 1. Booth, D., Haas, H., McCabe, F., Newcomer, E., Champion, M., Ferris, C., Orchard, D.: Web Services Architecture. W3C Web Services Architecture Working Group (2004) http://www.w3.org/TR/2003/WD-ws-arch-20030808 2. Balasubramanian, V., Bashian, A.: Document management and web technologies: Alice marries the Mad Hatter. In: Commun. ACM., vol. 41(7), pp. 107–115. ACM Press, New York (1998) 3. Chandrasekaran, S., Silver, G., Miller, J.A., Cardoso, J., Sheth, A.P.: Web service technologies and their synergy with simulation. In: Proc. of Winter Sim. Conf., San Diego, California, USA, vol. 1, pp. 606–615. ACM, New York (2002)
Building Autonomic and Secure Service Oriented Architectures
93
4. Chandrasekaran, S., Miller, J.A., Silver, G., Arpinar, I., Sheth, A.P.: Performance analysis and simulation of composite web services. In: Electronic Markets, USA, Routledge, vol. 13(2), pp. 120–132 (2003) 5. Bishop, M.: Computer Security. In: Art and Science, Addison-Wesley, London (2003) 6. Bicarregui, J., Dimitrakos, T., Matthews, B.: Towards security and trust management policies on the web (2000) 7. Beth, T., Borcherding, M., Klein, B.: Valuation of trust in open networks. In: Gollmann, D. (ed.) Computer Security - ESORICS 94. LNCS, vol. 875, pp. 3–18. Springer, Heidelberg (1994) 8. Department of Defense: Trusted computer system evaluation criteria, Department of Defense Standard 5200.28-STD (Orange Book) (1985) 9. Xiong, L., Liu, L.: Building trust in decentralized peer-to-peer electronic communities. In: Proceedings of ICECR-5, Montreal, Canada (2002) 10. Dini, O., Moh, M., Clemm, A.: Web services: Self-adaptable trust mechanisms. In: Proc. of Advanced Industrial Conference on Telecomunication/Service Assurance with Partial and Intermitted Resource Conference /E-Learning on Telecomunication Workshop, IEEE Press, New York (2005) 11. Chung, J., Zhang, J., Zhang, L.: WS-Trustworthy: A framework for web services centered trustworthy computing. In: Proc. of IEEE Int. Conf. on Services Computing (SCC 04), Washington, DC, USA, pp. 186–193. IEEE Computer Society, Los Alamitos (2004) 12. Birman, K.P., van Renesse, R., Vogels, W.: Adding high availability and autonomic behavior to web services. In: Proc. of 26th Int. Conf. on Software Engineering (ICSE 2004, pp. 17–26. IEEE Computer Society, Los Alamitos (2004) 13. IBM Corp.: An architectural blueprint for autonomic computing, USA (2004) 14. Kephart, J.O., Chess, D.M.: The vision of autonomic computing. In: Computer, vol. 36(1), pp. 41–50. IEEE Computer Society Press, Los Alamitos (2003) 15. Zhang, Y., Liu, A., Qu, W.: Software architecture design of an autonomic system. In: Proc. of 5th Australasian Workshop on Soft. and System Arch. pp. 5–11 (2004) 16. Mancini, E.P., Rak, M., Villano, U.: Predictive autonomicity of web services in MAWeS framework. Journal of Comp. Science 2, 513–520 (2006) 17. Casola, V., Mazzeo, A., Mazzocca, N., Vittorini, V.: A security metric for public key infrastructures. Journal of Computer Security 15(2) (2007) 18. Whitepaper: Security in a web services world: A proposed architecture and roadmap (2002) 19. Atkinson, B., et al.: Ws-security specification, web services security ver. 1.0 (2002) 20. Mancini, E.P., Rak, M., Villano, U.: Autonomic service oriented architectures with mawes. To be published in Journal of Autonomic and Trusted Computing, American Scientific Publishers (2007) 21. Casola, V., Coppolino, L., Rak, M.: An architectural model for trusted domains in web services. Journal of Information Assurance and Security 1(2) (2006)
