An extended XACML model to ensure secure information access for web services

The Journal of Systems and Software 83 (2010) 77–84

Contents lists available at ScienceDirect

The Journal of Systems and Software journal homepage: www.elsevier.com/locate/jss

An extended XACML model to ensure secure information access for web services Shih-Chien Chou *, Chun-Hao Huang Department of Computer Science and Information Engineering, National Dong Hwa University, Taiwan

a r t i c l e

i n f o

Article history: Received 17 October 2008 Received in revised form 17 May 2009 Accepted 26 June 2009 Available online 2 July 2009 Keywords: Web service Information flow control Security Prevent information leakage

a b s t r a c t More and more software systems based on web services have been developed. Web service development techniques are thus becoming crucial. To ensure secure information access, access control should be taken into consideration when developing web services. This paper proposes an extended XACML model named EXACML to ensure secure information access for web services. It is based on the technique of information flow control. Primary features offered by the model are: (1) both the information of requesters and that of web services are protected, (2) the access control of web services is more precise than just ‘‘allow or reject” policy in existing models, and (3) the model will deny non-secure information access during the execution of a web service even when a requester is allowed to invoke the web service. Ó 2009 Elsevier Inc. All rights reserved.

1. Introduction Internet has substantially changed the software world because more and more software systems operate on the net. To save software development efforts, web services have been offered for applications to invoke (here web services can be considered reused software components). In developing web services, ensuring secure information access when web services are being executed is important. Many research results have been proposed regarding web service access control (Bertino et al., 2006; Bhatti et al., 2004, 2005; Koshutanski and Massacci, 2005; Mecella et al., 2006; OASIS, 2003; Paurobally and Jennings, 2005; Seamons et al., 2001; Shen and Hong, 2006; Skogsrud et al., 2004; Srivatsa et al., 2007; Wonohoesodo and Tari, 2004). In general, the researches focus on allowing or denying a requester to access a web service. Some researches go a step further to solve the problem of negotiation/conversation among web services (Bertino et al., 2006; Koshutanski and Massacci, 2005; Mecella et al., 2006; Paurobally and Jennings, 2005; Seamons et al., 2001; Skogsrud et al., 2004; Srivatsa et al., 2007; Wonohoesodo and Tari, 2004). The need for negotiation is because an invoked web service may invoke other web services. In our research, we go another step further to ensure secure access of information (which prevents information leakage) when requesters or web services are being executed. Secure information access can be achieved through information flow control (Maamir and Fellah, 2003; Myers and Liskov, 2000; Samarati et al., 1997). The basic control mechanism is disallowing unauthorized roles to access information within executing applications. Since roles are played by users (Sandhu

* Corresponding author. E-mail address: [email protected] (S.-C. Chou). 0164-1212/$ - see front matter Ó 2009 Elsevier Inc. All rights reserved. doi:10.1016/j.jss.2009.06.045

et al., 1996), disallowing unauthorized roles to access information prevents unauthorized users to access sensitive information. This achieves the objective of information flow control (i.e., preventing information leakage). We identified the reference model XACML (OASIS, 2003) proposed by OASIS for web service access control. It determines whether a requester can invoke a web service by checking the requester’s attributes. We also identified implementations of XACML (Shen and Hong, 2006). Moreover, we identified models to solve the problem of negotiation (Bertino et al., 2006; Koshutanski and Massacci, 2005; Mecella et al., 2006; Paurobally and Jennings, 2005; Seamons et al., 2001; Skogsrud et al., 2004; Srivatsa et al., 2007; Wonohoesodo and Tari, 2004). In addition to the issues that have been addressed, our research identified the following three problems that should be solved in web service access control: (a) The existing models only protect web services. In our opinions, both the information of requesters and that of web services should be protected. (b) The existing models only make an ‘‘allow or reject” decision. That is, if a requester’s attributes pass the requirements of a web service, the requester is allowed to invoke the web services. Otherwise, the invocation is rejected. We think that the ‘‘allow or reject” policy is imprecise in web service access control. For example, suppose a web service manages sensitive information (e.g., accounts and passwords of customers in a bank) under some situations and manages non-sensitive information (e.g., advertisements provided by a bank) under other situations. With the ‘‘allow or reject” policy, a requester is allowed to invoke the web service only when the requester is authorized to access the sensitive information managed by the web service. In the real cases,

78

S.-C. Chou, C.-H. Huang / The Journal of Systems and Software 83 (2010) 77–84

