A Faster Way to Temporarily Redirect the Role Based Access Control Workflow Processes Christine Liang

Transcription

1 A Faster Way to Temporarily Redirect the Role Based Access Control Workflow Processes Christine Liang ABSTRACT In recent years, many large organizations have used the Role Based Access Control (RBAC) Workflow Management System (WFMS) to manage their daily workflow. It allows the flow of work between individuals and/or departments to be clearly defined and tracked. Some of these workflow processes require human interactions, such as review/approval processes. If the specific reviewers or approvers are temporarily not available, because of sick days, business travel, vacation, etc., then these processes will be stuck in user accounts for days and may cost the company thousands or millions of dollars. This paper introduces a new temporary redirect method Acting and By- Direction, and demonstrates that this method is more efficient than the existing workflow redirect method. Keywords Workflow, Workflow Model, Workflow Management System, WFMS, Role Based Access Control, RBAC, temporary routing path, Flexible Process, Acting and By-Direction 1. INTRODUCTION Workflow Management Systems (WFMS) can be described as a technology that uses electronic systems to manage, monitor, and automate business processes. It allows the flow of work between individuals and/or departments to be clearly defined and tracked. Most of the workflow processes are developed with Role Based Access Control (RBAC) for security purposes [5]. Within a RBAC WFMS, every user is associated with one or more roles. The user s assigned roles indicate to the workflow system this user s privileges level and grants only permitted access to this user [4]. The simple and more understandable roles are often combined with organization roles (positions), departments, divisions, locations and more. Within organizations, and thus in workflow applications, the concept of a hierarchy of people/roles is prevalent. People are placed in one or more units such as department, divisions, or groups and they have different bosses, at different hierarchical levels [5]. There are also role hierarchies and permissions involved in the RBAC WFMS model [2]. Figure 1 shows a typical organizational structure. This structure clearly defines a chain of command (role hierarchies) within the organization, where the top-most role is the first in command, then the next in command is down one level, and so on. Workflow designers can use roles to specify the routing chains for the workflow process types as the example shows in Table 1. Figure 1. Organizational Structure example Table 1. Workflow processes specification example Process Types Routing Chains Employees=>Supervisors=>Managers Timecard Approval =>Time Keeping =>Accounting Employees=>Supervisors=>H.R. Maternity Leave =>Insurance =>Accounting Sick Leave (>5 Employees=>Medical Center days) =>Security=>Supervisors Purchase Order Employees=>Finance=>Purchasing Approval =>Accounting Business Travel Employees=>Supervisors=>Managers Reimbursements =>Finance=>Accounting Employees=>Supervisors=>Managers Educational =>Directors=>H.R.=>Finance Reimbursements Accounting A workflow process type is defined as a unique workflow process identifier that contains a unique routing chain. A routing chain is a list of pre-defined routing paths for a particular workflow process type, with a specific order. There are two basic types of order, sequential and parallel, as shown in Figures 2 and 3 respectively. A routing chain can be designed using sequential order, parallel order or the combination of both. Sequential order allows the workflow process instance to route to one node at a time. Figure 2 demonstrates the transitional states diagram for a sequential order workflow process instance. This instance of a workflow process type strictly follows the routing chain, starting from the first available node, then waiting for a response. If the response is a subset of {rejected, disapproved, timeout}, then the SB2-T1-1

