Service-Oriented Architectures and Workflow Management Systems
A service-oriented architecture (SOA) is a paradigm for organizing and utilizing distributed services that may be under the control of different ownership domains [34].
An SOA provides a uniform means of offering, discovering, and interacting with and using services to produce desired effects consistent with measurable preconditions and expectations. An SOA requires the services to be only loosely coupled to the operating system and other technologies that underlie applications, and it separates functions into distinct units, or services [35], that developers make accessible over a network so that users can combine and reuse them when producing applications.
An SOA can be implemented in a software framework such as Web services [35].
Web services make functional building blocks accessible over standard Internet protocols independently of the types of platforms and programming languages. These services can be new applications or legacy systems wrapped to make them network-enabled. One of the goals of an SOA is to allow users to combine various functions to form ad-hoc applications that are almost entirely developed from existing software services. Orchestration is normally required to produce a new application [36].
A high-level language such as the Business Process Execution Language (BPEL) extends the service concept by providing a method for defining and supporting the orchestration of fine-grained services into coarser business services [37]. Orchestration involves ensuring that Web services interact with each other at the message level, including the business logic and execution order of the interactions from the perspective and under the control of a single endpoint. This involves an executable
business process that may result in a long-lived, transactional, multistep process model.
In fact, the BPEL incorporates a workflow model to describe the orchestration of Web services. An SOA is therefore a useful technical platform for workflow software.
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 (ACM), where an access request from a subject can be granted if the requested access right is recorded in the matrix [38]. A similar access control model is the access control list (ACL), which is usually related to a computer file system and is a list of permissions attached to a file or object [39]. 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 [40]. The RBAC model is regarded as a neutral policy and has been the most popular security model in recent years. In this model roles are created for various operations within an organization, with the permissions to perform certain operations being assigned to specific roles. Subjects are assigned particular roles, through which they acquire the permissions to perform particular system functions. RBAC assumes that the permissions needed to perform an organization’s roles change slowly over time, but that users may enter, leave, and change roles rapidly. A pure RBAC solution may provide inadequate support for dynamic attributes such as the time of day, which might need to be considered when determining user permissions. Supporting access control (particularly in large organizations) can result in a “role explosion” due to thousands of separate roles being created for different collections of permissions. Although RBAC provides a solid foundation for managing information security, administrators may be burdened with
having to maintain hundreds or even thousands of roles across several applications.
The number of roles increases with the number of connected systems, and an organization with a thousand employees can easily end up with several thousand roles [41]. Such role explosion usually occurs in information management systems controlling access in dynamic and heterogeneous infrastructures with combinations of employee turnover and security policy.
Recent work in attribute-based access control (ABAC) [42] 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 which can dynamically adjust role assignments and permission assignments based on context information [43].
The central idea of ABAC is that access can be determined based on various attributes presented by a subject and by attributes of the environment, such as an employee only being allowed to access certain data during his/her working hours.
Figure 3-1 shows the operation of ABAC. The administrative domain2 maintains a set of long-term policies3 that are stored in a policy pool (these policies are said to be “long term” since they do not change rapidly). The ABAC can support dynamic
roles
4 in which attributes such as the time of day are used by a front-end module to determine the subject’s role, retaining a conventional role structure but changing role sets dynamically. Note that roles are not created when a request is made; instead, a subject is bound to a role according to some access rules when a request is granted.While ABAC may require up to 2n access rules for n attributes, attempting to implement the same controls in RBAC could in the worst case require 2n roles [44]. A request RQ of a subject to an object takes the form RQ=(S, O, R), where S is the
2 An administrative domain is a service provider with access to a security repository, which makes it easy to authenticate and authorize clients with credentials.
3 In this paper we use the terms “policy” and “access control policy” interchangeably.
4 There are various ways to specify and implement dynamic roles; see Section 3-6.
subject, O is an object, and R is the set of operations that S is going to perform on O.
In the worst case, determining the permissions available to a particular request will require evaluation of all of the long-term policies, which potentially contain a large set of access rules in the policy pool.
Long-term policies
Resource manager
Resource Resource
Resources Access request
(S,O,R)
Policy pool
Dynamic attributes collection
Administrative domain Maintain
(Insert, delete, …)
Figure 3-1. Operation of ABAC
Standards related to an SOA such as Web services and BPEL do not support the specification of either authorization policies or authorization constraints on the execution of activities constituting a business process. The increasing popularity of SOA services makes it necessary to consider how to support access control, since services may have to access data objects maintained by other servers [45, 46]. 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 [47]. The XACML is an access control model that incorporates the RBAC model, and it was designed to work in conjunction with the Security Assertion Markup Language [48]. Since the XACML is based on RBAC, it only considers the static binding between subjects, objects, and roles; that is, the access control policy cannot be regulated according to the dynamic behaviors of the SOA system.
The dynamic behaviors in an SOA-based application are related to run-time states
and histories, including variables of workflow processes and flow control results and histories. It is necessary to investigate if statically specifying the access control fulfills the requirements of the workflow-based SOA environment. In this chapter we first present a motivating example to demonstrate that access control is usually influenced by dynamic behaviors in a workflow-based system. We then propose a novel access control model called workflow-based dynamic access control (WBDAC) in which the access control system can create transient policies according to the reference environment of the workflow process. The lifetime of a transient policy is equal to or shorter than the lifetime of its corresponding workflow process: so, the proposed model can alleviate the role- and rule-explosion problems in traditional or extended versions of RBAC and ABAC for workflow applications. To implement the WBDAC, we define the dynamic access control language for an SOA (DACL4SOA), which is a logical expression of the WBDAC. Although the DACL4SOA is designed to cooperate with previously proposed standards, such as the Web Services Description Language (WSDL), BPEL, and XACML, we believe that the method of incorporating dynamic access control using the DACL4SOA can be applied to any SOA framework. We also show that if the access control in a workflow-based SOA system cannot be specified according to dynamic behaviors of workflow processes, then the resulting overly tight coupling between the access control requirements and the flow structure will increase the difficulty, overhead, and cost of system development and maintenance. According to the separation-of-concerns principle, implemented Web services should only provide the required core functionality. The WBDAC can separate the specification of the access control requirements and service orchestration so as to reduce the software development and maintenance cost of an SOA system. The implementation and experimental results presented herein demonstrate the feasibility of the proposed
model.
This chapter is organized as follows. In Section 3-1 we present examples to demonstrate why it is necessary to consider the dynamic behaviors of the workflow process when specifying access control in SOA systems. Section 3-2 describes the proposed WBDAC model, and Section 3-3 presents the logical expression of WBDAC (i.e., the DACL4SOA). The architecture to support the DACL4SOA in the BPEL run-time system is given in Section 3-4. In Section 3-5 we detail the implementation and experimental results. Section 3-6 presents related work.
3-1. Motivating examples
In this section we present examples to demonstrate that it is insufficient to specify access control without considering dynamic behaviors of the workflow process.
Without loss of generality, we use Web services and the BPEL to construct our demonstration example. We use the sample scenario shown in Figure 3-2. This example was provided by a group at our school to a team of contractors as a test of their Web services and SOA middleware. Actual deployments will probably involve more complex arrangements than that shown in this figure, but it is unlikely that an application that is unable to deal with this simple case would be able to deal with more realistic configurations.
v
: Web service v : BPEL process Administrative domain A
Administrative domain B
Figure 3-2. Sample scenario consisting of two BPEL processes
The example comprises an SOA application consisting of two BPEL processes and three external Web services. The scenario has clients that invoke BPEL processes called “overtime process”, which is a workflow for processing overtime requests and comprises five activities (A1–A5). Note that each invocation instantiates a new instance of “overtime process” so that we can handle multiple requests from clients simultaneously. The “overtime process” invokes another BPEL process called
“personnel process”, which has five activities (B1–B5). Note that the “overtime process” and “personnel process” are maintained and executed in two different administrative domains in the same application5. The database, DB, is administrated by the domain A that the “overtime process” belongs to. An access control mechanism is necessary in this scenario since the owner of the “personnel process” needs to access database DB. For this discussion we assume that the three external Web services provide data mining services: they access database DB and report the mining results.
The “client” invokes the “overtime process” by offering personal information such
5 It is common for different services and workflow processes to be maintained by different administrative domains in SOA applications.
as the name, ID, and other information related to a request from an employee. The security requirements entail the following access control requirements. First, the
“register service” and “directory check service” are only allowed to access related data of a specified department6 of an employee in database DB when activities A2 and A3 are executing, respectively. Second, the “personnel service” is only allowed to access the personal information of an employee—when “personnel process” is executing. The ID or name of this employee is offered by the “client” when s/he starts an “overtime process”.
In this motivating example the access control has to be regulated once the BPEL process starts executing. This regulation should be synchronized with the execution of BPEL processes; this is a kind of WBDAC. Also, the access control depends on the information that the “client” provides when it starts executing the “overtime process”. Note that this information is stored in the state7 of the “overtime process”.
To conform with the access control requirements in this example, we need an access control model that can regulate the accesses according to the state of the workflow process.
An intuitive and traditional solution is to encode the access control requirements in the implementation of the workflow process. For example, in ABAC, many of the long-term policies for deciding if an access request should be granted are placed in the policy pool. For a particular access control requirement of some workflow processes, we may have to define a lot of roles with the permissions to access different parts of the data in DB and access rules which dynamically bind activities or workflow processes with different roles. We then add some long-term polices accordingly. After
6 Different process instances usually access related data of different departments.
7 A BPEL variable used to store information or data used in the business process. It can refer to a primitive xsd data type or a complex type [37].
that we add further activities to the workflow processes to send commands to the access control system in order to change some attributes8 dynamically, and these mutable attributes and added long-term policies including role definitions and access rules can be used by the resource management to decide if a request should be accepted. Note that these long-term policies are static polices because they stay in the policy pool even if the associated workflow processes are not executing. Referring to our motivating example, we should have roles with the permissions for accessing information of different departments and employees and access rules for synchronizing access controls with the execution of activities A2 and A3 and “personnel process”.
The large set of predefined roles and access rules required usually results in role and rule explosion.
Also, workflow processes usually have to be modified when the access control requirements are changed. This tight coupling between the workflow process and the required access control increases the cost of implementing and maintaining the SOA application. This provides the motivation to design an access control model that can separate the implementation of the SOA application and the access control requirements, so that the system designer should not need to change the implementation of the workflow when the access control policy is altered.
3-2. WBDAC model
WfMSs are software systems that support coordination and cooperation among members of an organization when they are performing complex business processes [49], which are modeled as workflow processes that are automated by the WfMS. The workflow model (also referred to as the workflow process definition) is the
8 They could be attributes of subjects, roles, objects, or the system [50].
computerized representation of the business process that defines its starting conditions, stopping conditions, activities, and control and data flows among the activities. An activity is a logic step within a workflow, which includes the information about the starting and stopping conditions, the users who are allowed to participate (the
participants), the tools and/or data needed to complete the activity, and the constraints
on how the activity should be completed. The activities in a process are usually organized into a directed graph that defines the order of their execution, where nodes and edges in the graph represent activities and control flow, respectively. A workflowprocess instance represents the state of execution of a workflow process definition by
the WfMS, and is usually controlled by the workflow engine.We propose using the WBDAC model to support a dynamic access control mechanism in an SOA. An SOA application initially consists of some workflow processes and standalone services, where any workflow can have multiple instances.
Since we want to specify the access control policy dynamically, we use the elaboration
time as a time-based descriptor in our policy specification. We define two types of
elaboration time. A process-based elaboration time is a three-tuple, (PRC, ACT, T), where PRC is the name or ID of a workflow process, ACT is one of the activities inPRC, and T is “after”, “before”, or “during”. A process-based elaboration time is used
to specify the time which is after, before, or during the execution of an activity in a workflow process. A usage-based elaboration time includes “before using (Tbefore)”,“after using (Tafter)”, or “during using (Tduring)”, which specify the time before, after, and during an interval of an event, respectively.
We define the reference environment of a workflow process instance at time t to be the run-time states that are visible at t and the result of flow controls in the execution of this workflow process before t ; note that t is a process-based elaboration
time. The reference environment at a specific time may contain information offered by participants of some activities and data mined from databases in previous executions of activities. The essential idea of WBDAC is for the system designer to specify how to create transient policies according to the reference environment of the workflow processes in certain situations. However, since a single workflow process can have multiple instances and different process instances usually have different execution statuses, it may be necessary to create different policies that will have different lifetimes. For example, in the motivating example presented in Section 3-1, we need to activate multiple instances of “overtime process” and “personnel process” as several clients may start the “overtime process” simultaneously. We need to enforce different access controls for “personnel service” executed by different “personnel processes” instances in this situation.
Based on previous definitions, we define that the policies of WBDAC are represented by a set of transient policy specifiers. A transient policy specifier is a four-tuple, (Pact, Pdeact, (t), ), comprising the following components:
P
act is a set of guards, that are used to specify whether the policy manipulation function, (t'), will be activated. A guard <p, t>, is a pair, where Boolean predicate p is evaluated at process-based time t. (t'), t't , is activated at time t', if any of the guards in Pact is evaluated as being True at time t. Pdeact has the same structure of Pact, and it will deactivate the policies which was produced by (t') when any of the guards in Pdeact is evaluated as being True at time t. If there is no Pdeact, all of the generated policies will be deactivated when the workflow instance terminates.
(t) is a process-based policy manipulation function, where t is a
process-based elaboration time. The activation of(t) produces a set of
transient policies according to the reference environment at t. These policies are stored in the policy pool for the access control. The deactivation of
(t)
revokes these policies.
is a set of actions. In WBDAC we do not restrict the form or type of
actions; the possible actions may involve updating mutable attributes of subjects and objects or even system attributes, creating objects, and deleting objects. An <a, t> is executed at time t, which is Tbefore, Tduring, or Tafter. If t =T
before, then a is executed before(t) is activated; if t = T
after, then a is executed after (t) is deactivated; while if t = Tduring, then a is executed after(t) is activated and before (t) is deactivated. The execution of a can
involve consulting the reference environment at the time when a is executing.In WBDAC we do not restrict the form or type of the set of policies generated by
In WBDAC we do not restrict the form or type of the set of policies generated by