it is possible that a requester only requests the web service to access non-sensitive information (e.g., the requester requests the web service to retrieve the advertisements of a bank). Under this situation, invoking the web service by the requester should not be rejected. Nevertheless, the ‘‘allow or reject” policy will reject the requester if the requester is not authorized to access the sensitive information. In our opinions, invoking a web service should be allowed if the requester passes some basic requirements. When a web service is being executed, if the requester requests to access the information unauthorized for the requester, the web service denies the request and stops the service. This access control policy is more precise than the ‘‘allow or reject” policy. (c) With the control of the existing models, when a requester is allowed to invoke a web service, the web service must do everything the requester requested. If unsafe access occurs, the web service cannot deny the access. In our opinion, information access in a web service should be monitored even when the web service is allowed to be invoked by a requester. According to the above description, we think that an access control model for web services should be more precise. In the past years, we developed information flow control models to prevent information leakage (Chou, 2004; Chou and Chen, 2006), which can also be used in the access control of web services. Here information leakage refers to leaking high security level information to low security level users. For example, if a patient’s case history can only be read by a hospital’s doctors, information leakage occurs when a patient obtains another patient’s case history. In an executing program, an information flow occurs when information is assigned to a variable. Controlling information flows corresponds to preventing high security level information from being assigned to variables that can be accessed by low security level users. Since variables of an application generally carry an application’s information and users can obtain a variable’s content when the variable is output, controlling information flows prevents low security level users from obtaining high security level information. In our research, we extended XACML by embedding the information flow control concept. The extended model is named EXACML (extended XACML). Currently, the model is only fit for objectoriented web services. EXACML protects the information managed by both requesters and web services. Moreover, access control in EXACML does not follow the ‘‘allow or reject” policy. Instead, EXACML sets up basic requirements for web services. The basic requirements determine whether a requester can invoke a web service. Since a web service may invoke other web services, the basic requirements also determine whether the requester can invoke those web services. That is, the basic requirements handle negotiation mentioned above. When a requester passes the basic requirements of a web service, the requester can invoke the service. During the execution of the web service, EXACML prevents the requester from accessing sensitive information that is not authorized for the requester. Therefore, EXACML solves the three problems mentioned above. Moreover, since the concept of information flow control is embedded, EXACML inherits the features of information flow control models such as controlling both read and write access and preventing indirect information leakage (Chou, 2004; Chou and Chen, 2006). This paper describes EXACML.

2. Related work Access control for web services protects sensitive information (in both requesters and web services) from being leaked. Quite a

few access control models for web services have been proposed. Below we survey some important ones. The research of Shen and Hong (2006) proposes an access control model for web services. In the model, requester uses PMI (privilege management infrastructure) for authentication. The checking, retrieval, and revocation of authentication are all managed by the PMI. It also uses an RBAC-based web service access control policy to determine whether a requester can invoke a web service. In general, the model merely determines whether a requester can invoke a web service. It, however, cannot solve the three problems mentioned in Section 1. The model proposed by Bhatti et al. (2004) uses X-GTRBAC (Bhatti et al., 2005) to control the access of web services. X-GTRBAC can be used in heterogeneous and distributed sites. Moreover, it applies TRBAC (Bertino et al., 2001) so that the factor of time is considered. Although the model proposed by Bhatti seems sophisticated, it cannot solve the three problems mentioned in Section 1. XACML (OASIS, 2003) is a reference model proposed by OASIS for web service access control. It determines whether a requester can invoke a web service. There are implementations of XACML, such as that in Shen and Hong, 2006. In general, both XACML and the implementations cannot solve the three problems mentioned in Section 1. The model proposed by Seamons et al. (2001) discusses whether a composition of web services can be invoked. The need for the discussion is because a web service may invoke other web services. The model offers a language to facilitate enforcing the access control specification, which describe whether a composition of web services can be invoked. In general, the model cannot solve the three problems mentioned in Section 1. The model proposed by Bertino et al. (2006) incorporates the role-based access control (RBAC) concept (Sandhu et al., 1996) to define its access policies. It uses a two-leveled mechanism for web service access control. The first level, which is the service level, checks the roles assigned to consumers (i.e., requesters) and web services. An authorized requester is a candidate to invoke a web service. We use the term ‘‘candidate” because an authorized requester should pass the second level to invoke a web service. The second level, which is the attribute level, uses parameters as attributes of a service and assigns permissions to the attributes. A requester can invoke a web service only when it possesses the permissions to access the attributes. The control of the model is more precise than those that using only one level control. Nevertheless, it still fails to solve the problems mentioned in Section 1. Quite a few researches focus on negotiation among requesters and web services. Below we survey some of them. We do not discuss them much because the objectives of the researches and that of ours are not the same. We discuss them because our model’s basic requirements mentioned in Section 1 are also a kind of negotiation. The model Trust-Serv (Wonohoesodo and Tari, 2004) discusses dynamic choosing web services at run time. The choosing process is a kind of negotiation. It uses the concept of trust negotiation (Yu et al., 2003) to select web services that are allowed to invoke. The major component used to determine whether a web service is allowed to invoke is credential. Trust-Serv describes trust negotiation policies using state machines, which are easy to be computerized. The model proposed by Koshutanski and Massacci (2005) uses digital credentials to manage negotiation. It defines strategies for negotiation policies. The model proposed by Skogsrud et al. (2004) handles the problem of k-leveled invocation of web services (a web service may invoke other ones, this results in multilevel invocations). The major component used in the model is credentials. The objectives of some models we surveyed are also about negotiation (Mecella et al., 2006; Paurobally and Jennings, 2005; Srivatsa et al., 2007; Ardagna and Damiani, 2006; Koshutanski

S.-C. Chou, C.-H. Huang / The Journal of Systems and Software 83 (2010) 77–84

79

and Massacci, 2003; Sirer and Wang, 2002). Each of the research uses a process or a mechanism to determine whether a web service or a set of web services can be invoked. We do not negate the value of the researches regarding negotiation. Nevertheless, they cannot solve the three problems mentioned in Section 1. Our survey revealed that researchers agree on the needs of access control for web services. Nevertheless, the models we surveyed do not solve the problems mentioned in Section 1. We thus design our model EXACML. 3. Model In this section, we first describe web services. We then describe the architecture of XACML because our model EXACML is an XACML extension. Finally, we describe EXACML. 3.1. Web services The architecture of a web-service-based application is shown in Fig. 1 (W3C Working Group, 2004), which is composed of three cooperating components. The components are the requesters, the web service provider, and the service broker. Since a web service may invoke another web services, a requester may be an application or a web service. The service broker records web services offered by the service provider. When a new web service is provided, the service provider should register the service to the service broker. When a requester requests a web service, the requester inquires the service broker for the existence of the service. If the answer of the inquiry is positive, the requester invokes the web service provided by the service provider. In Fig. 1, the three components communicate with one another using the XML-based SOAP protocol. In general, the components can be located on the same site or on distributed ones. 3.2. XACML XACML (OASIS, 2003) is a reference model proposed by OASIS. It offers mechanisms to define access control policy. Under different security requirements, different control policies can be defined using the mechanisms. The architecture of XACML is shown in Fig. 2, in which the component ‘‘Resources” corresponds to web services. Note that in the original XACML model, the ‘‘Requester” component is depicted as the ‘‘User” component. Since our EXACML model also has a ‘‘User” component and the concepts of the users in EXACML and those in the original XACML model are different, we replace the ‘‘User” component using the ‘‘Requester” components in the original XACML model to prevent confusion. In XACML, PAP writes policies and policy sets to the Policy repository. Context handler performs format exchange among XACML components. With the control of XACML, when a requester requests to access a resource, PEP takes control to determine