2 workflow process instance stops and reaches an End state. If the response is in the subset of {accepted, approved}, the RBAC WFMS routes the workflow process instance to the next available node. 2. CURRENT WORKFLOW TEMPORARY REDIRECT METHOD In [1], the multi-agent based workflow management system provides some flexibility by guiding the end users to build valid workflow specifications at run time. It distributes the workload to the end users and allows them to redirect their workflow process instances. The workflow designer does not need to be aware of all of the semantics, all services offered by these workflow processes, or all steps or rules involved in the business process. The path can be virtually specified, since the physical path will be determined during the execution of workflow process instances. The creation of such models will still involve analysis of the actual processes in the organization, interviews with the users, etc., but it does not have to be as detailed as in the traditional workflows case. [1] This model provides a redirect method, but also increases the number of operations. Figure 2. Sequential order states graph A routing chain with parallel order allows the RBAC WFMS to route the workflow process instance to all nodes simultaneously. Figure 3 demonstrates the transitional states diagram for the parallel order workflow process instance. This workflow process instance reaches the End state only if all nodes have responded, or if a timeout occurs. For example, a theoretical company that has 10,000 employees is divided into 200 departments. Each department has about fifty people and three or four divisions. Supervisors are the division heads and managers are the department heads. In order for employees to get their paychecks, they are required to submit a timecard for approval each week. According to company policy, timecards have to be approved by a list of authorized personnel as shown in Table 2. Timecards are due before 2:00 p.m. every Monday. Late timecards are deferred to the next week. Table 2. Timecard Approval Personnel Example Sequence number Description 1 Submitter => any employee 2 Approver 1 => supervisor 3 Approver 2 => manager 4 Approver 3 => human resource 5 Approver 4 => time keeping 6 Approver 5 => accounting department Figure 3. Parallel order states graph Regardless of which order the routing chain follows, if one node is temporarily not available, then the workflow process instance is stuck until it reaches the timeout limit. Once the timeout occurs, the workflow process instance ends as incomplete. The end users have to resubmit the workflow process in order to complete the work. The existing workflow system provides a temporary redirect method described in Section 2. Section 3 introduces the new temporary redirect method. Section 4 demonstrates that the new redirect method is more efficient than the existing temporary redirect method. Section 5 discusses some related work. Section 6 concludes the paper and suggests future work. In this example, the workflow designers create a workflow process type: timecard approval process. This workflow process type has a unique sequential routing chain as shown in Table 2. During runtime, as soon as an employee submits a timecard approval process, a timecard approval process instance is created. Each workflow process instance has its individual routing path instance. The RBAC WFMS uses the submitter s information and follows the routing chain to determine the routing path for the particular workflow process instance. In this case, the RBAC WFMS uses the submitter s department and division to find the submitter s supervisor and routes the timecard approval process instance to the supervisor. Once the submitter s supervisor approves the timecard, the RBAC WFMS then uses the supervisor s information to find the appropriate manager, and so on. Since there are 200 departments and each department has three to four supervisors, there are a total of 600 to 800 supervisors and 200 managers. There is a good chance that one or more supervisors or managers will be temporarily out of the office. Assume that Department 001 s manager is on a business trip for two weeks. During these two weeks, Employee X is acting as SB2-T1-2

