The first part of this dissertation presents how to implement the CWSM in a WfMS.
The CWSM, which is also called the Brewer and Nash model [13], and is constructed to provide information security or access controls that can change dynamically. This model was designed to provide controls that avoid conflict of interest (COI) in commercial organizations. Data are viewed in this model as consisting of objects that belong to particular companies. Access to particular parts of data is not constrained by their attributes but rather by what data the subject already holds access rights to. Note that the access related to read, write, or read-and-write operation. The company data set is categorized into mutually disjoint COI classes, as shown in Figure 2. For example, banks, oil companies, and airline companies belong to different COI classes, and the CWSM policy prohibits information flows from one company to another that cause COI.
Thus, if a subject accesses the information of bank B1, then s/he is not allowed to access information of other companies within the same COI class, such as that of bank B2 or Bi.
However, the subject can access information in another COI class, such as objects of oil company O1.
Company Information
Bank
B1 B2 Bi
1 2
Oil Company Other conflict of
interest class Conflict of interest class
…
Company data set
Individual objects
… O1 O2 … Oj
Airline Company
A1 A2 … Ak
1 2
Figure 2. Examples of company information for the CWSM
The CWSM proposes the following mandatory read and write rules:
BN read rule: Subject S can read object O only if O is from the same company information as some object read by S, or O belongs to a COI class within which S has not read any object.
BN write rule: Subject S can write object O only if S can read O by the BN read rule, and no object can be read that is within a different company data set from the one for which write access is requested.
Many access control mechanisms have been proposed and implemented. Access control is traditionally implemented using an access control matrix (ACM), in which an access request from a subject can be granted if the requested access right is recorded in the matrix [14]. The role-based access control (RBAC) model is regarded as a neutral policy and has been the most popular security model in recent years [15]. Data access is
restricted to authorized users in this approach, and it represents a newer alternative approach to mandatory access control and discretionary access control [14]. 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 operations. RBAC has been applied to access control in WfMSs [16,17,18,19]. Although RBAC has been successful in various applications, we have found it to be difficult for conducting higher level access control such as the CWSM in WfMSs. When the company information used in a workflow process is static, then RBAC can implement the BN read rule. However, RBAC has problems in implementing the BN read rule if the company information is dynamic. There are at least two cases to consider. The first case is where the same workflow definition uses different company information. Although we know the structure of the company information, we need to design different codes to apply RBAC to them. The second case is where the company information may be created or updated dynamically during the execution of the workflow process. In this case the code for implementing RBAC need to bind subject to objects dynamically. A lack of knowledge of the COI class and company data set prior to executing the workflow process makes it impossible to design the code for operating RBAC in advance. In the second situation we need to apply the BN write rule during the execution of the workflow process.
Because the application of the BN write rule requires the use of the object access history and the company information to decide if permission for a write operation should be granted, it is impossible to implement the BN write rule purely in RBAC without storing the object access history and the company information in the workflow engine. The
main factor making RBAC difficult to implement CWSM is access permission in RBAC being controlled by the binding relationships among subjects, roles, and objects.
However, access control in the CWSM depends on the object access history and company information to determine if an access request should be granted. Section 3.1 provides several examples to illustrate these two situations.
In this dissertation we show how to implement the CWSM in a WfMS. It is obvious that we should solve the problems that cannot be solved by the popular RBAC model.
Our solution is to design an API that allows the system developer to specify the CWSM policy in a WfMS. The proposed API is designed to satisfy the following dynamic security requirements for the CWSM:
1. Dynamic binding between subjects and companies: The binding of a subject and a company can be dynamically implemented during the workflow execution. For example, according to the company information shown in Figure 2, if a subject requests access to objects of bank B1 and this access is successful, then s/he is bound to B1. This is the basic requirement that makes the information security access controls of the CWSM able to change dynamically.
2. Dynamic company information manipulation: The company information should be able to be created, chosen, or updated dynamically during the workflow execution.
As a result, the same workflow definition can use different company information.
3. Privileged subject management: The binding of subjects to company information can be controlled during the execution of the workflow process. In some applications, not all data accesses of the participants in a WfMS should be controlled by the CWSM.
4. Temporal-based enforcement: The time or duration when the CWSM policy is applied should not be static. In some situations, we may want to set up the CWSM policy to be applied only on part of the activities in a workflow process.
In general, implementing the CWSM should depend on the dynamic behavior of the workflow process. That is, it should be possible to synchronize operations related to the CWSM policy with the progression of the workflow process. This enhances the flexibility of the CWSM because our framework synchronizes access control with the execution of WfMSs. By using the proposed API, the workflow engine creates data access history tables that store dynamic data accesses performed by subjects. Instead of specifying each data access according to the company information, the workflow engine consults the data access history tables and company information to control the data access so as to implement the CWSM security requirement.