Fig. 1. Web service architecture.

Fig. 2. XACML architecture.

whether the request should be allowed or rejected. During the determination process, PIP collects attributes. The collected attributes includes those of resource information such as resource name, those of requester information such as the requester’s role, those of environment information such as system time, and those of action information such as operation type. The collected attributes are then sent to PDP, which makes decision by checking whether the attributes fulfill the policies associated with the invoked web service. The final decision is returned to PEP. If the request is allowed, the requester can access the resource. Otherwise, the request is rejected. 3.3. EXACML EXACML is an extension of XACML. Therefore, the components of EXACML are almost the same as those of XACML. Nevertheless, we assigned information flow control functions to EXACML components so that the problems mentioned in Section 1 can be solved. In EXACML, a requester should pass the basic requirements before invoking a web service. Checking whether a requester passes the basic requirements corresponds to negotiating among requesters and web services. Therefore, the basic requirements are a solution of negotiation mentioned in Section 1. We do not compare our negotiation approach with others because our research aims at solving the three problems mentioned in Section 1 instead of merely solving the negotiation problem. When a requester passes the basic requirements and invokes a web service, the web service is being executed. During the execution, EXACML checks whether the instructions that will cause information flows are secure. If a non-secure information flow is identified, the web service will be stopped to prevent information leakage. Below we formally define the EXACML model, which is based on RBAC. Definition 1. EXACML ¼ ðUSR; RLE; URA; VAR; ACLS; DSOURCES; BRÞ, in which (a) USR is a set of users. Users play roles when an application is being executed. (b) RLE is a set of roles. EXACML regards an object as a role. Regarding objects as roles is natural because real world objects frequently map to software objects. (c) URA is a set of user-role assignments, which is defined as ‘‘USR ? 2RLE”. (d) VAR is the set of variables appear in the requester and the web services. A variable may be an object attribute, a private variable used in object methods, or a method return value. (e) ACLS is a set of access control lists (ACLs). EXACML attaches ACLs to variables. ACLs are permissions in EXACML. Since ACLs are attached to variables, the control granularity is detailed to variables. We need this fine-grained control because different variables may carry information in differ-

80

S.-C. Chou, C.-H. Huang / The Journal of Systems and Software 83 (2010) 77–84

ent security levels. In general, role should be used to define ACLs (i.e., permissions). Nevertheless, using roles (i.e., objects, see item (b) above) to define ACLs results in imprecise control. We use an example to explain this point.Assume that a doctor can browse and change the case histories of the patients assigned to him. Moreover, a doctor can browse but not change the case histories of the patients not assigned to him. Under this assumption, if a patient is assigned to a doctor, the doctor object’s methods ‘‘browse_ case_history” and ‘‘change_case_history” can access the patient object’s attribute ‘‘case_history”. On the other hand, if a patient is not assigned to a doctor, only the method ‘‘browse_case_history” but not ‘‘change_case_history” of the doctor object can access the patient object’s attribute ‘‘case_history”. Suppose we regard objects as roles. Then, when an object is allowed to access a variable, every method of the object can access the variable. This will allow every doctor object’s methods ‘‘browse_case_history” and ‘‘change_case_history” to access every patient object’s attribute ‘‘case_history” in the above example. This causes trouble in the control example mentioned above. Therefore, using roles to define ACLs results in imprecise control. According to this consideration, EXACML uses object methods instead of roles (i.e., objects) to define ACLs. Letting MD be the set of object methods, the ACL ACLvar attached to a variable var is defined below:ACLvar = {RACLvar; WACLvar}, in which  RACLvar e 2MD, in which object methods in RACLvar are allowed to read var.  ACLvar e 2MD, in which object methods in WACLvar are allowed to write var.We need both RACL and WACL because EXACML controls both read and write accesses as the models we designed previously (Chou, 2004; Chou and Chen, 2006). (f) DSOURCES is a set of data sources (DSOURCEs). Each variable in EXACML is associated with a DSOURCE to facilitate write access control (we will describe it later). DSOURCE records the object methods by which a variable’s data are written. For example, suppose the variable ‘‘var” is derived from the variables ‘‘var1” and ‘‘var2”, and ‘‘var1” and ‘‘var2” are respectively written by the object method ‘‘md1” and ‘‘md2”. Then, the DSOURCE of ‘‘var” is the set ‘‘{md1, md2}” after the derivation. (g) BR is the basic requirements mentioned before. In the following text, we will describe BR before describing the information flow control policy in EXACML. Note that Definition 1 does not include the important components ‘‘role-permission assignments” and ‘‘sessions” mentioned in RBAC. Role-permission assignments are not included because ACLs indicate the variables that can be read and/or written by a role’s method. That is, role-permission assignments are embedded in ACLs. As to sessions, we assume that a session is automatically created when a web service is invoked and the session is dropped when the service ends. Therefore, we need not explicitly define sessions. To check whether a requester can invoke a web service, the requester and the web service should first pass the basic requirements, which constitute the BR component in EXACML (see item (g) in Definition 1). Below we describe the BR component in details. In our original design, we use ACLs to define basic requirements. We then identified that ACLs are only suitable for checking whether an access is secure within a program or checking whether an invocation from a program to another one is secure. Nevertheless, they cannot be used to check whether an invocation from a