3 the manager of Department 001 for everyday business needs. However, the RBAC WFMS has no way to know that the manager of Department 001 is on travel, since he is a valid user in the system. According to the existing workflow redirect method [1], the end users (employees) can change the routing path for their workflow process instance at runtime. To complete the timecard approval process on time, all department 001 employees (about 50 of them) have to manually change their routing path to Employee X for every process instance. The total number of affected process instances for one workflow process type (timecard approval process) is: 50 process instances x 2 weeks = 100 process instances. End users must manually make the same routing path changes 100 times. If it takes at least one operation to change one workflow process instance s routing path, then 100 process instances require at least 100 operations to change the process instance s routing path. This example does not include Department 001 manager s involvement in other typical workflow process types (sick leave approval process, travel reimbursement process, educational reimbursement process, purchase requisition process, etc.). There could be hundreds or thousands of workflow process instances affected by this one person. Thus, the existing workflow redirect method requires at lease n operations (OP) to redirect n workflow process instances (WFPI). 3. THE NEW TEMPORARY REDIRECT METHOD: ACTING AND BY-DIRECTION This section introduces the Acting and By-Direction redirect method. The basic approach is to provide the temporary routing path before runtime. The key idea is to allow the unavailable node to specify a temporary substitute node to perform its duty. For instance, in the timecard approval example, if the RBAC WFMS allows the Department 001 manager to assign Employee X as his temporary substitute before he leaves, then all of his employees timecards will be automatically routed to Employee X. In fact, his employees do not need to perform any extra operation to change the instances of the routing chain for their timecards. Furthermore, when he returns from the trip, he can remove the temporary substitution. This new method, Acting and By-Direction, significantly reduces the total number of operations for redirecting the workflow process instances. Acting and By-direction can be described as authorization (permission) delegation. A delegator (a user or role that originally owns a set of permissions) authorizes a chosen person or role (the delegatee) to temporarily perform the workflow activities.. During the delegation, the delegator remains the authority to remove the delegation. There are two types of delegations possible in the RBAC Acting and By-Direction WFMS model: Acting A delegator (role/user) assigns all delegator s permissions to a specific delegatee (role/user). By-Direction A delegator (role/user) assigns a delegator s permission to a delegatee (role/user) for a specific workflow process. These Acting and By-Direction assignments are made before the workflow process instances are generated. During execution, the RBAC WFMS finds the delegatees and routes the workflow process instances to them. 3.1 Acting Assignments Acting assignment is a temporary assignment to an Actingdelegatee from the unavailable Acting-delegator. The Actingdelegatee temporarily takes over all the workflow process instances assignments from the unavailable Acting-delegator. As soon as an Acting assignment is initiated, all workflow process instances that are currently in the Acting-delegator s account are routed to the Acting-delegatee. In addition, any future workflow process instances generated during this Acting assignment period will also be routed to the Acting-delegatee. These temporarily redirected workflow process instances are known as Actinginstances. The RBAC WFMS tracks every workflow process Acting-instance and its history. When the Acting assignment is removed, all Acting-instances revert to the state they were in before the Acting assignment occurred Requirements for Acting Assignment Authorized users who have privileges to initiate Acting assignments are the Acting-delegators or workflow administrators. There is only one Acting assignment for one Acting-delegator. If the Acting-delegators are not available to authorize the Acting assignment, a workflow administrator should be able to initiate the Acting assignment for them. An Acting-delegator is permitted to assign only one Acting assignment. If they want to initiate another acting assignment, they have to remove the current Acting assignment first, and then reassign the Acting assignment. An Acting-delegatee can be defined as either a single user or a unique role. An Acting-delegatee must be different than the Acting-delegator. Furthermore, the Acting assignment permits a recursive relationship to enhance flexibility. As a result, a delegator can also be a delegatee for other acting assignments. Table 3 lists four different Acting assignments. Since recursive relationships are permitted, the final Acting-delegatee for User001 is User005 instead of User002. The RBAC WFMS routes all User001 workflow process instances to User005 instead of User002. Actually, in this example, all Acting-delegators (User001, User003, User002 and User004) have Acting assignments that point to the same final Acting-delegatee: User005. Therefore, all workflow processes instances for these Acting-delegators are eventually routed to User005. Table 3. Recursive Acting Assignments Example A Acting ID Acting-Delegators Acting-Delegatees 1 User001 User002 2 User003 User004 3 User002 User003 4 User004 User005 Example B (shown in Table 4) computes the same result as Example A: all Acting assignments are delegated to User005. SB2-T1-3

