Formal modeling and analysis of XML firewall for service-oriented systems

Transcription

1 Int. J. Secrity and Networks, Vol. 3, No. 3, Formal modeling and analysis of XML firewall for service-oriented systems Haiping X*, Mihir Ayachit and Ahinay Reddyreddy Compter and Information Science Department, University of Massachsetts Dartmoth, North Dartmoth, MA 02747, USA {h, g_mayachit, g_areddyreddy}@massd.ed *Corresponding athor Astract: As more sinesses deploy we services over the Internet, the isse of how to secre them from intrders and possile threats ecomes more important. Firewalls have een designed as a major component to protect a network or a server from eing attacked. However, since conventional firewalls emphasize on packet filtering at the transport and session layer, rather than verifying ser permissions and eamining packet contents at the application layer, they are not sitale for protecting service providers from nathorized we service invocations. In this paper, we propose a formal XML firewall secrity model sing role-ased access control (RBAC) mechanisms. Or proposed formal model spports ser athentication and role-ased ser athorization according to policy rles stored in a policy dataase that can e pdated dynamically. The formal model is designed compositionally sing colored Petri nets (CPN), which can serve as a high-level design for XML firewall implementation. The major components of or compositional XML firewall secrity model are the application model and the XML firewall model. We analyze the application model and the XML firewall model separately sing an eisting Petri net tool, and demonstrate how key properties of or formal models can e verified, and how a design error can e detected and corrected at an early design stage. Keywords: XML firewall, we services, service-oriented systems, role-ased access control (RBAC), colored Petri net (CPN), formal verification. Reference to this paper shold e made as follows: X, H., Ayachit, M., and Reddyreddy, A. (2008) Formal modeling and analysis of XML firewall for service-oriented systems, Int. J. Secrity and Networks, Vol. 3, No. 3, pp Biographical notes: Haiping X received the Ph.D. degree in compter science from the University of Illinois at Chicago in He is an assistant professor in the Compter and Information Science Department at the University of Massachsetts Dartmoth, where he is a co-director of the Concrrent Software Systems Laoratory. His research interests inclde distrited software engineering, formal methods, Internet secrity, mlti-agent systems, and service-oriented systems. He is a memer of the ACM and the IEEE Compter Society. Mihir Ayachit received the M.S. degree in compter science from the University of Massachsetts Dartmoth in He is crrently a software engineer in Parametric Technology Corporation. His research interests inclde we services secrity, formal methods, and model-ased software development. Ahinay Reddyreddy is crrently a gradate stdent in the Compter and Information Science Department at the University of Massachsetts Dartmoth. His research interests inclde we services secrity and formal methods for specification and analysis of concrrent and distrited software, especially the application of Petri net-ased models. 1 RODUCTION We services provide a standardized way that spport interoperale machine to machine interaction over the Internet (Booth et al., 2004). We services are XML ased software components that can e dynamically incorporated into different applications sing remote method invocation mechanisms, sch as JAX-RPC (Java API for XML-ased RPC) (Nagappan et al., 2003) and WSIF (We Service Invocation Framework) (Jric, 2006). A we service is designed as a loosely copled software component that can e descried sing WSDL (We Services Description Langage), registered sing UDDI (Universal Description, Discovery and Integration), and invoked sing standard protocols, sch as SOAP (Simple Oject Access Protocol) that is ond to standard nderlying protocols, e.g., HTTP. Copyright 2008 Inderscience Enterprises Ltd.

2 2 H. XU ET AL As more sinesses deploy we services over the Internet that dynamically interact with varios applications and data sorces, the isse of how to secre them from intrders and possile threats ecomes more important (Mysore, 2003). Secrity prolems in we services are severe ecase the Internet is a plic network infrastrctre, where the information availale to e accessed over the Internet has different levels of siness confidentiality. Frthermore, a service consmer may invoke we services sing false identity, access we services with insfficient permissions, or corrpt we services y attacking the service providers (e.g., sing an XML message-ased denial of service attack). Ths, secrity consideration ecomes very critical for the sccessfl deployment of service-oriented systems. A conventional firewall typically resides at the perimeter of a network server or a siness s private network, and monitors the data traffic entering and eiting the network to prevent nathorized access to the server or the network. Typical types of conventional firewalls inclde package filtering firewalls, application-level gateways, and statefl inspection firewalls (Pfleeger and Pfleeger, 2003; Fernandez et al., 2005). However, a conventional firewall may provide no secrity at all for we services. This is ecase most of the we services are SOAP ased or simply XML ased, which is ond to HTTP; ths, XML messages can most likely pass throgh port 80, the defalt we port, which is normally not locked y a conventional firewall (Windley, 2003). Frthermore, a potential intrder can inclde malicios SOAP attachments, insert harmfl SQL code or eectale commands into an XML packet, or send an etremely large XML packet to overload the XML parser on the service provider side (Moradian and Håkansson, 2006; Voroiev and Han, 2006). A conventional firewall sally does not eamine the content of a packet; ths, it is not ale to identify threats sch as SQL injection, denial of service, schema poisoning, and XML parameter poisoning (Gralla, 2007; Voroiev and Han, 2006). For eample, a packet with XML data tampered with an SQL injection attack that can erase a whole dataase cannot e detected sing packet filtering techniqes; instead, it can only e detected y content filtering approaches. Hence, conventional firewalls are not sfficient to provide secrity for we services. In addition, conventional firewalls sally eist at the transport and session layer, rather than the application layer and within the data packet or content (Wrenn, 2004); therefore, secrity holes can e left to allow an nathorized person to attack a service provider y accessing we services withot needed permissions. To protect we services from eing attacked, we develop a compositional formal model, called XML firewall secrity model, which enforces access restrictions for we service invocations. Or secrity model is derived from a general XML firewall model presented in (Ayachit and X, 2006). In or proposed model, the access to we services is only granted to those sers, who are athenticated and athorized to have access to the services. The model is formally defined sing the Petri net formalism, which is a matre formalism with eisting theory and tool spport (Mrata, 1989). There are two key components in the XML firewall secrity model, namely, the application model and the XML firewall model. In the XML firewall model, we adopt the role-ased access control (RBAC) mechanism (Feinstein et al., 1996) in order to effectively deploy ser athorization and access rights. The role-ased access control mechanism we se in or model is statefl. In other words, role assignment and permission granting in XML firewall depend not only on a ser s identity, t also on the crrent state of the system. The rest of the paper is organized as follows. Section 2 smmarizes the related work. Section 3 presents an architectral design of XML firewall protected serviceoriented systems. Section 4 introdces the compositional Petri net ased XML firewall secrity model, inclding the application model and the XML firewall model. Section 5 performs some formal analysis of the Petri net models sing an eisting Petri net tool. Section 6 gives the conclsions and ftre work. 2 RELATED WORK A closely related work to or proposed XML firewall approach is the role-ased access control (RBAC) mechanism. The role-ased access control model has een sed as one of the most attractive soltions to providing secrity featres in different distrited compting infrastrctre (Feinstein et al., 1996). In an RBAC model, sers are assigned roles with permissions, which ensre that only athorized sers are given access to certain data or resorces. A principle motivation ehind RBAC is the aility to specify and enforce enterprise specific secrity policies sch that it can map natrally to an organization s strctre. Since in a typical organization, ser and role associations change more freqently than role and permission associations, RBAC reslts in redced administrative costs as compared to associating sers directly with permissions. In an RBAC model, a ser is a hman eing or a process within a system; while a role defines a collection of permissions associated with a certain jo fnction within an organization. A permission of a role is an access mode that can e eercised on a particlar oject or a resorce in the system. A ser can e related to possily many roles sing sessions, which specify the drations of valid role assignments. Most of the RBAC models follow the same asic strctre of sject, role and privilege. However, in a more sophisticated role-ased access control model, access decisions for an application will depend on the comination of the reqired credentials of sers and the contet and state of the system, as well as other factors sch as relationship, time and location (Zhang and Parashar, 2004). Giri and Iglio proposed a role-ased access control model that provided special mechanisms for the definition of content-ased access control policies (Giri and Iglio, 1997). By etending the notion of permission, they allowed the specification of secrity policies, in which the permission of an oject may depend on the content of

