API to Specify the Security Policy for the CWSM in WfMSs

As discussed in Section 3.1, specifying a CWSM policy in RBAC is complicated by the need to set up sophisticated role assignments based on the company information and subjects that are required to be involved in the security framework. A convenient way to solve this problem would be to control the read/write access to objects issued by all the subjects involved in a WfMS according to all the available company information automatically. However, this method does not work in a WfMS. In the motivation example shown in Figure 5, Leo is responsible for the work distribution in activity A. It is obvious that Leo should be able to access objects of all companies to perform his task in this business process. If the CWSM of company information CI1 is applied to Leo, then he will not be able to perform his task in activity A. It is obvious that Leo needs to refer to data objects of all three companies to distribute work related to the three companies to John, Mary, and Ken. The examples shown in Section 3.1 provide the motivation to design an API to specify security policy based on the CWSM for WfMSs.

First of all, we should be able to bind the subjects to certain company information, which is a basic operation in the CWSM. We should then be able to control when the CWSM associated with the binding starts or ceases. Also, applying the CWSM can be synchronized with the progress or the dynamic behavior of the WfMS. We call this API the “Chinese Wall Security Policy Specification API for WfMS” (CWSPS API).

We use the Backus Naur Form [108] to show the syntax of the CWSPS API (see Figure 10A). Note that all the nonterminal symbols in the figure are underscored.

There are several types of commands in the CWSPS API:

 LoadCompanyInformation (line 5): Company information that will be used should first be loaded into the workflow engine. Since company information can be represented by a tree data structure, we propose storing the company information in an XML document since such a document intrinsically has a tree data structure [109].

An example of an XML document that represents company information is shown in Figure 10B. Line 1 in Figure 10C shows an example of a LoadCompanyInformation statement. Note that variable CI1 now represents an entity of the company information.

 Subject and company information binding (line 6): This statement binds a group of subjects to a set of company information. The binding is assigned to a variable that is subsequently used to start or cease the associated CWSM policy; see line 3 in Figure 10C.

 Subject and company information ignore (line 8): We assume that all the accesses to objects should be controlled by the workflow engine. However, if the designer wants some subjects not to be controlled by the CWSM, s/he can set these subjects to be able to perform read and write operations to objects contained in certain sets of company information without limitation.

 EnforceCWSM (line 10): This starts a CWSM policy according to a binding defined in a Subject and company information binding or Subject and company information ignore statement.

 CeaseCWSM (line 11): This stops the execution of a CWSM policy according to a binding defined in a Subject and company information binding or Subject and company information ignore statement.

 TouchR (line 12): This command has two parameters, SubjectName and CompanyName, and sets the status of individual objects of company CompanyName as having been read by subject SubjectName.

 TouchRW (line 13): This command is very similar to TouchR, setting the status of individual objects of company CompanyName as having been read and written by subject SubjectName.

 CheckR (line 14): This command has two parameters, SubjectName and CompanyName, and is used to check if subject SubjectName should be granted permission to read objects of company CompanyName.

 CheckRW (line 15): This to used to check if subject SubjectName should be granted permission to read and write objects of company CompanyName.

(A)

1. CWSPSAPI statements 

2. LoadCompanyInformation | Subject and company information binding |

3. Subject and company information ignore | EnforceCWSM | CeaseCWSM |

4. EnforceCWSM | CeaseCWSM | TouchR | TouchRW | CheckR | CheckRW

5. LoadCompanyInformation  CompanyInformationName = LoadCompanyInformation(URL_Address)

6. Subject and company information binding 