program to another one is secure under an environment that programs may be added or removed. The rationale is that knowing every program’s variables is necessary to define ACLs. In a web-service-based environment, both applications and web services may be added or removed anytime. Therefore, we used another mechanism instead of ACLs to define the basic requirements. The mechanism is called the trust management mechanism. To define the mechanism, the following sub-components should be included by the BR component: (a) Security level numbers: When a requester invokes a web service, every argument of the requester and the return value of the web service should be associated with a security level number. The number is set by programmers because both the requester and the web service do not know the security levels of the arguments and the return value. The programmers first determine the security levels of the arguments and the return value. They then set proper security level numbers to the arguments and the return value. EXACML uses a four-bit unsigned number for a security level number. That is, the security level number is between 0 (i.e., ‘‘0000” in bit representation) and 15 (i.e., ‘‘1111” in bit representation). In EXACML, larger security level number implies more sensitive information. (b) Credit level numbers: Every application and web service is associated with a credit level number. Like the security level number, EXACML uses a four-bit unsigned number for a credit level number. In EXACML, larger credit level number implies more reliable applications or web services. (c) Invocation graph: A web service may invoke other web services. The trust management mechanism needs an invocation graph to indicate the invocation relationships among web services. The relationships facilitate identifying the composition of web services that will be invoked by a requester when the requester invokes a web services. Below we describe the use of the three sub-components in the trust management mechanism. When a new web service is created, the service is registered to the UDDI. In addition to the web service, the existing web services that will be invoked by the newly added web service are also registered. Moreover, the security level numbers of the newly added web service’s return value is also registered. The registered invocation relationships allow the UDDI to establish an invocation graph. The UDDI then give an initial credit level number to the newly added web service. In our design, the initial credit level number is 15 (i.e., full credit). The credit level numbers of applications are also recorded in the UDDI and their initial values are also 15. Giving the newly added applications and web services the full credit is harmless because the EXACML model will stop the execution of an application or a web service when they attempt to leak information. We think that giving full credit results in the least limitation whenever the new applications and web services need to be executed. For example, when a requester want to invoke a new web service, the full credit of the web service increases the possibility of the web service to be invoked. That is, the utilization of new web services can be increased as long as they do not leak information. On the other hand, if a new web service leaks information, EXACML will prevent the leakage. Moreover, the credit levels of both applications and web services will be adjusted according to their dynamic behavior during program execution (see the credit level number promotion/demotion rules described below). As a summary, we think that giving the full credit to every newly added application and web service is reasonable. When an application APPLI intends to invoke a web service WEBSER, the programmers of APPLI assigns a security level number

81

S.-C. Chou, C.-H. Huang / The Journal of Systems and Software 83 (2010) 77–84

to every argument sent to WEBSER. EXACML then sends to the UDDI the name of APPLI and that of WEBSER. Having received the names, the UDDI retrieves all web services to be invoked (including WEBSER) by checking the invocation graph. The UDDI then returns to EXACML the following information: (a) the credit level numbers of APPLI, (b) the web services to be invoked and their credit level numbers, and (c) the security level numbers of the invoked web services’ return values. Let: (a) WEB be the set of web services to be invoked, (b) WEBclni be the credit level number of the ith web service in WEB, (c) WEBslni be the security level number of the ith web service’s return value in WEB, (d) APPcln be the credit level number of APPLI, (e) ARG be the set of arguments sent by APPLI, and (f) ARGslni be the security level number of the ith argument in ARG. With the above six components, the basic requirements for APPLI to invoke WEBSER are listed below:

First basic requirement :

MinðEBclni Þ >¼ MaxðARGslni Þ