3 FORMAL MODELING AND ANALSYIS OF XML FIREWALL FOR SERVICE-ORIENTED SYSTEMS 3 the oject itself. Althogh mch work has een done in the area of access control, most of the work is ser-centric, where only credentials of the ser are considered when granting access permissions. Very little work has een done to comine contet information with credentials while access control decisions are eing made. In or XML firewall model, we comine the traditional RBAC with the state information to determine access control; ths, or approach can e more fleile and effective in dynamic permission assignments. Previos work on how to protect we service providers from eing attacked is rare. Fernandez and his colleages proposed to protect we services from nathorized access y developing a pattern-ased langage for XML firewall (Fernandez, 2004; Fernandez et al., 2005). They designed two patterns for XML firewall, namely the secrity assertion coordination pattern sing role-ased access control (RBAC) for access to distrited resorces, and a filter pattern for filtering XML messages or docments according to instittion policies. Althogh their approach provides sefl insights aot implementation of XML firewalls, the XML firewall model they proposed is not formally defined. Cremonini and his colleages proposed an XML-ased approach to comining firewalls and we services secrity specification (Cremonini et al., 2003). They discssed aot the secrity reqirements of we service architectre (WSA), and presented some possile design gidelines for semantics-aware firewalls that can e flly integrated within the WSA. However, technical details aot implementation of their approach are still missing. More recently, Moradian and Håkansson smmarized possile attacks on XML we services, inclding SQL injection, IP spoofing, and denial of service attacks (Moradian and Håkansson, 2006). Bt no soltions are proposed to protect the service providers from service-ased attacks. Different from the aove approaches, we propose a statefl XML firewall secrity model that spports dynamic role assignment and permission granting. Frthermore, since an XML firewall represents one of the critical components in a siness application, to ensre a correct design, we develop a formal model sing colored Petri nets (Jensen, 1992), and demonstrate how eisting Petri net tools can e sed to verify the key properties of or net model. Some XML firewall related prodcts are crrently availale on the market for secring we services applications. For eample, the Form Systems Company developed an XML secrity appliance, called XWall, which resides in front of servers that contain sensitive XML tagged information (Allen, 2006). The appliance encrypts XML fields in real time, as the data goes into the server. It then decrypts it when the data eits the server. The appliance is niqe as it eamines data on a tag-y-tag asis, and therefore does not encrypt the nnecessary or non-critical fields. Another implementation of the XML firewall is the DataPowerXS40 XML Secrity Gateway (DataPower, 2006). This firewall reqires the creation of a virtal firewall for every service eposed to the otside world, which then forms a path throgh the firewall to the ack-end server spplying the we services. Each virtal firewall is configred with a cstom firewall policy of actions on each XML message passing throgh the firewall. Policy actions are implemented throgh XSL style sheets and may inclde XML filtering, digital signatres, signatre verification, schema validation, encryption, decryption, transformation and roting. XML firewall vendors, as a whole, are a mi of startp companies and older secrity companies looking to enter the market. Althogh the aove implementations contain certain XML firewall featres and can help to protect we services, their fnctionalities are still very limited. For eample, they do not spport verification of ser athorization, and ths, nathorized ser may access we services with insfficient permissions. In addition, eisting XML firewall approaches are sally not state-ased, so they cannot protect we services from certain threats sch as a denial of service attack. In contrast, we propose a general soltion to implementing XML firewalls that spports state-ased ser athentication and athorization. More importantly, or XML firewall model is formally defined sing the Petri net formalism, so it spports formal verification for ensring a correct design (e.g., deadlock-freeness), as done in or previos work (X and Shatz, 2003a; X et al., 2005). Some additional related work along this direction incldes X and Nygard s work, where a threat-driven model is developed sing aspect-oriented Petri nets (X and Nygard, 2005; X and Nygard, 2006). Their approach spports incremental modeling of secrity featres to improve trstworthy of software design. Different form the aove threat-oriented approach, we take a property-oriented approach to secrity where secrity featres are eplicitly defined in or model. Frthermore, or proposed formal model can serve as a high-level design for XML firewall implementation, and may provide a potential soltion to atomated software development as illstrated in (X and Shatz, 2003). 3 ARCHITECTURAL DESIGN An XML firewall protected service-oriented system consists of three major types of components, namely application, XML firewall, and we service. The system architectre of a service-oriented system with a single XML firewall installed is illstrated in Figre 1. As shown in the figre, a service provider may deploy a grop of we services on a we server, which is protected y an XML firewall. The we services can e invoked y varios applications at rntime, so the we services shall e ale to interact with different applications concrrently. Meanwhile, an application is allowed to make mltiple reqests to we services that are protected y the same XML firewall at the same time. Therefore, the XML firewall mst spport processing of varios we service invocation reqests concrrently. In Figre 1, we illstrate two applications that may interact with the same grop of we services concrrently. It is worth to e noted that an application can also interact