4 However, there are differences between these two examples. The key difference is that the Acting assignment in Example A indirectly delegates all the workflow process instances to User005. Example B directly assigns all the workflow process instances to User005. Each Acting assignment is an individual event, and can be removed at any time. If the Acting ID 2 assignment is removed from both examples A and B at the same time, then the resulting routing paths are different. In example A, both User001 and User002 are routed to User003 instead of User005; only User004 remains unchanged. In example B, all Acting-delegatees remain the same. Table 4. Recursive Acting Assignments Example B Acting ID Acting-Delegators Acting-Delegatees 1 User001 User005 2 User003 User005 3 User002 User005 4 User004 User By-Direction Assignments By-Direction assignments are similar to Acting assignments. The major distinction is that a By-Direction assignment only affects one specific workflow process type, whereas an Acting assignment affects all workflow process types associated with the delegator. Each By-Direction assignment must have a process type associated with it Requirements for By-Direction Assignment The authorized users who have the privileges to initiate By- Direction assignments are the By-Direction-delegators or workflow administrators. To initiate the By-Direction assignment, the By-Direction-delegator is required to select a workflow process type. In addition, the By-Direction-delegator must belong to the routing chain of the selected workflow process type. The By-Direction-delegator is permitted to assign only one By-Direction assignment for a workflow process type. Similar to the Acting requirements, a By-Direction-delegatee can also be defined as either a single user or a unique role. The By- Direction-delegatee must be different than the By-Directiondelegator within the same workflow process type. Furthermore, the By-Direction assignment permits a recursive relationship to enhance flexibility. As a result, a delegator can also be a delegatee from other By-Direction assignments for the identical workflow process type. Table 5 shows a recursive relationship from User003 (By-Direction ID 2) to User005 (By- Direction ID 4) for the Process Type ID BBX3. The RBAC WFMS routes all User003 s workflow process instances that are related to BBX3 to User005. Table 5. By-Direction Assignments Example By-Direction ID Process Type ID By-Direction Delegators By-Direction Delegatees 1 A001 User001 User002 2 BBX3 User003 User CC User002 User003 4 BBX3 User004 User005 5 BBX4 User002 User Combination of Acting and By-Direction Acting assignment is best if the delegator wants all workflow process types under his/her account temporarily transferred to another user/role. By-Direction assignment is best if only a few workflow process types need to be temporarily handled by someone else. Combining Acting and By-Direction assignments means that all temporarily redirected assignments can be accomplished under any circumstance Requirements for Acting and By-Direction Assignments By-Direction assignment always has a higher priority than Acting assignment. This means that if there is a By-Direction assignment and an Acting assignment for the same workflow process instance, the WFMS always accepts the By-Direction assignment and ignores the Acting assignment. When combining Acting and By-Direction assignments, two requirements from Sections and must be modified to avoid a circular relationship (endless loop): An Acting-delegatee must be different than the Actingdelegators and the By-Direction-delegators. The By-Direction-delegatee must be different than the By-Direction-delegators within the same workflow process type and the Acting-delegators. Figure 4 shows an example of Acting and By-Direction assignments. In this example, there are two By-Direction assignments (B1 and B2) and four Acting assignments (A1, A2, A3 and A4). B2 and A2 have the same delegator but different delegatees. So, when employees from department 021, division 011 start the RC_WPT_1 workflow process instances, the RBAC WFMS will find A2 and route the workflow process instances to the supervisor of department 021, division 012. If the same group of employees starts the RC_WPT_2 workflow process instances, the RBAC WFMS will use B2 instead of A2 and route the workflow process instances to the manager of department 021. Figure 4 Examples of Acting and By-Direction Assignments SB2-T1-4

5 3.4 Integrate with the RBAC WFMS Engine So far, we have presented the Acting and By-Direction redirect method and defined the Acting and By-Direction assignments. It is also necessary for the RBAC WFMS engine to recognize the Acting and By-Direction assignments and use them. In general, the RBAC WFMS engine routing process is described in following steps. 1. Submitter (end user) starts workflow process instance; 2. WFMS finds next_user based on the routing chain; 3. WFMS routes the process instance to next_user; 4. For parallel order, repeat steps 2 and 3 until the end of the routing chain is reached, then wait for all users responses. If all responses or a timeout is received, go to step 8. For sequential order, go to step 5; 5. Wait for user response; 6. If response is in the subset of {Accepted, Approved}, then go to step 7; 7. Check to see whether this is the last user in the routing chain. If yes, go to step 8; else go to step 2; 8. End the workflow process instance. The Acting and By-Direction functions can be inserted between steps 2 and 3 to find the actual routing path. Figure 5 shows the high-level Acting and By-Direction function. Figure 5. Acting and By-Direction Function As shown in step 2, the RBAC WFMS uses the routing chain to find the next user. This step is a required step for any existing RBAC WFMS. As soon as the next user is found, the Acting and By-Direction function is activated. The Acting and By-Direction function checks if a By-Direction assignment exists. If yes, it finds the By-Direction delegatee, replaces the next user with the By-Direction delegatee and continues with step 3. However, if no By-Direction assignment exists, it checks if there is an Acting assignment for the next user. If yes, it replaces the next user with the Acting-delegatee; else, the next user remains the same as it was in step 2. Using this technique, the RBAC WFMS engine always checks for Acting and By-Direction before it routes to the next user. Whether Acting and By-Direction assignments exist or not, the RBAC WFMS engine structure never changes. 4. COMPARING THE ACTING AND BY- DIRECTION METHOD TO THE EXISTING METHOD The scope of this paper includes proving that the Acting and By- Direction method is a faster way to temporarily redirect the RBAC workflow process. To determine if it is faster, the number of operations (OPs) used by the current redirect method (current) is compared to the Acting and By-Direction redirect method (new). We assume the following are valid: node Na within the routing chain of a workflow process type is temporarily unavailable for a period of time t. During t, node Nb will be temporarily substituted for Na. Within t, there are n workflow process instances (WFPIs) being generated and routed to Nb. Then the following is valid: new: since within t means from t_start until t_end, therefore 1 OP to generate Acting and By-Direction assignment at t_start + 1 OP to remove Acting and By-Direction assignment at t_end Total = 2 OPs from t_start to t_end current: Thus, the current workflow redirect method requires at lease n operations (OPs) to redirect n workflow process instances (WFPI). (from Section 2) Result: new: n WFPIs require 2 OPs to redirect n WFPIs from Na to Nb within t current: n WFPIs require n OPs to redirect n WFPIs from Na to Nb within t 5. RELATED WORK Many research projects [7, 8, 9, 10] are also focused on increasing the flexibility of the workflow management system. Combi and Pozzi [3] propose a workflow system that manages temporal aspects via a temporal database system, composed of a temporal layer on top of a relational DBMS. The adoption of a temporal database system will increase efficiency by allowing some additional features, such as the management of process model evolution and the selection of executing agents via a workload balance over time. Performance issues related to routing design are addressed in [6], which establishes a new routing control algorithm, Adaptive Routing Control (ARC), to find the efficient and flexible path of workflow. 6. CONCLUSION Using the result from Section 4, we can conclude that Acting and By-Direction is n/2 times faster than the current workflow redirect method when n>2. There is no way to determine the exact number of workflow process instances (n) that will be affected by the delegator before runtime. The worse case is that no workflow process instance is affected by the delegator. In that case, the Acting and By-Direction redirect method wastes two extra operations. That is a fairly small number compared to everyday flow of work between individuals. SB2-T1-5