By now we have described the basic requirements (i.e., the BR component of EXACML) to check whether an invocation from an application to a web service is allowed. However, as we have mentioned in Section 1, allowing an invocation does not ensure information leakage will not occur. Therefore, we have to ensure every instruction that induces information flow is secure when the invoked web service(s) are being executed. EXACML requires that the following two EXACML secure rules should be fulfilled when an information flow in the web service occurs. To define the rules, we assume that: (a) the variable ‘‘d_var” is assigned a value derived from the variables in the set ‘‘{vari | vari e VAR in Definition 1 and i is between 1 and n}”, (b) the assignment appears in the object method ‘‘md1”, (c) the original ACL of ‘‘d_var” is ‘‘{RACLd_var; WACLd_var}”, (d) the ACL of the ith variable that derives ‘‘d_var” is ‘‘fRACLvari ; WACLvari g”, and (e) the DSOURCE of ‘‘vari” is ‘‘DSOURCEvari ”:

First EXACML secure rule : Second basic requirement :

APPcln >¼ MaxðWEBslni Þ

In the basic requirements, the function ‘‘Min” selects the minimum value from a set of data and ‘‘Max” selects the maximum one. The first basic requirement requires that the credit level number of every service to be invoked must not be less than any security level number of the arguments sent by APPLI. The requirement intends to ensure that the information carried by the arguments will not be leaked by the web services to be invoked. The second basic requirement requires that the credit number of APPLI must not be less than any security level number of the return values of the web services being invoked. The requirement intends to ensure that the information carried by the return value will not be leaked by APPLI. As mentioned above, the security levels of arguments are set by programmers. Moreover, the invocation graph is created by the invocation relationships registered by programmers. Therefore, the security level numbers and the invocation graph will not be changed during the execution of applications. As to the credit level numbers of applications and web services, they are not controlled by programmers. Instead, they are automatically promoted and demoted according to the dynamic behavior of the applications and web services. The promotion/demotion performed every delta time (the length of delta is defined by the user of EXACML). The promotion/demotion rules are described below: Credit level number promotion rule: If an application does not leak the information returned from the web service it invoked in a delta time, the credit level number of the application is increased by one. Similarly, if a web service does not leak the information received from the arguments sent by an application in a delta time, the credit level number of the web service is increased by one. Note that the credit level number should not be larger than 15. Credit level number demotion rule: If an application leaks the information returned from the web service it invoked, the for-bit credit level number of the application is right shifted by one bit (the most significant bit is filled by 0). Similarly, if a web service leaks the information received from the arguments sent by an application, the for-bit credit level number of the web service is right shifted by one bit (the most significant bit is filled by 0). According to the above rules, the promotion is slow and the demotion is fast. This is reasonable because of the importance of information protection. As to identifying whether an application or a web service leaks information, it is accomplished by the EXACML secure rules mentioned below. Although the following description merely mentions that the execution of a web service should be checked, the execution of an application should also be checked to ensure no information leakage occurs. Therefore, the data needed by the promotion/demotion rules (i.e., whether information leakage occurs in a delta time) can be easily acquired.

RACLd v ar # \ni¼1 RACLvari
^ md1 2 \ni¼1 RACLvari

Second EXACML secure rule :