4 4 H. XU ET AL with different grops of we services, which are deployed y different service providers protected y their own XML firewalls (this scenario is not shown in Figre 1). At the application side, a ser interacts with an application throgh its ser interface. The application logic is the siness logic of an application, which varies from application to application. The application logic processes the reqests from the ser, and initiates service calls that may invoke a single we service or a grop of we services at the same time. The reqest from the application is checked y the XML firewall for athenticity and access limitations depending on state information stored in the StateDB dataase. If the reqest is valid, the XML firewall will pass the reqest to the corresponding we service; otherwise, the reqest is rejected. The administrator of an XML firewall can change the policies stored in a policy dataase throgh an administration modle at rntime. Activities of changing policies inclde adding a new policy, modifying an eisting policy, and deleting a policy that is no longer needed. Each we service has its own logic to process the corresponding method reqest, and retrns the reslt to the XML firewall. Upon receiving the reslt from a we service, the XML firewall then passes the reslt to the application. When the application receives the reslt from the XML firewall, the application logic processes the reslt for frther comptation, and will send appropriate messages to the ser throgh its ser interface. The refinement of the XML firewall modle in a service-oriented system is illstrated in Figre 2, which descries the important components inside an XML firewall modle. As shown in Figre 2, to start an application, a ser first needs to log into the application. If the ser is a valid one, the application logic will process the ser s access reqests, and ased on the ser s reqests, the application logic initiates the needed service calls. A service call with the ser s information is intercepted y the XML firewall for athentication and athorization. The ser is athenticated y checking against certified ser information stored in a dataase, called UserInfoDB, as shown in Figre 2. If the ser s identification is valid, he is assigned a role defined in the Role dataase (i.e., RoleDB); otherwise, an access denied message is sent to the application. The role assignment is ased on the system state inclding the ser s crrent state, which is determined y the stats of the incoming message as well as the information stored in the StateDB dataase. After the role assignment process is completed, a ser space, which contains a session and access permissions of the ser, is created ased on policies from the PolicyDB dataase. The ser space is then compared with the service reqest to determine whether the incoming reqest from the ser has permissions to invoke a we service; meanwhile, the incoming message is inspected for any malicios contents within the ser space. If the ser has the needed permissions, and the XML-ased message does not contain any malicios contents, the we service reqest will e dispatched to the corresponding we service y the XML firewall; otherwise, an access denied message will e sent to the application. If the we service reqest is a valid one, the we service will process the reqest, and retrn the reslt to the XML firewall, which is then passed ack to the application. Application Logic User Login Application [valid ser] athentication [invalid] Assign Role [valid] Create User Space XML Firewall UserInfoDB RoleDB StateDB PolicyDB We Service 1 message inspection Figre 2 Refinement of the XML firewall modle in Figre 1 4 CPN-BASED COMPOSITIONAL XML FIREWALL SECURITY MODEL Petri nets are a well-fonded process modeling techniqe that has formal semantics to allow specification, design, verification, and simlation of a system (Mrata, 1989). Petri nets have een widely sed to model and analyze varios types of processes and systems inclding secrity [access passed] Access Reqest Invoke Service [access denied] Retrn Reslts We Service n User A User Interface Application Logic Application_1 (Service Consmer) Internet (SOAP, HTTP, etc.) XML Firewall Reqest Response Reqest Response We Service 1 We Service n User B User Interface Application Logic Application_2 (Service Consmer) StateDB Update Policy Administration Service Provider Admin Figre 1 XML firewall protected service-oriented system

5 FORMAL MODELING AND ANALSYIS OF XML FIREWALL FOR SERVICE-ORIENTED SYSTEMS 5 protocols (Borolet et al., 2004), we services (Hamadi and Benatallah, 2003; Li and Chen, 2005), manfactring systems (Tomodge, 1995; Jalilvand and Khanmohammadi, 2004), and siness processes (Aalst, 2002). A Petri net is a directed, connected, and ipartite graph, in which each node is either a place or a transition. In a Petri net model, tokens are sed to specify information or conditions in the places. When there is at least one token in every inpt place of a transition, the transition is enaled. An enaled transition can e fired y removing one token from every inpt place, and depositing one token in each otpt place of the transition. Colored Petri nets (CPN or CP-net) are an etension of ordinary Petri nets, which allow different vales (represented y different colors) for the tokens (Jensen, 1992; Jensen and Rozenerg, 1991). Colored Petri nets have a formal synta and semantics that leads to compact models of rather comple systems for modlar design and analysis (Christensen and Petrcci, 1992; Jensen, 1998). In addition, a CPN allows associating gards and eectale code written in a high-level programming langage the ML langage (Clack et al., 1993) with a transition. The modeling and analysis of CPN models are spported y powerfl Petri net tools, sch as the CPN Tools (Ratzer et al., 2003). Petri nets are a graphical and mathematical modeling tool applicale to many systems. In this section, we develop a compositional XML firewall secrity model for we services invocation sing CPN. As mentioned previosly, we design or XML firewall protected service oriented system modlarly with the asic components, i.e., the application modle and the XML firewall modle, where the interfaces etween these modles are well defined. In or CPN models, we introdce a few types of tokens that denote the different types of inpts and otpts of transitions. For eample, if a transition reslts in a Boolean decision, a token will e placed at the otpt place of the transition. In addition, we associate gards with some transitions to model the decision making processes. 4.1 Application model An application invokes we services according to its application logic, which may involve concrrency. Figre 3 shows a CPN model for an application that invokes two we services concrrently. We assme the we services are deployed on different we hosts, so they mst e protected y different XML firewalls. The two we services are represented y two astract transitions WS_Logic1 and WS_Logic2 (denoted y oes with thicker order line in Figre 3). An astract transition is a high-level transition that represents an activity, which can e refined in a more detailed design. The refinement of an astract transition into a new Petri net is eyond the scope of this paper, t it can e modeled as a sstittion transition that stands for a CPN modle in a hierarchical net strctre spported y the CPN Tools (Ratzer et al., 2003; Jensen et al., 2006). In Figre 3, the XML firewall modle is astracted into a snet with a few places and transitions (enclosed in a dashed line o in Figre 3), which will e refined into a more detailed design in Section 4.2. An XML firewall can e sed to protect one or a grop of we services deployed on a we server (only one we service is shown in Figre 3 ehind each XML firewall). We services are invoked y varios applications according User_DB 1 1`e 1`e Login_Reqest Get_Login_Reqest Username_Pass Check_UserDB N1 Valid 1 1`1 1`1 Access_Denied [=false] [=tre] [=false] otpt (); Ready_To_ Accept_Req Failre Not_Valid XML Firewall 1 Logot WS_Reqest1 XML_FW1 User_Reqest 1 1`1 Dispatch_Reqest XML Firewall 2 Accept_Reqest WS_Reqest2 XML_FW2 Create_Reqest Reqest_Details Application_Logic Init_Reslt 1 1`1 N2 Done_Checking1 Done_Checking2 [=tre] Get_User_Details User_Details [=tre] Req_for_WS1 [=false] Access_Denied1 [=tre] Req_for_WS2 [=false] Access_Denied2 otpt (); action(1); colorset = nit with e; colorset = ool; colorset = int; var : ; var : ; var : ; WS_Req1 otpt(); action(1); WS_Logic1 otpt(); action(1); FW_Reslt1 otpt(); action(1); WS_Req2 WS_Logic2 otpt(); action(1); FW_Reslt2 Accept_Reslt Figre 3 CPN model of an application that invokes two we services