6 In the near future, our interests are to make the Acting and By- Direction redirect method an independent, add-on workflow component. The focus will be the compatibility with the existing popular workflow management systems. It will increase the flexibility of all workflow management systems. Acting and By- Direction can be used in combination with the existing workflow redirect method. 7. REFERENCES [1] Deng, S.G., Yu, Z., Wu, Z.H., and Huang, L.C., Database theory, technology and applications (DTTA): Enhancement of workflow flexibility by composing activities at run-time, Proceedings of the 2004 ACM symposium on Applied computing, Mar [2] Botha, R.A., Eloff, J.H.P., Designing role hierarchies for access control in workflow systems, Computer Software and Applications Conference, PP , Oct [3] Combi, C., Pozzi, G., Database theory, technology and applications (DTTA): Architectures for a temporal workflow management system, Proceedings of the 2004 ACM symposium on Applied Computing, Mar [4] Dridi, F., Muschall, B., and Pernul, G., Administration of BBAC System, 2004 Big Island, Hawaii p. Proceedings of the 37th Annual Hawaii International Conference on System Sciences (HICSS'04) - Track 7, 70187b, Jan [5] Chaari, S., Biennier, F., Ben Amar, C., and Favrel, J., An authorization and access control model for workflow, First International Symposium on Control, Communications and Signal Processing, PP , [6] Yang, S.J., Design issues and performance improvements in routing strategy on the internet workflow, International Journal of Network Management, Vol. 13 Issue 5, Sept [7] Iwaihara, M., Jiang, H., and Kambayashi, Y., Organizational engineering (OE): An integrated model of workflows, e-contracts and solution implementation, Proceedings of the 2004 ACM symposium on Applied computing, Mar [8] Wainer, J., Bezerra, F., and Barthelmess, P., Coordination models, languages and applications (CM): Tucupi: a flexible workflow system based on overridable constraints, Proceedings of the 2004 ACM symposium on Applied computing, Mar [9] Zirpins, C., Lamersdorf, W., and Baier, T., Service composition: Flexible coordination of service interaction patterns, Proceedings of the 2nd international conference on Service oriented computing, Nov [10] Chinn, S., and Madey, G., Temporal representation and reasoning for workflow in engineering design change review Engineering Management, IEEE Transactions on Engineering Management, Volume: 47, Issue: 4, PP: , Nov SB2-T1-6