Paintings & Photography

A Petri net based XML firewall security model for web services invocation

Description
A Petri net based XML firewall security model for web services invocation
Published
of 7
All materials on our website are shared by users. If you have any questions about copyright issues, please report us to resolve them. We are always happy to assist you.
Related Documents
Share
Transcript
    A PETRI NET BASED XML FIREWALL SECURITY MODEL FORWEB SERVICES INVOCATION Mihir M. Ayachit and Haiping XuComputer and Information Science DepartmentUniversity of Massachusetts DartmouthNorth Dartmouth, MA 02747Email: {g_mayachit, hxu}@umassd.edu ABSTRACT An XML firewall differs from a conventional firewallbecause its major task is to control access to web servicesrather than to filter untrusted addresses. An XML firewallcan effectively protect web services from being attackedby inspecting a complete XML message including itshead and data segments, and rejecting unauthorized webservices invocation. In this paper, we propose a formalXML firewall security model using role-based accesscontrol (RBAC). Our proposed model supports userauthentication and user authorization according toinformation stored in a user database and a policydatabase associated with an XML firewall. The formalmodel is designed compositionally using Petri nets, whichcan serve as a high-level design for XML firewallimplementation. The key components of ourcompositional security model are the application modeland the XML firewall model. To illustrate the advantagesof our formal approach, we use an existing Petri net toolto verify some key properties of our model, such asboundedness and liveness. KEY   WORDS  XML firewall, web services, role-based access control(RBAC), Petri net model, formal verification 1. Introduction Web services are Internet-based software components thatsupport open, XML-based standards and communicationprotocols. As more businesses deploy web services intoapplications that dynamically interact with otherapplications and data sources, the issue of how to securethem from intruders and other possible threats becomesmore important [1]. Security problems in web services aresevere because the Internet is an insecure and untrustablepublic network infrastructure, where the informationavailable to be accessed over the Internet has differentlevels of business confidentiality. Furthermore, a serviceconsumer may invoke web services using false identity,or corrupt the services by attacking the service providers,for example, using a denial of service attack. Thus,security consideration becomes very critical for thesuccessful deployment of web services applications.Conventional firewalls have been designed as a majorcomponent to protect a network or a server from beingattacked. However, they may provide no security at all forweb services. This is because web services normally usethe SOAP protocol over HTTP, whose port is typicallynot blocked by conventional firewalls. To protect webservices from being attacked, we develop a generalframework, called XML firewall security model, whichenforces access restrictions for web services invocation.In our model, the access to web services is only granted tothose users who are authenticated and authorized to haveaccess to the services. The model is formally definedusing the Petri net formalism, which is a matureformalism with existing theory and tool support [2]. Thereare two types of components in the XML firewall securitymodel, namely, the application model and the XMLfirewall model. In the XML firewall model, we adopt therole-based access control (RBAC) mechanism toeffectively deploy user authorization and access rights.The RBAC model has been proposed as one of the mostattractive solutions to providing security features indifferent distributed computing infrastructure [3]. In anRBAC model, users are assigned roles with permissions,which are access modes that can be exercised on aparticular object in the system. RBAC ensures that onlyauthorized users are given access to certain data orresources. Most of the RBAC models follow the samebasic structure of subject, role and privilege. However, ina more sophisticated role-based access control model,access decisions for an application will depend on thecombination of the required credentials of users and thecontext and state of the system, as well as other factorssuch as relationship, time and location [4]. The RBACmechanism we use in our model depends on not only theuser’s identity, but also the current state of the system. Inour XML firewall, we can define certain policy rules thatspecify the users’ access to the web services based on thesystem state. Thus, our XML firewall model is stateful .There is very little work done in the past on how toprotect web service providers from being attacked.Previous work on protecting web services fromunauthorized access emphasized on developing pattern-   547-034 61  based language for XML firewall [5]. Fernandez and hiscolleagues classified firewalls into three categories,namely, packet filter firewall, proxy-based firewall, andstateful firewall [6]. They proposed two patterns for XMLfirewall, which are security assertion coordination patternusing RBAC for access to distributed resources, and filterpattern for filtering XML messages or documentsaccording to institution policies. Instead of proposingpattern languages for stateless XML firewall, we design astateful XML firewall protected system that may assignpermissions to various roles according to the currentsystem. Furthermore, since XML firewalls are criticalsystems for businesses, to ensure the correctness of thesystem design, we develop a formal model using Petrinets, and demonstrate how existing Petri net tools can beused to verify the key properties of our model.Currently, there are also a few XML firewall productsavailable in the market to secure web services developedby leading companies. For example, the Forum SystemsCompany has an XML security appliance that is acombination of hardware and software and resides in frontof servers that contain sensitive XML tagged information[7]. The appliance encrypts XML fields in real time, asthe data goes into the server. It then decrypts it when thedata exits the server. Although such XML firewallimplementations can help to protect web services, theirfunctionalities are still very limited. For example, they areusually not state-based, so they cannot protect webservices from certain threats such as a denial of serviceattack. In this paper, we propose a general solution toimplementing XML firewalls based on a Petri net basedXML firewall security model, which is formally definedand supports formal verification as we did in our previouswork [8]. Meanwhile, our formal model can serve as ahigh-level design for XML firewall implementation, andmay provide a potential solution to automated softwaredevelopment as illustrated in [9].The rest of the paper is organized as follows. Section 2presents an architectural design of XML firewallprotected systems. Section 3 introduces the compositionalPetri net based XML firewall security model, includingthe application model and the XML firewall model.Section 4 performs some formal analysis of the Petri netmodels using an existing Petri net tool. Section 5 givesthe conclusions and future work. 2. Architectural Design of XML Firewall To deal with security issues in web services invocation,we build an XML firewall security model to protect webservices from threats in an unsecured environment. Suchthreats include unauthorized access and access withoutsufficient permissions. Our approach focuses on buildingthe XML firewall model that coordinates authenticationand access rights. The proposed model for XML firewallscan filter XML messages according to policies enforcedin a policy base associated with each XML firewall.The XML based firewall security model consists of threemajor components: applications, XML firewalls and webservices. The architecture of an XML firewall protectedservice-oriented system is illustrated in Figure 1. Asshown in the figure, a user interacts with the applicationthrough the user interface. The application logic is thebusiness logic inside the application, which varies fromapplication to application. The application logic processesthe requests from the user and initiates service calls. Aservice call can be an invocation of a single web serviceor a group of web services. The request from theapplication is checked by the XML firewall forauthenticity and access limitations depending on thesystem state. If the request is valid, the XML firewall willpass the request to the corresponding web service;otherwise, the request is rejected. The administrator of theXML firewall can change the policies of the firewall atruntime. Each web service has its own logic to process thecorresponding method request and returns the result to theXML firewall. Upon receiving the results from the webservices, the XML firewall passes the results back to theapplication. When the application receives the resultsfrom the XML firewall, the application logic processesthese results and may send appropriate messages to theuser through its user interface . Figure 2 is the refinement of the XML firewall, whichdescribes the important components inside an XMLfirewall model. When a user starts the application, he firstlogs into the application. Then the user’s access requestsare processed by the computational logic. Based on theuser’s requests, the computational logic initiates theneeded service calls. The service call with the user’sinformation is intercepted by the XML firewall forauthentication and authorization. The user is authenticatedby checking against the UserInfo database, i.e., the UserInfoDB as shown in Figure 2. If the user’sidentification is valid, he is assigned a role from the  Role  database, i.e., the  RoleDB ; otherwise, an access denied   message is sent to the application. The role assignment isbased on the current state of the user as well as the state  Application (Service Consumer)  XML Firewall Response Application LogicWeb Service 1 Web Service n   Admin Policy ChangeRequest User Interface … ResponseRequest User Figure 1. Protecting service provider using statefulXML firewall State Info Service Provider  Request 62  User Login Computational Logic [valid user]authenticateuser[valid][invalid] AssignRole UserInfoDB CreateUser Space StateDBPolicyDB AccessRequestInvokeServiceWeb Service 1 Web Service n ReturnResults Figure 2. XML firewall architecture check permissions[accesspassed]RoleDB[accessdenied] …  XML Firewall Application of the system, which is determined by the status of incoming message and the information stored in the State  database, i.e., the StateDB . After the role assignment isdone, a user space is created by using policies from the Policy database (i.e., the PolicyDB ), which contains theaccess permissions of the user. The user space is thencompared with the service request to determine whetherthe incoming request from the user has permissions toinvoke the web service. If the user has the permissions,then the request is passed to the corresponding webservice; otherwise, an access denied  message is sent to theapplication. Upon receiving a request from the XMLfirewall, the web service process the request and returnsthe result to the XML firewall, which is then passed back to the computational logic in the application. 3. Compositional Petri Net Models of XMLFirewall Petri nets are a graphical and mathematical modeling toolapplicable to many systems [2]. A Petri net is a directed,connected, and bipartite graph in which each node iseither a place or a transition. In a Petri net model, tokensare used to specify information or conditions in theplaces. For an ordinary Petri net, when there is at leastone token in every input place of a transition, thetransition is enabled. An enabled transition may fire byremoving one token from every input place, anddepositing one token in each output place of thetransition. In this section, we develop a compositionalXML firewall security model for web services invocationusing Petri nets. As mentioned previously, we design ourXML firewall protected service architecture usingmodular design with the basic modules, i.e., theapplication model and the XML firewall model, where theinterfaces between these modules are well defined. 3.1 Application Model Figure 3 shows the Petri net model of an application thatinvokes two web services concurrently. In the applicationmodel, we assume that a user can log into the applicationby providing his username and password. Once a userprovides his username and password, a token is placed inthe  Login_Request  place. The username and password arethen received by firing Get_Login_Request  transition anda token is deposited into the Username_Password  place.The Check_User_DB transition is fired to check thevalidity of the username and password according to theinformation stored in the User_DB place, which is adatabase that stores details of all registered users, forexample, the user’s contact information. If the usernameand password check is valid, the Get_User_Details  transition is fired and a token is placed in the User_Details place. At the same time, a token isdeposited into the  Ready_To_Accept_Request  place toindicate that now a user access request can be processed.It should be noted that a user could make a request to theapplication only if he is authenticated by the application.If the user fails the authentication check, then   a token isplaced in the Failure place by firing the  Not_Valid   transition. In this case, the transition  Access_Denied  canfire and a token will be returned to the  Login_Request   place. The token placed in the User_Access_Request   place represents a request from the user. The user requestis accepted by firing the  Access_Request  transition. Notethat the  Access_Request  transition can fire only if there isa token in the  Ready_To_Accept_Request  place.   As aresult of firing the Access_Request  transition, a token isdeposited into the  Dispatch_Request  place. If the requestis a logout request, then the  Logout  transition will fire. If the  Logout  transition fires, a token is taken out of the  Ready_To_Accept_Request  place and User_Details place,and a new token is returned back to initial place  Login_Request  . Since there is no token in the  Ready_To_Accept_Request place now, a user must loginagain before he can make further access requests.If the request made by the user is an access request, the Create_Request  transition can fire, and a token will bedeposited into the  Request_Details place. A token in the  Request_Details place contains the information retrievedfrom the User_Details place combined with theinformation from the incoming user request. The token inplace  Request_Details enables the Computational_Logic  transition, which   represents the business logic of theapplication. The Computational_Logic transition isdefined as an abstract transition (denoted as shadedrectangle in Figure 3), which is a unit of module that canbe refined later on. When the transition Computational_Logic fires, the application applies itsbusiness logic to the incoming request and generatesrequests for web services invocation. To illustrate 63  concurrent invocations of two web services, theapplication model includes two web services that areprotected by a XML firewall respectively. To simplifymatters, we assume that the user has to wait for the resultsof both of the requests to be processed before any furtherrequests can be made. Notice that the XML firewallmodel shown in the figure (in a dashed line box) can beused to secure a single or a group of web services. Wewill refine the XML firewall in Section 3.2. The goal of the XML firewall is to perform the authentication andauthorization verification of incoming requests from theapplication. Hence, when the application accepts therequest, the XML firewall performs the authenticationverifications and checks the access rights. If the user is anauthorized user, and if he has the necessary permissions tothe web service that is requested, then the web servicewill be invoked. This logic is represented in the Figure 3as the  XML_FW  transition. By firing the transition  XML_FW  , a token is deposited in place  Done_Checking  for further processing. If the user request is authentic andthe user has all the necessary permissions, the transition  Req_for_WS can fire. When the transition fires, a tokenrepresenting this request will be deposited into place WS_Req , and enables the WS_Logic transition. Thetransition WS_Logic is defined as an abstract transitionthat represents the corresponding web service logic. Afterprocessing the web service, a token representing the resultis deposited into the FW_Result  place. On the other hand,if the web service access is denied, the  Access_Denied   transition fires, and a token representing an access denied   message is placed in the FW_Result  place.Now the Accept_Result  transition in the application canfire if we have a token in the FW_Result  place in both of the XML firewalls. Once the result is accepted, a token isdeposited into the  Init/Result  place,   which can be used by Computational_Logic transition for further processing.After the Computational_Logic transition fires, a token isreturned to the User_Access_Request  place, whichenables the next user access request. 3.2 XML Firewall Model The XML firewall module in Figure 3 (displayed insidethe dashed line box) can be refined as shown in Figure 4.To make the Petri net model self-contained, we haveshown an abstraction of the application model with twoplaces and two transitions. In this model, we also includean abstract web service module that is denoted by theabstract transition WS_Logic .As we discussed earlier, the computational logic in theapplication handles all the incoming requests comingfrom the user and invokes the corresponding webservices. When the Computational_Logic generates a webservice request, a token is placed into the WS_Request   place indicating a method call. The Check_If_Existing  transition can fire in order to check if the user is anexisting user or a new one, where the user who made therequest is checked for identity. If the user is not found inthe UserInfo_ DB, then the user is recognized as a firsttime user and the First_Time_User  transition can fire. Foreach first time user, the Perform_Background_Check    Ready_To_Accept_RequestWS_Logic WS_LogicUser_DBReq_for_WS1Req_for_WS2Dispatch_RequestUser_DetailsCreate_RequestDetailsAccess_RequestLogoutUser_Access_RequestGet_Login_RequestUsername_PasswordCheck_User_DBNot_ValidFailureValidGet_User_DetailsLogin_RequestComputational_LogicXML_FWXML_FWAccess_DeniedAccess_DeniedReq_for_WSReq_for_WSAccept_Result Figure 3. Petri net model of an application that invokes two web services concurrently Request_FW_ResultFW_ResultAccess_DeniedInit/ResultWS_ReqWS_ReqDone_CheckingDone_Checking 64  transition can fire and a background check is performedusing information stored in  BG_Check_DB . A userbecomes a valid member if the background check ispassed. As a result of valid authentication, the Update_Databases transition is fired to update the UserInfo_DB and  Role_DB. Meanwhile, a token isdeposited into the Valid_User_Request  place indicating avalid user request. If the authentication fails, the Check_Failed  transition will fire and a token indicatingaccess denied is placed in the FW_Result  place.The user is identified as a regular user if his user profileexists in the UserInfo_DB database. For a regular user,the  Existing_User  transition can fire and a token isdeposited into the Valid_User_Request  place. Once thetoken is deposited into the Valid_User_Request  place, theauthorization process starts by firing the Start_Authorization transition. The state information forthe incoming request is generated by firing the Fetch_State_Info transition, which uses state informationthat is already stored in the State_DB . Since the incomingrequest may hold state information itself (e.g., the time of the request), the state of the incoming request is computedusing State_DB as well as the status of the incomingrequest. After the state information is generated, a tokenindicating current state of the request is placed in the State_Info place. Then, the  Assign_Role transition can fireto assign the roles to the user using information stored inthe  Role_DB. In addition, a user session is created byfiring the Create_Session transition. The user sessiondefines the period of time during which, a user caninteract with an application. The user session begins whenthe user starts to access the web services and ends whenthe user finishes the web services invocation. If thesession expires during the invocation, the WS_Logic  transition returns a timeout  result back to the XMLfirewall. The next task is to fetch a policy from the Policy_DB. The Fetch_Policy transition can fire whenthere is a token in the User_Role place and the State_Info  place. A policy is fetched from the Policy_DB based onthe user role and current state of the system. After apolicy is fetched and a session is created, a user space iscreated that contains the user information, permissionsand the session information. A token representing a userspace will be deposited into the UserSpace place.A token in the  Access_Request  place represents a webservice invocation request. The Check_Permission  transition can fire to check the  Access_Request  with the User_Space to determine its access permissions. After thechecking, a token representing the result will be depositedinto the place Permission_Result  . If the user has theneeded permissions, then the Pass transition fires. Afterthe web service request is processed (i.e., the firing of the WS_Logic transition), a token representing the result of the web service invocation is passed to the XML firewall.This token enables   the  Accept_WS_Response transition.The result from the web service also updates informationin the State_DB . On the other hand, if the user does nothave sufficient permissions to invoke a web service, the Fail transition fires, and a token representing accessdenial is placed in the  Access_Failed  place. When thetransition  Access_Denied  fires, a token is deposited intothe FW_Result  place, which indicates the web serviceaccess is denied. From the above model, we can see thatthe FW_Result  place may hold two types of tokens: onerepresenting an access denied  message, and another onerepresenting the result from web service invocation. With Start_AuthorizationAccess_RequestCreate_SessionFailUser_RequestComputational_ LogicInit/ResultWS_RequestCheck_If_ExistingFirst_Time_UserExisting_UserPerform_Background_Check BG_Check_DBCheck_FailedCheck_PassedUpdate_DatabasesRole_DBAssign_RoleFetch_State_InfoUser_RolePolicy_DBFetch_PolicyCreate_UserSpaceUserSpace( Username , Permissions , Session )Check_PermissionPassAccess_FailedWS_LogicAccept_ResultAccept_WS_ResponseFW_ResultUserInfo_DBStateInfo Figure 4.   Petri net model of an XML firewall with one application and one web service   Valid_User_RequestAccess_DeniedState_DB  Application Permission_Result 65
Search
Tags
Related Search
We Need Your Support
Thank you for visiting our website and your interest in our free products and services. We are nonprofit website to share and download documents. To the running of this website, we need your help to support us.

Thanks to everyone for your continued support.

No, Thanks