6 6 H. XU ET AL to sers access reqests. To protect oth the application and the we services, a ser is reqired to provide his credentials (e.g., ser name and password) when he logs into the application. This is represented y a token (denoted as 1`1 in Figre 3, meaning one token with vale 1) placed in the Login_Reqest place. The token is passed to the Username_Pass place when the Get_Login_Reqest transition fires. The checking of the sername and password is done y firing the transition Check_UserDB, which verifies a ser s identity with the information of certified sers stored in a dataase called User_DB. Note that the information stored in the dataase User_DB is represented y a nit token denoted as 1`e in Figre 3. A failre reslt from the athentication process indicates that the ser is not a valid one, so a Boolean token false will e deposited into place N1, which enales the transition Not_Valid. Note that the gard [=false] associated with the transition Not_Valid evalates to tre when a false token is present in place N1. The firings of the transitions Not_Valid and Access_Denied seqentially will inform the ser that the access to the application was denied, and a token will e retrned to the Login_Reqest place. On the other hand, if the ser is verified as a valid one after firing the transition Check_UserDB, a Boolean token tre will e deposited into place N1, which enales the transition Valid. The firing of transition Valid deposits a token in oth of the places N2 and Ready_To_Accept_Req. A token in place N2 enales the transition Get_User_Details that can fetch a ser s detailed information from the User_DB dataase, and deposit a token into place User_Details. Meanwhile, a token in place Ready_To_Accept_Req enales oth of the transitions Accept_Reqest and Logot to allow an access reqest to we services and a logot reqest, respectively. Note that althogh there is an initial token in place User_Reqest that represents a reqest from the ser, the transition Accept_Reqest cannot fire ntil a token is present in place Ready_To_Accept_Req, which indicates that the ser s athentication check has een passed, and ths, any reqests from the ser can now e processed. As a reslt of firing the Accept_Reqest transition, a token is deposited into the Dispatch_Reqest place for frther processing. If the ser reqest is a logot reqest, then the Logot transition will fire. If the Logot transition fires, the tokens in the three places Ready_To_Accept_Req, User_Details, and Dispatch_Reqest are removed, and a new token is retrned to the initial place Login_Reqest and the place User_Reqest. Since there is no token in the Ready_To_Accept_Req place now, a ser mst login again efore he can make any frther reqests. If the reqest made y the ser is an access reqest to we services, the Create_Reqest transition can fire, and a token will e deposited into the Reqest_Details place. A token in the Reqest_Details place contains the information retrieved from the User_Details place comined with the information from the incoming ser reqest. This enales the Application_Logic transition representing the siness logic of the application. Note that the Application_Logic transition is defined as an astract transition that can e refined into a detailed design according to the actal fnctionalities of the application. When the transition Application_Logic fires, the application applies its siness logic to the incoming reqest, and generates reqests for we services invocation. To illstrate concrrent invocations of two we services, the CPN model contains two we services that are protected y two different XML firewalls. To simplify matters, we assme that the ser has to wait for oth of the reslts retrned from the we service invocations efore any frther reqests can e processed. The goal of the XML firewall is to perform the athentication and athorization activities for incoming ser reqests from an application. If the ser is athorized and has the needed permissions to access a we service, then the we service is invoked. This logic is shown in Figre 3 sing the XML_FW1 and XML_FW2 transition for XML Firewall 1 and XML Firewall 2, respectively. If the ser reqest is athentic, and the ser has all the necessary permissions to invoke a we service protected y an XML firewall, a tre token will e deposited into its Done_Checking place (Done_Checking1 or Done_Checking2), which enales the corresponding Req_for_WS transition (representing the action of reqest for we services). If the transition Req_for_WS fires, a token representing this reqest will e deposited into place WS_Req (We Service Reqest), and enales the corresponding WS_Logic transition that is defined as an astract transition for the we service logic. After processing the reqest y a we service, a token representing the reslt will e placed in the corresponding FW_Reslt place. On the other hand, if the we service access is denied, the corresponding Access_Denied transition fires, and a token representing an access denied message is placed in the FW_Reslt place. When there is a token in oth of the FW_Reslt1 and FW_Reslt2 place, the Accept_Reslt transition in the application modle can fire. Once the reslt is accepted, a token is deposited into the Init_Reslt place, which implies the availaility of the retrn reslts from the we services. This enales the Application_logic transition, and the retrn reslts can now e sed y the Application_Logic transition for frther processing. When the Application_Logic transition fires, any needed comptations are performed, and a token is retrned to the User_Reqest place, which enales a new ser access reqest. 4.2 XML firewall model In Figre 3, the XML firewalls are designed as compositional modles (displayed inside the dashed line oes) that have well-defined interfaces with oth of applications and we services. The XML firewall modle in Figre 3 can now e refined into a more detailed design as shown in Figre 4. To make the CPN model of an XML firewall self-contained, we have shown an astraction of the application modle with two places (i.e., User_Reqest and Init_Reslt_1) and two transitions (i.e., Application_Logic and Accept_Reslt) in Figre 4. In addition, we also inclde

7 FORMAL MODELING AND ANALSYIS OF XML FIREWALL FOR SERVICE-ORIENTED SYSTEMS 7 an astract we service modle that is represented y the astract transition WS_Logic. Note that different from Figre 3, we only show one XML firewall in Figre 4; however, de to the compositional modlar design of or net model, it is straightforward to etend the CPN model in Figre 4 into a system that incldes two XML firewalls as shown in Figre 3. As we discssed earlier, the application logic in an application handles all the incoming reqests coming from the ser and invokes the corresponding we services. In Figre 4, when the Application_Logic generates a we service invocation reqest, a token is placed into the WS_Reqest place indicating a we service invocation. The Check_If_Eisting transition is enaled, and can fire to check if the ser, who makes the reqest, is an eisting ser or a new one. If the ser s identity is not fond in the dataase UserInfo_DB, then the ser is recognized as a first time ser, and a false token is deposited into place N1, which enales the transition First_Time_User. For each first time ser, the PerformBG_Check transition is fired, and a ackgrond check is performed according to sers ackgrond information stored in dataase BG_DB. A ser ecomes a valid memer if the ackgrond check is passed, and a token is deposited into place Valid_User. Then the Update_DBs transition mst fire to pdate the ser information dataase UserInfo_DB as well as the role information dataase Role_DB. Meanwhile, a token is deposited into place Valid_User_Req indicating the crrent reqest is from a valid ser. On the other hand, if the ser athentication fails, the Check_Failed transition is fired, and a token indicating access denied is deposited into the FW_Reslt_1 place. A ser is identified as a reglar ser if his ser profile eists in the UserInfo_DB dataase. For a reglar ser, the Eisting_User transition is fired, and a token is deposited into the Valid_User_Req place. Once a token is present in the Valid_User_Req place, the athorization process can start y firing the Start_Athorization transition. The state information for the incoming reqest is generated y firing the Fetch_State_Info transition, which ses state information that is already stored in the dataase State_DB, as well as information etracted from the incoming reqest message (e.g., the time of the reqest). After the state information is generated, a token indicating the crrent state of the reqest is placed into the State_Info place. The Assign_Role transition is now enaled and can fire to assign roles to the ser according to information stored in the dataases UserInfo_DB and Role_DB. In addition, a ser session is created y firing the Create_Session transition. The ser session defines the period of time dring which, a ser can interact with an application when invoking a we service. If the session epires dring an invocation (the session information will e passed along with a ser space token to the WS_Logic transition as descried later), the WS_Logic transition retrns a timeot reslt to the XML firewall, so a new we service invocation reqest needs to e placed. The net task is to fetch a policy from the Policy_DB. The Fetch_Policy transition can fire when there WS_Reqest Application 1 1`1 User_Reqest Appication_Logic 2 2`1 Init_Reslt_1 Accept_Reslt [=false] otpt (); Check_If_Eisting [=false] N1 First_Time_User N2 PerformBG_Check N3 Check_Failed Eisting_User [=tre] otpt (); FW_Reslt_1 Access_Denied otpt (); BG_DB [=tre] Check_Passed Update_StateDB FW_Reslt WS_Logic WS_Req Pass 1 1`e Valid_User_Req Acess_Failed UserInfo_DB Update_DBs otpt (); 1 1`e 1`e Valid_User otpt (); [=false] Fail [=tre] Role_DB Start_Athorization 1 1`e Access_Req Insp_Reslt Mesg_Inspection otpt (); User_Info Create_Session Session Assign_Role N5 N4 User_Space State_Info Create_UserSpace User_Role Fetch_Policy User_Perm Fetch_State_Info State_DB Policy_DB 1`e 1`e 1 1`e 1`e colorset = nit with e; colorset = ool; colorset = int; var : ; var : ; var : ; 1 1`1 Add_Policy_Req Comp_Logic Init_Reslt_2 1 1`1 1`1 New_Policy [=false] Reject_Policy Check_Conflict Decision Sync [=tre] Accept_Policy 11`e 1`e New_Policy_1 Update_Policy Administration otpt (); otpt (); Figre 4 CPN model of an XML firewall with one application and one we service

8 8 H. XU ET AL is a token in the User_Role place, the State_Info place, and the Sync place. A policy is fetched from the Policy_DB dataase ased on the ser s role and ser s crrent state. After a policy is fetched and a session is created, a ser space is created, which contains the ser information, permissions and the session information. A token representing a ser space will e deposited into the UserSpace place. Note that ideally, oth the session token and the ser space token shold e defined as colored tokens that contain the needed information; however, to simplify or CPN model, we se tokens of type to represent oth sessions and ser spaces. A token in the Access_Req place represents a we service invocation reqest in XML format. The Mesg_Inspection transition can fire in order to check the following two aspects: (1) the entire XML message is scanned in order to discover whether the message contains any malicios contents; (2) the we service invocation reqest is verified if it can e granted within the ser space created according to the ser s role and permissions. A Boolean token representing the reslt will e deposited into the place Insp_Reslt. If the message does not contain any malicios contents, and the ser has the needed permissions to invoke the we service, the Pass transition can fire, and a we service reqest will e dispatched to the corresponding we service. After the we service reqest is processed (i.e., the firing of the WS_Logic transition), a token representing the reslt of the we service invocation is deposited into the FW_Reslt place. This token enales the Update_StateDB transition, which pdates the state information in the dataase State_DB, and also deposits a token in place FW_Reslt_1. On the other hand, if the XML message contains any malicios contents, or the ser does not have sfficient permissions to invoke a we service, the Fail transition fires, and a token is placed into the Access_Failed place. When the transition Access_Denied fires, a token that indicates the we service access is denied is deposited into the FW_Reslt_1 place. From the aove description, we can see that the FW_Reslt_1 place may hold two types of tokens: one representing an access denied message, and another one representing the reslt from we service invocation. With a token in the FW_Reslt_1 place, the transition Accept_Reslt defined in the simplified application modle can fire. As a reslt, a token will e deposited into the Init_Reslt_1 place, and the Application_Logic transition determines the net step of actions. When the Application_Logic transition fires, a token will e retrned to the place User_Reqest, and the CPN model for the XML firewall will go ack to its initial state. Note that in the Init_Reslt_1 place, initially there are two tokens denoted y 2`1. This allows a ser to make two concrrent reqests to we services protected y the same XML firewall, and it reqires that the XML firewall have the capaility of processing more than one we service reqest at the same time. At the ottom of Figre 4, we introdce an Administration snet that models the administration process of adding new policies into the dataase policydb. The astract transition Comp_Logic in Figre 4 represents the comptation logic to captre a ser s reqest for adding a new policy into plicydb. When the transition Comp_Logic fires, a token representing a new policy is deposited into place New_Policy. Then the transition Check_Conflict mst fire to ensre the new policy is consistent with eisting policies stored in the policydb. If there is no conflict etween the new policy and the eisting policies, the new policy will e accepted y firing the transition Accept_Policy, and the PolicyDB is pdated when the transition Update_Policy fires. Otherwise, the Reject_Policy transition fires, and the PolicyDB shall remain nchanged. Notice that we have introdced a synchronization place Sync that initially contains a nit token to synchronize the processes of fetching a policy and pdating the policydb. When the Check_Conflict transition fires, the nit token in place Sync is removed, so the transition Fetch_Policy cannot fire even if there is a token in each of the places User_Role and State_Info. The Fetch_Policy transition can ecome enaled again once the nit token retrns to the Sync place when the PolicyDB has een properly pdated (i.e., when the transition Update_Policy fires). De to the modlar design of or CPN models, or CPN models can e easily etended to spport modelling the activity of modifying or deleting an eisting policy from the PolicyDB. 5 ANALYSIS OF APPLICATION MODEL AND XML FIREWALL MODEL One of the advantages of sing CPN to model XML firewall protected service-oriented systems is de to its spport for formal analysis sing eisting Petri net analysis tools. In this section, we show how to se the CPN Tools (Ratzer et al., 2003) to analyze some key properties of or CPN models. The CPN Tools is a program that spports editing, simlating, and analyzing colored Petri Nets (Jensen et al., 2006). In CPN Tools, a fast simlator is availale for handling oth timed and ntimed Petri nets efficiently. The CPN Tools inclde a state space analysis engine that can generate a fll or partial state space, and prodce a standard state space report containing information sch as ondedness, liveness, and deadlock-freeness properties. The fnctionality of the simlation engine and the state space facilities are developed ased on a previos version of the tool, called Design/CPN (Alert et al., 1989), which is a widespread tool for colored Petri Nets. To verify the correctness of or XML firewall secrity models, we tilize some key definitions for Petri net ehavior properties as adapted from (Mrata, 1989). Definition 5.1 Reachaility: In a Petri net N with initial marking M 0, denoted as (N, M 0 ), a marking M n is said to e reachale from the marking M 0 if there eists a seqence of firings that transforms M 0 to M n. A firing or occrrence seqence is denoted y σ = M 0 t 1 M 1 t 2 M 2 t n M n or simply σ = t 1 t 2 t n. In this case, M n is reachale from M 0 y σ, and we write M 0 [σ > M n.

9 FORMAL MODELING AND ANALSYIS OF XML FIREWALL FOR SERVICE-ORIENTED SYSTEMS 9 Definition 5.2 Bondedness: A Petri net (N, M 0 ), is said to e k-onded or simply onded if the nmer of tokens in each place does not eceed a finite nmer k for any marking reachale from M 0. A Petri net (N, M 0 ) is said to e safe if it is 1-onded. Definition 5.3 Liveness: A Petri net (N, M 0 ), is said to e live if for any marking M that is reachale from M 0, it is possile to ltimately fire any transition of the net y progressing some frther firing seqence. Definition 5.4 Reversiility: A Petri net (N, M 0 ) is said to e reversile if, for each marking M that is reachale from the initial marking M 0, M 0 is reachale from M. Definition 5.5 Home Marking: A marking M home of a Petri net (N, M 0 ) is said to e a home marking if M home can e reached from any reachale marking M n. Definition 5.6 Dead Marking: A marking M dead of a Petri net (N, M 0 ) is said to e a dead marking if, in marking M dead, no transition is enaled in the net. We first inpt or application net model defined in Figre 3 into the CPN Tools. The state space analysis tool prodces the reslts as listed in Tale 1. The analysis reslts in Tale 1 show that the fll state space has een calclated, and the net has an pper ond of 1 (de to space limitation, we only list the ondedness properties of some key places of the application model in the right colmn of Tale 1). This implies that any place in the application net model can contain at most one token at any time, and the net is onded and safe. The reason why the application net model is onded and safe is ecase there is only one token in the Init_Reslt place initially (as shown in Figre 3). Therefore, after the Application_Logic transition fires for the first time, it cannot fire again ntil the reslt of the previos we services invocation retrns. Similarly, the lower ond of a place is the nmer of tokens that the place mst contain at any time. For eample, the lower ond of place User_DB is 1, ths the place User_DB mst contain at least one token at any time. The home properties in Tale 1 shows that all markings, inclding the initial marking M 0, are home markings. According to Definition 5.5, a home marking M home can e reached from any reachale marking; ths, at any time, the initial marking M 0 can e reached y progressing some frther firing seqence. This proves that the application CPN model is reversile, and the net can always retrn to its initial state withot leaving residal tokens in the net. Since the initial marking M 0 represents that there are no we service reqests eing processed at the net, the reversiility property indicates that every we service reqest can e processed sccessflly. The analysis reslts tell s that there are no dead markings in or net model, and all transitions are live. Since a live transition means, from any reachale marking, we can always find a firing seqence containing the transition, according to Definition 5.3, or net model is live. Ths, for any marking M that is reachale from M 0, it is possile to ltimately fire any transition of the net. As a conseqence, as long as there are valid ser reqests with the needed permissions, oth the WS_Logic1 and WS_Logic2 transition can fire eventally. The analysis reslts also show that there are no dead transitions. A transition is dead if, in all reachale markings, the transition is not enaled. Dead transitions correspond to parts of the model that can never e activated, and they can e removed from the model withot changing the model ehaviors (Jensen et al., 2006). Therefore, or analysis reslt proves that all transitions in or net model can e activated eventally. Similarly, we inpt or XML firewall net model defined in Figre 4 into the CPN Tools, the state space analysis tool prodces the reslts as listed in Tale 2. The analysis reslts Tale 1 Analysis reslts of the CPN application model in Figre 3 Statistics State Space Nodes: 260 Arcs: 823 Secs: 0 Stats: Fll Home Properties Home Markings All Liveness Properties Dead Markings None Dead Transition Instances None Live Transition Instances All Bondedness Properties Best Integer Bonds Upper Lower Dispatch_Reqest 1 0 Done_Checking1 1 0 Done_Checking2 1 0 FW_Reslt1 1 0 FW_Reslt2 1 0 Failre 1 0 Init_Reslt 1 0 Login_Reqest 1 0 Ready_To_Accept_Req 1 0 Reqest_Details 1 0 User_DB 1 1 User_Details 1 0 User_Reqest 1 0 Username_Pass 1 0 WS_Req1 1 0 WS_Req2 1 0 WS_Reqest1 1 0 WS_Reqest2 1 0

10 10 H. XU ET AL show that or net model is 2-onded. Since there are two tokens in the Init_Reslt_1 place of the application model initially, we epect that there can e at most two tokens in the WS_Reqest place, which represent two concrrent we service reqests. This is proved y the pper ond of 2 in the WS_Reqest place as shown in Tale 2. Similarly, the pper ond of 2 in the WS_Req place shows that two concrrent we service reqests can actally e made if the ser has passed the athentication, and has the needed permissions. From the home properties of the net model as shown in Tale 2, we find that there is only one home making, which has the node nmer Since the node nmer of the initial marking M 0 is always 1, the reslt shows that the Tale 2 Analysis reslts of the CPN model in Figre 4 Statistics State Space Nodes: 2065 Arcs: 6740 Secs: 2 Stats: Fll Home Properties Home Markings [1604] Liveness Properties Dead Markings [1604] Dead Transition Instances None Live Transition Instances None Bondedness Properties Best Integer Bonds Upper Lower Access_Req 2 0 Acess_Failed 2 0 Add_Policy_Req 1 1 Decision 1 0 FW_Reslt 2 0 FW_Reslt_1 2 0 Init_Reslt_1 2 0 Init_Reslt_2 1 0 Insp_Reslt 2 0 New_Policy 1 0 New_Policy_1 1 0 Session 2 0 State_Info 2 0 Sync 1 0 User_Info 2 0 User_Perm 2 0 User_Reqest 1 1 User_Role 2 0 User_Space 2 0 Valid_User 2 0 Valid_User_Req 2 0 WS_Req 2 0 WS_Reqest 2 0 Figre 5 State space tracing of the dead marking state M 1603 (i.e., Node 1604)

11 FORMAL MODELING AND ANALSYIS OF XML FIREWALL FOR SERVICE-ORIENTED SYSTEMS 11 initial marking is not a home marking; ths, the XML firewall net model is not reversile. Frthermore, from the liveness properties, the single home marking (node 1604) is a dead marking. From Definition 5.6, we know that, in a dead marking, no transition is enaled. Therefore, when the net model reaches the dead marking, the net ecomes dead, and cannot process frther y firing any transitions. This indicates a deadlock error in or net model, and the net model is not live. To find ot the case of the deadlock error, we again se the state space analysis tool provided y the CPN Tools to trace the dead marking. As shown in Figre 5, we find the following firing seqence σ that leads to the dead marking, i.e., M 0 [σ > M 1603, where the initial marking M 0 is nmered as node N1, and the dead marking M 1603 is nmered as node N1604. σ = N1, Application_Logic, N2, Application_Logic, N4, Checking_If_Eisting, N10, Checking_If_Eisting, N21, Eisting_User, N42, Eisting_User, N76, Start_Athorization, N129, Start_Athorization, N204, Assign_Role, N303, Assign_Role, N423, Fetch_State_Info, N563, Fetch_State_Info, N715, Comp_Logic, N876, Check_Conflict, N1038, Create_Session, N1186, Reject_Policy, N1341, Create_Session, N1466, Comp_Logic, N1604. By simlating the XML firewall net model according to the firing seqence σ, it is easy to see that the eistence of the dead marking M 1603 (N1604) is de to the firing of the transition Check_Conflict, which takes away the nit token in place Sync. If the new policy is accepted and the policy dataase has een properly pdated (i.e., when the transition Update_Policy fires), the nit token will e retrned to the Sync place. In this case, the Fetch_Policy transition can fire as long as there are tokens in place State_Info and User_Role. However, if the new policy is rejected (as illstrated in the firing seqence σ), there will e no token retrned to the Sync place; in this case, the transition Fetch_Policy ecomes disaled forever, and ths, a deadlock sitation occrs. The deadlock error can e corrected y adding a new arc from the transition Reject_Policy to place Sync, so a nit token can e retrned to the Sync place when the new policy is rejected. Now we inpt or revised net model into the CPN Tools again, and we get the analysis reslts as listed in Tale 3. From the analysis reslts in Tale 3, we can see that all markings inclding the initial marking are home markings. Ths, or revised XML firewall net model is reversile. Frthermore, there are no dead markings, and all transitions are live. This proves that or revised net model is live. As a reslt, as long as there are valid ser reqests with needed permissions, the WS_Logic transition can fire eventally. Note that the CPN models we have developed in this paper are compositional. This means we can easily develop a CPN model that consists of mltiple applications, mltiple firewalls, and mltiple we services. Since oth of the application model and the revised XML firewall model have een proved to e reversile, onded, and live, de to the modlar design of or formal approach, a compositional model with mltiple applications, firewalls and we services is also reversile, onded, and live. 6 CONCLUSIONS AND FUTURE WORK The secrity isses in service-oriented systems have ecome more and more important. Effective secrity mechanisms are critical for ensring the sccessfl deployment of we services. In this paper, we introdced a compositional CPN model for XML firewall protected service-oriented systems. We sed the colored Petri net formalism ecase it has a distinct advantage of eing easy to nderstand and se de to its graphical notations and powerfl rles for defining Tale 3 Analysis reslts of the revised CPN model in Figre 4 Statistics State Space Nodes: 1475 Arcs: 5135 Secs: 1 Stats: Fll Home Properties Home Markings All Liveness Properties Dead Markings None Dead Transition Instances None Live Transition Instances All Bondedness Properties Best Integer Bonds Upper Lower Access_Req 2 0 Acess_Failed 2 0 Add_Policy_Req 1 1 Decision 1 0 FW_Reslt 2 0 FW_Reslt_1 2 0 Init_Reslt_1 2 0 Init_Reslt_2 1 0 Insp_Reslt 2 0 New_Policy 1 0 New_Policy_1 1 0 Session 2 0 State_Info 2 0 Sync 1 0 User_Info 2 0 User_Perm 2 0 User_Reqest 1 1 User_Role 2 0 User_Space 2 0 Valid_User 2 0 Valid_User_Req 2 0 WS_Req 2 0 WS_Reqest 2 0

12 12 H. XU ET AL system strctre and dynamic ehaviors (Mrata, 1989, Jensen 1992). A colored Petri net provides an eectale model that directly defines the concept of a system s state space. Althogh most research on atomated analysis of concrrent and distrited systems ses some type of statespace eploration approach and cannot avoid the associated state-space eplosion prolem, ased on or significant eperience with Petri nets for many years, the Petri net formalism is capale of achieving an effective alance etween theoretical concepts and practical techniqes. Or proposed model spports secred we services invocation, which only allows ser reqests with needed permissions. The effectiveness of or approach is de to the incorporation of the role-ased access control (RBAC) mechanism into or secrity model, so ser roles and permissions for we services invocation can e assigned dynamically. Althogh there are some eisting implementations of XML firewall with limited fnctionality, or proposed approach provides a etter soltion to protecting service providers, where state-ased ser athentication and athorization are spported eplicitly for we services invocation. More importantly, or XML firewall secrity model is formally defined sing CPN, ths certain ehavioral properties sch as deadlockfreeness can e formally verified. The compositional CPN model we proposed consists of the application model and the XML firewall model, which can e analyzed separately; therefore the state-space eplosion prolem in or formal approach is not significant. To demonstrate the advantages of or formal approach, we sed the CPN Tools to verify some key properties of or net model. Or analysis reslts show that or proposed net model (the revised model) is live and onded, which indicate that or net model is deadlock free and only reqires onded resorces. Different from other eisting work, or approach ensres a correct design of XML firewall, which can serve as a reliale high-level software design for implementation. In or ftre work, we plan to refine or CPN models into a more detailed design sing colored tokens with more semantics sch as sers, their roles, access permissions, and constraints, and show how to implement XML firewalls ased on or proposed formal CPN models. ACKNOWLEDGEMENT This material is ased pon work spported y the Chancellor s Research Fnd and UMass Joseph P. Healey Endowment Grants, and the Research Seed Initiative Grant, College of Engineering, UMass Dartmoth. We thank all anonymos referees for the carefl review of this paper and the many sggestions for improvements they provided. REFERENCES Aalst, W. M. P. van der (2002) Making work flow: on the application of Petri nets to siness process management, In J. Esparza and C. Lakos, editors, Application and Theory of Petri Nets 2002, Vol. 2360, Lectre Notes in Compter Science, pages Springer-Verlag, Berlin, Alert, Ken, Jensen, K., and Shapiro, R. (1989) DESIGN/CPN: a tool package spporting the se of colored nets, Petri Net Newsletter, No. 32, pp Bonn, Germany: Gesellschaft für Informatik (GI), Special Interest Grop on Petri Nets and Related System Models, April Allen, D. (2006) Form Systems XWall We Services Firewall. Retrieved on Ferary 29, 2006, from html?articleid= Ayachit, M. and X, H. (2006) A Petri net ased XML firewall secrity model for we services invocation, Proceedings of the International Conference on Commnication, Network, and Information Secrity (CNIS 2006), Octoer 2006, MIT, Camridge, Massachsetts, USA, pp Booth, D., Haas, H., McCae, F., Newcomer, E., Champion, I. M., Ferris, C., and Orchard, D. (2004) We services architectre, W3C Working Grop Note, Ferary 11, Retrieved on Janary 18, 2007, from Borolet, R., Kladel, H., and Pelz, E. (2004) A semantics of secrity protocol langage (SPL) sing a class of composale high-level Petri nets, Proceedings of the Forth International Conference on Application of Concrrency to System Design (ACSD 04), Christensen, S. and Petrcci, L. (1992) Towards a modlar analysis of colored Petri nets, Proceedings of the 13th International Conference on Application and Theory of Petri Nets (ICATPN-92), In: Jensen, K.: Lectre Notes in Compter Science, Vol. 616, Sheffield, UK, pp Springer- Verlag, Jne Clack, C., Myers, C., and Poon, E. (1993) Programming with Standard ML. Prentice-Hall, Cremonini, M., Vimercati, S. D. C., Damiani, E., Samarati, P. (2003) An XML-ased approach to comine firewalls and we services secrity specifications, Proceedings of the 2003 ACM Workshop on XML Secrity, pp DataPower (2006) WeSphere DataPower SOA Appliances: XS40 XML Secrity Gateway. Retrieved on March 15, 2006, from Feinstein, H., Sandh, R., Coyne, E., and Yoman, C. (1996) Role-ased access control models, IEEE Compter, 29(2):38 47, Fernandez, E. B. (2004) Two patterns for we services secrity, Proceedings of the 2004 International Symposim on We Services and Applications (ISWS'04), Las Vegas, NV, Fernandez, E. B., Larrondo-Petrie, M. M., Seliya, N., Delessy- Gassant, N., and Schmacher, M. (2005) A pattern langage for firewalls, In M. Schmacher, E. B. Fernandez, D. Hyertson, F. Bschmann, and P. Sommerlad (Eds.), Secrity Patterns, Wiley Giri, L. and Iglio, P. (1997) Role templates for content-ased access control, Proceedings of the Second ACM Workshop on Role Based Access Control, Virginia, USA, Gralla, P. (2007) XML Firewalls, The We Services Advisor, Janary 7, Retrieved on Janary 9, 2007, from i855052,00.html Hamadi, R. and Benatallah, B. (2003) A Petri net-ased model for we service composition, Dataase Technologies 2003, Eds. K. D. Schewe, X. Zho, Astralian Compter Science Society Inc., Sydney, Astralia, 2003, pp Jalilvand, A. and Khanmohammadi, S. (2004) Modeling of fleile manfactring systems y timed Petri net, Proceedings of the International Conference on Comptational Intelligence, 2004, pp Jensen, K. and Rozenerg, G. (eds.) (1991) High-level Petri Nets: Theory and Application, New York: Springer-Verlag.

13 FORMAL MODELING AND ANALSYIS OF XML FIREWALL FOR SERVICE-ORIENTED SYSTEMS 13 Jensen, K. (1992) Colored Petri Nets: Basic Concepts, Analysis Methods and Practical Use, Vol. I : Basic Concepts, EATCS Monographs on Theoretical Compter Science, New York Springer-Verlag. Jensen, K. (1998) An introdction to the practical se of colored Petri nets, In W. Reisig and G. Rozenerg (Editors): Lectres on Petri Nets II: Applications, Lectre Notes in Compter Science, Vol. 1492, Springer-Verlag 1998, pp Jensen, K., Kristensen, L. M., and Wells, L. (2006) Colored Petri nets and CPN Tools for modelling and validation of concrrent systems, International Jornal on Software Tools for Technology Transfer. Springer-Verlag, Jric, M. B. (2006) Etending BPEL with WSIF for enterprise application integration, BPEL Cookook: Best Practices for SOA-Based Integration and Composite Applications Development, Packt Plishing, Jly Li, B. and Chen, H. (2005) We service composition and analysis: a Petri-net ased approach, Proceeding of the First International Conference on Semantics, Knowledge and Grid (SKG'05), Moradian, E. and Håkansson, A. (2006) Possile attacks on XML we services, IJCSNS International Jornal of Compter Science and Network Secrity, Vol.6, No.1B, Janary 2006, pp Mrata, T. (1989) Petri nets: properties, analysis and applications, Proceedings of the IEEE, 77(4): , April Mysore, S. (2003) Secring we services - concepts, standards, and reqirements, White Paper, Sn Microsystems, Nagappan, R., Skoczylas, R., and Sriganesh, R. P. (2003) Developing Java We Services, Wiley, Pfleeger, C. P. and Pfleeger, S. L. (2003) Secrity in Compting, 3/e Prentice Hall, Ratzer, A.V., Wells, L., Lassen, H. M., Larsen, M., Qvortrp, J. F., Stissing, M. S., Westergaard, M., Christensen, S., and Jensen, K. (2003) CPN Tools for editing, simlating, and analysing colored Petri nets, Proceedings of the 24th International Conference on the Application and Theory of Petri Nets, Eindhoven, Netherlands, Jne Tomodge, S. (1995) Applications of Petri nets in manfactring systems: modeling, control, and performance analysis, IEEE Control Systems Magazine, Vol. 15, Isse 6, Decemer Voroiev, A. and Han, J. (2006) Secrity attack ontology for we services, Proceedings of the Second International Conference on Semantics, Knowledge, and Grid (SKG'06), 2006, pp. 42. Windley, P. J. (2003) Closing the XML secrity gap, InfoWorld, Octoer 17, Retrieved on Decemer 22, 2006, from Wrenn, G. (2004) Secring we services: a jo for the XML firewall, We Services Tips for XML Developers, March 8, Retrieved on Janary 18, 2007, from i955191,00.html X, D. and Nygard, K. E. (2005) A threat-driven approach to modeling and verifying secre software, Proceedings of the 2005 IEEE/ACM International Conference on Atomated Software Engineering (ASE 05), Novemer 2005, pp X, D. and Nygard, K. E. (2006) Threat-driven modeling and verification of secre software sing aspect-oriented Petri nets, IEEE Transactions on Software Engineering (IEEE TSE), April 2006, Vol. 32, No. 4, pp X, H. and Shatz, S. M. (2003a) A framework for model-ased design of agent-oriented software, IEEE Transactions on Software Engineering (IEEE TSE), Janary 2003, Vol. 29, No. 1, pp X, H. and Shatz, S. M. (2003) ADK: an agent development kit ased on a formal model for mlti-agent systems, Jornal of Atomated Software Engineering (AUSE), Octoer 2003, Vol. 10, No. 4, pp X, H., Zhang, Z., and Shatz, S. M. (2005) A secrity ased model for moile agent software systems, International Jornal of Software Engineering and Knowledge Engineering (IJSEKE), Agst 2005, Vol. 15, No. 4, pp Zhang, G. and Parashar, M. (2004) Contet-aware dynamic access control for pervasive applications, Proceedings of the Commnication Networks and Distrited Systems Modeling and Simlation Conference (CNDS 2004), 2004 Western MltiConference (WMC), San Diego, CA, USA, 2004.