7. Var = CWSM (CompanyInformation(CompanyInformationName

{,CompanyInformationName}), Subject(SubjectName {, SubjectName });

8. Subject and company information ignore 

9. Var = CWSMIgnore (CompanyInformation(CompanyInformationName

{,CompanyInformationName}), Subject(SubjectName {, SubjectName });

10. EnforceCWSM  Enforce(Var, {Var });

11. CeaseCWSM  Cease(Var, {Var });

12. TouchR  TouchR(SubjectName, CompanyName);

13. TouchRW  TouchRW(SubjectName, CompanyName);

14. CheckR  CheckR(SubjectName, CompanyName);

15. CheckRW  CheckRW(SubjectName, CompanyName);

16. CompanyInformationName  StringWithoutWhitespace

17. SubjectName  StringWithoutWhitespace

18. Var  StringWithoutWhitespace

19. CompanyName  StringWithoutWhitespace

20. URL_Address  StringWithoutWhitespace

(B)

<?xml version="1.0" encoding="UTF-8"?>

<CompanyInformation>

<COI_Class Name="Bank">

<CompanyDataSet CompanyName="B1">

<Object Name="B1_Data_1"/>

<Object Name="B1_Data_2"/>

</CompanyDataSet>

<CompanyDataSet CompanyName="B2">

<Object Name="B2_Data_1"/>

<Object Name="B2_Data_2"/>

</CompanyDataSet>

</COI_Class>

<COI_Class Name="Oil Company">

<CompanyDataSet CompanyName="O1">

<Object Name="O1_Data_1"/>

<Object Name="O1_Data_2"/>

</CompanyDataSet>

<CompanyDataSet CompanyName="O2">

<Object Name="O2_Data_1"/>

<Object Name="O2_Data_2"/>

</CompanyDataSet>

3. b1=CWSM(CompanyInformation(CI1, CI2), Subject(John, Mary, Ken));

4. Enforce(b1);

(D)

/*CWSPS API statements executed in activity A*/

1. CI =

LoadCompanyInformation(CompanyInformationProcessedByWfProcess());

2. ignore=CWSMIgnore(CompanyInformation(CI), Subject(Leo));

3. Enforce(ignore);

4. PerformWorkDistribution();

5. binding=CWSM(CompanyInformation(CI), Subject(John, Mary, Ken));

6. Enforce(binding);

7. If (!TouchR(John, CompanyAssignedTo(John)) ReportError();

8. If (!TouchR(Mary, CompanyAssignedTo(Mary)) ReportError();

9. If (!TouchR(Ken, CompanyAssignedTo(Mary)) ReportError();

/*CWSPS API statements executed in activity Z*/

10. Cease(ignore);

11. Cease(binding);

(E)

/*CWSPS API statements executed after activity A*/

1. CompanyInformationCreatedByLeo =PrepareCompanyInformation();

2. CI = LoadCompanyInformation (CompanyInformationCreatedByLeo);

3. ignore=CWSMIgnore(CompanyInformation(CI), Subject(Leo));

4. Enforce(ignore);

5. binding=CWSM(CompanyInformation(CI), Subject(John, Mary, Ken));

6. Enforce(binding);

/*CWSPS API statements executed after activities B, C, or D*/

7. Lock(S);

8. cmp=ChooseCompany(CI);

9. TouchR(mySubject(),cmp);

10. Unlock(S);

11. PerformCompanyDataProcess(cmp);

12. /*CWSPS API statements executed in activity Z*/

13. Cease(ignore);

14. Cease(binding);

Figure 10. The Backus Naur Form of the CWSPS API and some examples

The CWSPS API statements are used to set up the CWSM policy of a workflow process. We assume that the scripts written in the CWSPS API are embedded in the execution code of activities, so that access control based on the CWSM can be synchronized with the progress of the workflow process. This means that these scripts may be executed during the execution of workflow processes. The statements

“b1=CWSM(CompanyInformation(CI1), Subject(John, Mary, Ken)); Enforce (b1);” specify enforcing the BN read and write rules to subjects John, Mary, and Ken according to company information CI1 as shown in Figure 5. We can easily change the associated company information to CI2 using the statements

“b2=CWSM(CompanyInformation(CI2), Subject(John, Mary, Ken)); Enforce (b2);”. Also, we can specify to apply multiple sets of company information to the same group of subjects as shown in Figure 10C. The CWSPS API code in Figure 10D show how to specify the security policy for the first motivation example shown in Section 3.1 The statement in line 1 first retrieves the company information used in the workflow

process. We assume that the routine

“CompanyInformationProcessedByWfProcess()” generates the information of a company. Second, lines 2 and 3 use the command “CWSMIgnore()” to instruct the system to grant permission for any access requests of objects that are included in

company information CI to Leo. Leo then performs work distribution in line 4. Lines 5 and 6 specify the data accesses of three subjects to be controlled by the company information CI. Finally, lines 7, 8, and 9 set up the statuses of individual objects in the company information according to the work distribution performed by Leo.

The CWSPS API code in Figure 10E show how to specify the security policy for the second motivation example described in Section 3.1. First, in line 1 Leo prepares the company information for several companies, and lines 2 to 6 specify the appropriate security policy between subjects Leo, John, Mary, and Ken, and company information CI. The above statements are executed in activity A. The code that need to be executed in activities B, C, and D are identical. Line 7 first locks a semaphore S to ensure that lines 8 and 9 are a critical section. Line 8 selects a company for the subsequent processing, lines 9 grants the subject access rights for objects of the chosen company, and line 10 unlocks the semaphore. Finally, the actual company data process can be performed. Note that the correctness of the code does not depend on the number of companies in the dynamically created company information.

We now describe how the CWSPS API satisfies the four dynamic security requirements mentioned in Section 1.2. First, the TouchR and TouchRW statements can be used for requirement 1. When the workflow process decides to bind a subject to an element in the company data set, the execution of TouchR or TouchRW achieves the binding. Requirement 2 can be satisfied by using the LoadCompanyInformation statement. The workflow process can prepare the company information in some activities and then execute this statement to load the information of a company to start CWSM-based access control. It is obvious that the workflow process can choose among

several sets of company information before it starts access control. Requirement 3 can be met by the Subject and company information binding and Subject and company information ignore statements. As long as the two statements can be embedded in the execution code of the activities, we can dynamically set up the access of objects contained in the company information by the specified subjects to be controlled or ignored. Finally, requirement 4 is satisfied by EnforceCWSM and CeaseCWSM statements, since it can control when to start or cease the CWSM-based access control specified by the programmer. The CWSPS API statements are generally designed to be embedded in the execution code of the workflow process. Thus, we can manipulate CWSM-based access control according to the dynamic behavior of the workflow process.

52