Related works of DRA4SOA

Existing SOA security standards such as WS-Security [88], Security Assertion Markup Language (SAML) [89], WS-Trust [38], WS-SecureConversation [90], and WS-SecurityPolicy [37] focus on the message security and identity management of SOA implementations that use Web services. These standards were created to address message-level security and provide the ability to satisfy security requirements of an

SOA environment. However, they only support the point-to-point security requirements of individual services, and they cannot refer to the structure of dynamically formed calling chains (or service chains [91, 92, 93]) to perform access control for a service invocation.

Access control is a mechanism that enables an authority to control accesses to a given information system. Many access control mechanisms have been proposed and implemented. Access control is traditionally implemented using an access control matrix, where an access request from a subject can be granted if the requested access right is recorded in the matrix [14]. A similar access control model is the access control list (ACL), which is usually implemented as a list of permissions attached to a file or object in a computer file system [94]. The role-based access control (RBAC) model differs from ACLs used in traditional discretionary access control systems in that it assigns permissions to specific operations that have high-level meaning in the organization, rather than to low-level data objects [15]. The Extensible Access Control Markup Language (XACML) is an open-standard XML-based language designed to express security policies and access rights to information for Web services, digital rights management, and enterprise security applications [95]. The XACML is an access control model that incorporates the RBAC model, and it was designed to work in conjunction with the SAML [89]. Recent work in attribute-based access control (ABAC) [96] suggests that attributes and rules could either replace RBAC or increase its simplicity and flexibility. A variant of ABAC is the context-aware access control system that can dynamically adjust role assignments and permission assignments based on context information [97].

Some researches have focused on the security problem in service composition in SOA systems. Zhu et al. proposed an access control model for Web-service provision called ACM4WSC, in which the users can access a composite Web service without being concerned about the access control of its elementary services [98]. They presented two methods to manage the access control policies of the elementary services. Carminati et al. proposed a method for modeling security constraints and a brokered architecture to build composite Web services according to specified security constraints [99]. Bartoletti et al. proposed a static approach that employs -calculus to determine how to compose services while guaranteeing that their execution is always secure without requiring any dynamic checking [100]. Srivatsa et al. presented an access control model for specifying and enforcing access control rules on the provision of Web services [101]. They proposed using pure-past linear temporal logic to perform history-sensitive access control based on causal or temporal dependencies of logged transactions. Hwang et al. proposed an operational model to support the security of Web services [102]. Their model supports a flexible key specification scheme called explicit key definition, which can be used to define three types of keys: static keys, dynamically selected keys, and keys applied to digital signatures. The service requester can determine the identity of the keys used without having to negotiate with the service provider. Paci et al. proposed a novel approach for determining at design time whether a choreography can be implemented by a set of Web services based on their access control policies and the disclosure policies regulating the release of their credentials [103]. Chiang proposed a framework to support process-instance security in an SOA, which targeted how to serialize the process instance of BPEL [104]. Wu-Lee and

Hwang described how to simultaneously support both dynamic policies and separation of concerns when developing an SOA application [105]. They presented the DPSL (Dynamic Policy Specification Language) for managing and controlling the quality of service according to the dynamic behavior of the workflow in an SOA. A notable omission in the above works is considering the situation where the service invocation may form a calling chain, and thus they did not provide any method for supporting calling-chain security.

We now discuss related work targeting calling-chain security. Li and Karp proposed authorization-based access control to solve the calling chain (which they called a service chain) security problem of SOA systems [42, 106]. In their method the access control decision is based on authorizations presented explicitly by the requester (or originator). Authorization-based access control employs a list of authorizations for each service provider. The policies use a policy language to specify which users are granted which rights. Authorization-based access control requires the originator to obtain the authorization rights before performing the invocation. However, services that may be invoked in the calling chain are usually unknown to the originator in real-world scenarios, which makes it impractical for the originator to obtain all of the needed authorization rights before making the invocation. She et al. proposed using a trusted third party and delegation tokens for access control in calling-chain security [91, 92].

This approach requires the originator or service providers to obtain a delegation token from the third-party security token server, and thus requires all of the service providers to trust that server. When an originator wants to invoke a service S in service provider SP1 indirectly, it forwards the obtained delegation token to a service provider, say SP2,

that then can use the delegation token of the originator to invoke S in SP1. However, the originator cannot prevent service provider SP2 from using this delegation token to perform other actions, and so the delegation token could be misused by SP2 and thereby create security problems. The scheme of She et al. offers a way to authenticate the identity of the originator according to the delegation token. In addition, their framework cannot guarantee nonrepudiation. Because their framework does not support a mechanism to derive the dynamically formed calling chain in a service provider, there is no way for a service provider to refer to the formed calling chain to perform access control. She et al. also proposed the Service Chain Information Flow Control (SCIFC) model for information flow control in the provision of Web services [93], which supports information flow control through a back-check procedure and pass-on certificates. When composing a new service S, whether or not the information embedded in the requests can flow to this new service should be back-checked with previous invoked services. In the response flow, S authorizes the flow of its response to previous invoked services using a pass-on certificate. SCIFC allows the Web services to specify how to protect their information in a calling chain without leaking any critical information to services they do not trust. However, SCIFC cannot support a mechanism to perform access control based on a dynamically formed calling chain and cannot guarantee nonrepudiation. Our DRA4SOA maintains confidentiality by applying element-wise encryption to the invocation and response information.

36