WACLd v ar

 [ni¼1 DSOURCEvari [ fmd1g The first EXACML secure rule controls read access. The condition ‘‘RACLd v ar # \ni¼1 RACLvari ” requires that ‘‘d_var” must be at least the same restricted as the variables deriving ‘‘d_var”. The condition ‘‘md1 2 \ni¼1 RACLvari ” is necessary because the method ‘‘md1” reads the variables deriving ‘‘d_var” and assigns the derived data to ‘‘d_var”. The second EXACML secure rule controls write access. It requires that the data sources of the variables deriving ‘‘d_var” should be within ‘‘WACLd_var”, because the data derived from the variables are written into ‘‘d_var”. The rule also requires that the method ‘‘md1” must be within ‘‘WACLd_var” because the write operation is performed by the method. After the derived data is assigned to the variable ‘‘d_var”, the ACL of ‘‘d_var” should be changed by the join operation to prevent indirect information leakage (Myers and Liskov, 1998). We use the symbol ‘‘” to represent the join operator. With join, ‘‘ACLd_var” will be changed to ‘‘ni¼1 ACLvari ” after the derived data is assigned to the variable ‘‘d_var”. Definition 2. The join operation for the variables in the set ‘‘{vari | vari e VAR in Definition 1 and i is between 1 and n}” is defined below:

ni¼1 ACLvari ¼ \ni¼1 RACLvari ; [ni¼1 WACLvari




The join operation trusts less or the same set of readers. Therefore, join will not lower down security level. On the other hand, the operation trusts more writers. This is reasonable because a writer that can write a variable should be regarded as a trusted data source for the data derived from the variable. If a variable is assigned a constant, no join operation will be executed and the ACL of the variable remains unchanged. In addition to joining ACLs, the DSOURCE of ‘‘d_var” will be adjusted as follows:

DSOURCEd v ar ¼ [ni¼1 DSOURCEvari [ fmd1g ‘‘DSOURCEd_var” is set the union of the DSOURCEs of the variables deriving ‘‘d_var” and the method ‘‘{md1}”. The union of the DSOURCEs is obvious because all data sources deriving the computation result should be considered data sources of the result. The method ‘‘md1” is also a data source because the computation result is written by ‘‘md1” to ‘‘d_var”.

82

S.-C. Chou, C.-H. Huang / The Journal of Systems and Software 83 (2010) 77–84

(f) The ‘‘Context Handler” offers the same functions as the original XACML model. (g) The UDDI stores the credit level numbers of applications and web services. It also stores the invocation graph and the security level numbers of web services’ return values. The information is not stored in the UDDI of the original webservice-based applications. However, it is necessary for EXACML. Storing the information is an extension of the UDDI to support EXACML.

Fig. 3. EXACML architecture.

Based on the EXACML model, we designed the architecture of the model. Since EXACML is an extension of XACML, we let EXACML and XACML possesses the same components. Fig. 3 shows the architecture of EXACML. The difference between Figs. 2 and 3 is that an additional component ‘‘Information Flow Checker” is added to EXACML. The component is a software agent that checks whether an instruction will cause information flow. If an instruction will cause information flow, the agent sends the instruction to EXACML to check whether the information flow is secure (i.e., checks whether the information flow instruction passes the two EXACML secure rules). If the flow is secure, the instruction is allowed to execute. We add the agent because checking an instruction consumes much execution time. We let the agent independently executed in a separate site to reduce runtime overhead (see Section 5 for the experiment data). Below we describe the assignment of information flow control functions to the components in Fig. 3: (a) The ‘‘Policy Repository” stores the information of users, roles, user-role assignments, ACLs, and DSOURCEs. (b) PIP collects information for PDP to make decision. When a requester intends to invoke a web service, PIP collects the arguments, return value, and the variable that receives the return value. Since the information sent from a requester to a web service is XML-based message embedded in the SOAP protocol, PIP is an XML interpreter. (c) PDP ensures whether an invocation is allowed by checking the basic requirements. The information needed to check the basic requirements is collected by the PIP and received from the UDDI. Moreover, PDP also checks whether an information flow is secure (i.e., checks whether the two EXACML rules are fulfilled) during the execution of a web service. The necessary information for the checking such as ACLs and DSOURCEs is retrieved from the ‘‘Policy Repository”. (d) PAP performs the join operation. (e) PEP is an interface component. When PEP receives a request from a requester to invoke a web service, PEP informs PIP to collect information mentioned in item (b) above. The collected information is then sent to PDP to check the fulfillment of the EXACML basic requirements. If the checking passes, PDP informs PEP and PEP allows the requester to invoke the web service. When PEP receives instructions from the ‘‘Information Flow Checker” agent to check information flow security, it sends the instructions to PDP. PDP then checks the fulfillment of the two EXACML secure rules. If the checking passes, PEP informs the web service to continue. Otherwise, PEP informs the web service to stop.

Fig. 3 depicts three major components in the EXACML architecture. They are the requester, the EXACML model (including the Information Flow Checker), and the web service. When using EXACML, we embed the model in a programming language. To prevent information leaked by applications or web services, they should be implemented using the EXACML-embedded programming language. Section 5 will depict the experiment data. In our experiments, we evaluate the overall results. It is difficult to evaluate the individual cost between components. Although we do not evaluate the cost between the ‘‘Information Flow Checker” and PEP in the current stage, it should be evaluated because ‘‘Information Flow Checker” is an agent. Evaluating the cost allows us to obtain the important information of using agents. We let the evaluation as a future work.

4. Features As mentioned in Sections 1 and 2, quite a few models have been proposed for web services access control. The models we survey generally design policies to determine whether a requester can invoke a web service. Section 1 clearly points out the problems of the existing models, which are: (a) the models protect only the information of web services, (b) the models only offer the ‘‘allow or reject” policy, and (c) the models cannot deny non-secure information access during the execution of a web service when the requester is allowed to invoke the web service. EXACML is designed to solve the problems by offering the following features: (a) both the information of the requesters and that of the web services are protected, (b) the access control is more precise than the ‘‘allow or reject” policy (see Section 1 for more detailed explanation), and (c) the model will deny non-secure information access during the execution of a web service even when the requester is allowed to invoke the web service. The following descriptions prove that EXACML offers the features. Assume that: (a) the application APPLI intends to invoke the web service WEB, (b) the credit levels of APPLI and WEB are respectively APPcln and WEBcln, (c) the maximum security level number of the arguments sent by APPLI is MAXARGsln, and (d) the security level number of the return value for WEB is WEBsln. When APPLI invokes WEB, APPLI should trust WEB. Otherwise WEB may leak the information sent by APPLI. In this regard, the credit level number of WEB should be at least the same as the security level number of every argument sent by APPI. This results in the requirement ‘‘WEBcln >= MAXARGsln”, which can be achieved by EXACML’s first basic requirement mentioned in Section 3.3 (note that the first basic requirement assumes that a set of web services are invoked by APPLI but here we use only one web service to simplify the explanation). On the other hand, when APPLI invokes WEB, WEB should trust APPLI. Otherwise, APPLI may leak WEB’s return value. In this regard, the credit level number of APPLI should be at least the same as the security level number of WEB’s return value. This results in the requirement ‘‘APPcln >= WEBsln”, which can be achieved by EXACML’s second basic requirement. According to the above description, the first basic requirement protects the information sent to a web service and the second one protects the value re-

83

S.-C. Chou, C.-H. Huang / The Journal of Systems and Software 83 (2010) 77–84

5. Evaluation We implemented a simple prototype for EXACML and used a simple banking system’s subsystems to test the prototype (we regard the subsystems as web services). We evaluated the prototype using two experiments. In the first experiment, we intentionally injected 1% invalid instructions (i.e., instructions that violate one or more EXACML secure rules) to every subsystem. We then checked whether the prototype EXACML can identify the injected

Invalid instructions identified by EXACML Percentage

1.06

Depositing subsystem

1.04 1.02 1 0.98

1

2

3 Student

4

5

Withdrawing subsystem Currency exchanging subsystem

Fig. 4. Invalid instructions identified by EXACML (in percentage).

Runtime overhead of EXACNL 20.4 Overhead

turned to a requester. That is, EXACML offers the above-mentioned feature: ‘‘both the information of the requesters and that of the web services are protected”. Existing models only check whether a requester can invoke a web service. Comparing with existing models, EXACML goes a step further to prevent information leakage during the execution of a web service. That is, EXACML offers the second and third features mentioned in the second paragraph of this section. To ensure security, existing models generally set up rigorous policy to decide whether a requester can invoke a web service. Nevertheless, ‘‘can invoke” and ‘‘securely invoke” are not necessary the same because existing model does not check information flows during program execution. In our consideration, we set up easy-topass basic requirements to filter out clearly untrusted invocations. We say the requirements easy to pass because we give every new application and web service full credit to increase the possibility of web service invocation. Nevertheless, ‘‘easy to pass” does not equal to ‘‘non-secure invocation” because EXACML checks every information flow during the execution of applications and web services. Any non-secure information will stop the execution of a web service to prevent information leakage. The prevention is achieved by the two EXACML rules and the join operation mentioned in Section 3.3. According to the first EXACML secure rule, when the value of the variable VAR is derived from a set of variables, the security level of VAR should be at least the same as every variable in the variable set to prevent values in high security level variables flow to a low security level variable. According to the second EXACML secure rule, when the value of the variable VAR is derived from a set of variables, VAR should trust the data sources of every variable in the variable set. This rule prevents information corruption caused by untrusted data sources. Moreover, the EXACML join operation prevents indirect information leakage. According to the above description, EXACML obviously offers the feature ‘‘denying non-secure information access during the execution of a web service even when the requester is allowed to invoke the web service”. As to the feature ‘‘the access control of EXACML is more precise than the ‘allow or reject’ policy”, we use the example in Section 1 to explain it. Suppose that: (a) the web service WEB manages sensitive information (e.g., accounts and passwords of customers in a bank) under some situations and manages non-sensitive information (e.g., advertisements provided by a bank) under other situations, (b) the application APPLI intends to invoke WEB, and (c) APPLI can only access non-sensitive information in WEB. Since APPLI cannot access the sensitive information managed by WEB, the invocation from APPLI to WEB will be rejected by the ‘‘allow or reject” policy offered by existing models. However, EXACML will allow the invocation because both APPLI and WEB initially obtain the full credit. As long as APPLI does not require WEB to access the sensitive information (i.e., every information flow of WEB fulfills the two EXACML rules when APPLI invokes WEB), the execution of WEB can finish. On the other hand, if APPLI intends to access sensitive information through WEB, the execution of WEB will stop and the credit level of APPLI will be demoted. According to the above scenario, EXACML offers more precise policy than the ‘‘allow or reject” policy.

Depositing subsystem

20.2 20 19.8 19.6 19.4

1

2

3 Student

4

5

Withdrawing subsystem Currency exchange subsystem

Fig. 5. EXACML overhead.

invalid instructions. We first adjusted the prototype by allowing invalid instructions to execute. The adjustment is necessary because EXACML will stop executing a program when an invalid instruction is identified (under this situation, we cannot identify all invalid instructions). After the adjustment, we let the subsystems to be executed under the control of EXACML. During the execution, we recorded the identified invalid instructions. The experiment result is shown in Fig. 4. When we checked the identified invalid instructions, we found that all the injected invalid instructions were identified. Figs. 4 shows that the number of invalid instructions identified by EXACML is more than that of injected ones. This is reasonable because students usually committed errors. In the second experiment, we correct all the invalid instructions identified by EXACML and disallowed invalid instructions to execute (i.e., remove the above-mentioned adjustment). We then execute the simple banking system’s subsystems programmed by five students. Fig. 5 shows the runtime overhead of the subsystems (the runtime overhead is obtained by comparing the execution time of the subsystems embedding EXACML with the execution time of those without the embedding). The average runtime overhead of EXACML in our experiment is about 20. In general, the overhead is large. Nevertheless, the prototype executes all the EXACML components (e.g., PIP, PEP, and PDP) as well as the web service on the same site. If the EXACML components are implemented as software agents and allowed them to be executed in parallel on different sites, we expect that the overhead can be reduced. In another experiment, we used three ‘‘Information Flow Checker” agents (see Fig. 3) executing on different sites. The experiment identified that the runtime overhead of the information flow checking function was reduced by about 10%. We thus believe that using software agents to implement EXACML can reduce runtime overhead. As described near the end of Section 3, we do not evaluate the cost between the ‘‘Information Flow Checker” and PEP in the current stage. Nevertheless, it should be evaluated because ‘‘Information Flow Checker” is an agent. Evaluating the cost allows us to obtain the important information of using agents. We let the evaluation as a future work. 6. Conclusions This paper proposes an access control model EXACML to ensure secure information access for web services. It is an extension of

84

S.-C. Chou, C.-H. Huang / The Journal of Systems and Software 83 (2010) 77–84

XACML. It embeds the concepts of information flow control to prevent information leakage. EXACML offers the following features: (1) both the information of requesters and that of web services are protected, (2) the access control of web services is more precise than just ‘‘allow or reject” policy in existing models, and (3) the model will deny non-secure information access during the execution of a web service even when a requester is allowed to invoke the web service. According to our survey, no existing model offers those features. In our design, EXACML uses basic requirements to check whether a requester can invoke a web service. Moreover, EXACML embeds an information flow control model in both requesters and web services to ensure secure access of information when they are being executed. We implemented a prototype system for EXACML and found that it can identify non-secure information access. We thus think that EXACML is useful in ensuring secure information access. Nevertheless, the runtime overhead is large. In the future, we will implement EXACML components as software agents that execute in parallel on different sites. We expect that this implementation will reduce runtime overhead. References Ardagna, C.A., Damiani, E., 2006. A web service architecture for enforcing access control policies. Electronic Notes in Theoretical Computer Science 142, 47–62. Bertino, E., Bonatti, P.A., Ferrari, E., 2001. TRBAC: a temporal role-based access control model. ACM Transactions on Information and System Security 4 (3), 191–233. Bertino, E., Squicciarini, A.C., Martino, L., Pacim, F., 2006. An adaptive access control model for web service. International Journal of Web Service Research 3 (3), 27– 60. Bhatti, R., Bertino, E., Ghafoor, A., 2004. A trust-based context-aware access control model for web services. In: IEEE ICW’04, pp. 184–191. Bhatti, R., Ghafoor, A., Bertino, E., Joshi, J.B.D., 2005. X-GTRBAC: an XML-based policy specification framework and architecture for enterprise-wide access control. ACM Transactions on Information and System Security (TISSEC) 8 (2), 187–227. Chou, S.-C., 2004. Embedding role-based access control model in object-oriented systems to protect privacy. Journal of Systems and Software 71 (1–2), 143–161. Chou, S.-C., Chen, Y.C., 2006. Managing role relationships in an information flow control model. Journal of Systems and Software 79 (4), 507–522. Koshutanski, H., Massacci, F., 2003. An access control framework for business processes for web service. In: ACM Workshop on XML Security. pp. 15–24. Koshutanski, H., Massacci, F., 2005. Interactive credential negotiation for stateful business processes. Lecture Notes in Computer Science, 256–272. Maamir, A., Fellah, A., 2003. Adding flexibility in information flow control for objectoriented systems using versions. International Journal of Software Engineering and Knowledge Engineering 13 (3), 313–326.

Mecella, M., Ouzzani, M., Paci, F., Bertino, E., 2006. An access control enforcement for conversation-based web services. In: International World Wide Web Conference. pp. 257–266. Myers, A., Liskov, B., 1998. Complete, safe information flow with decentralized labels. In: Proceedings of 14th IEEE Symposium on Security and Privacy, pp. 186–197. Myers, A., Liskov, B., 2000. Protecting privacy using the decentralized label model. ACM Transactions on Software Engineering and Methodology 9 (4), 410–442. OASIS, 2003. eXtensible Access Control Markup Language (XACML) Version 1.0. OASIS Standard 18. Paurobally, S., Jennings, N.R., 2005. Protocol engineering for web service conversations. Engineering Applications of Artificial Intelligence 18 (2), 237– 254. Samarati, P., Bertino, E., Ciampichetti, A., Jajodia, S., 1997. Information flow control in object-oriented systems. IEEE Transactions on Knowledge and Data Engineering 9 (4), 524–538. Sandhu, R.S., Coyne, E.J., Feinstein, H.L., Youman, C.E., 1996. Role-based access control models. IEEE Computer 29 (2), 38–47. Seamons, K.E., Winslett, M., Yu, T., 2001. Limiting the disclosure access control policies during automated trust negotiation. In: Network and Distributed System Security Symposium. Shen, H.-B., Hong, F., 2006. An attribute-based access control model for web services. In: IEEE International Conference on Parallel and Distributed Computing Applications and Technologies (PDCAT’06). pp. 74–79. Sirer, E.G., Wang, K., 2002. An access control language for web services. In: Proceedings of the Seventh ACM Symposium on Access Control Models and Technologies (SACMAT’02). pp. 23–30. Skogsrud, H., Benatallah, B., Casati, F., 2004. Trust-Serv: model-driven lifecycle management of trust negotiation policies for web services. In: International World Wide Web Conference. pp. 53–62. Srivatsa, M., Iyengar, A., Mikalsen, T., Rouvellou, I., Yin, J., 2007. An access control system for web service compositions. In: 2007 IEEE International Conference on Web Services, pp. 1–8. W3C Working Group, 2004. Web service architecture. The World Wide Web Consortium Working Group Note. Wonohoesodo, R., Tari, Z., 2004. A role based access control for web services. In: Proceedings of the 2004 IEEE International Conference on Service Computing, pp. 49–56. Yu, T., Winslett, M., Seamons, K., 2003. Supporting structured credentials and sensitive policies through interoperable strategies for automated trust negotiation. ACM Transactions on Information and System Security 6 (1), 1–42. Shih-Chien Chou received a PhD degree from the Department of Computer Science and Information Engineering, National Chiao Tung University, Hsinchu, Taiwan. He is currently a full professor in the Department of Computer Science and Information Engineering, National Dong Hwa University, Hualien, Taiwan. His research interests include software engineering, process environment, software reuse, and information flow control. Chun-Hao Huang received a Master degree from the Department of Computer Science and Information Engineering, National Dong Hwa University, Hualien, Taiwan. He is currently an Engineer in HitronTechnologies, Taiwan.