Inter-Instance Authorization Constraints for Secure Workflow Management

1

Inter-InstanceAuthorization Constraints for

SecureWorkflow Management

Janice Warner and Vijay AtluriJanice Warner and Vijay AtluriCIMIC and MSIS Department, Rutgers UniversityCIMIC and MSIS Department, Rutgers University

{janice,atluri}@rutgers.edu{janice,atluri}@rutgers.edu

SACMAT ’06SACMAT ’06

June 9, 2006June 9, 2006

©Vijay Atluri June 9, 2006 2

OutlineOutline• IntroductionIntroduction

WorkflowsWorkflows Authorization ConstraintsAuthorization Constraints

• MotivationMotivation• Related WorkRelated Work• Inter-instance Authorization Constraint Inter-instance Authorization Constraint

ModelModel• Constraint ProcessingConstraint Processing

Consistency CheckingConsistency Checking Anomaly RectificationAnomaly Rectification Task AssignmentTask Assignment


WorkflowWorkflow• Set of coordinated activities (tasks) to achieve a Set of coordinated activities (tasks) to achieve a

common business objectivecommon business objective• Used in numerous application domainsUsed in numerous application domains

Office AutomationOffice Automation Finance and bankingFinance and banking Web-servicesWeb-services Healthcare, …Healthcare, …

• Tasks are carried out by agents according to a Tasks are carried out by agents according to a set of organizational rules set of organizational rules

• SchemaSchema The specification of tasks and control flow The specification of tasks and control flow

requirementsrequirements• Workflow InstanceWorkflow Instance

Generated when a workflow is executedGenerated when a workflow is executed Tasks are assigned to users based on roles and the Tasks are assigned to users based on roles and the

other (security) policies other (security) policies


Authorization ConstraintsAuthorization Constraints• Purpose is to mitigate fraud and collusion Purpose is to mitigate fraud and collusion

among users among users • In a workflow environment In a workflow environment Forbid users or Forbid users or

roles from performing certain task(s)roles from performing certain task(s)

Preparecheck

Approvecheck

issuecheck

Check Processing Workflow

clerkclerk

manager

“prepare check” and “issue check” should not be executed by thesame user


Authorization ConstraintsAuthorization Constraints• Intra-instance ConstraintsIntra-instance Constraints

specified on a workflow schema and therefore apply to a single instance

Static: can be enforced at the time of schema specification

Dynamic: can only be enforced at run-time

• Inter-instance ConstraintsInter-instance Constraints specified on instances rather than on the workflow

schema Can be specified on multiple instances of the same

workflow that can only be enforced at run-time can be specified on the history of instances and

therefore are not necessarily limited to one workflow Other purposes

• workload and resource distribution


Need for Inter-instance ConstraintsNeed for Inter-instance Constraints• Prevent collusionPrevent collusion

Approve each others loans!!Approve each others loans!!• Prevent fraud over timePrevent fraud over time

Approve large amount of loans in a dayApprove large amount of loans in a day

• BindingBinding Exploit the experience: An individual should be Exploit the experience: An individual should be

assigned to a task because of previous experience assigned to a task because of previous experience with conducting that taskwith conducting that task


Example Bank Loan Approval ProcessExample Bank Loan Approval Process

Prevent collusion Prevent collusion • Two critical tasks can only be performed by the Two critical tasks can only be performed by the

same group of people three times.same group of people three times.

• There should not exist a group of n (say 2) users There should not exist a group of n (say 2) users

represented by G and m instances (say 4) such that represented by G and m instances (say 4) such that

if tif t11 is executed by a user in G, t is executed by a user in G, t22 is executed by the is executed by the

remaining users in G in more than m instances.remaining users in G in more than m instances.

t 1: Enter LoanApplication

t 2: AccountManagerApproval

t 3 VP Approval

t 4 Issue Check

Loan Amount >= $100K

Loan Amount < $100K


Example Bank Loan Approval ProcessExample Bank Loan Approval Process

• Prevent fraud over timePrevent fraud over time:: A user is not allowed to do tA user is not allowed to do t22 if the total loan amount per day if the total loan amount per day

exceeds $1M.exceeds $1M. There should not exist more than one instance of W such that the There should not exist more than one instance of W such that the

input parameters (say loan customer) is the same and the loan input parameters (say loan customer) is the same and the loan amounts sum up to $100K during a period of one month.amounts sum up to $100K during a period of one month.

There should not exist more than 4 instances of W such that a There should not exist more than 4 instances of W such that a specific input parameter (say loan customer) is the same and the specific input parameter (say loan customer) is the same and the user executing tuser executing t22 is also the same. is also the same.

A user is not allowed to execute more than 100 tasks (of any A user is not allowed to execute more than 100 tasks (of any workflow) in a day.workflow) in a day.

t 1: Enter LoanApplication

t 2: AccountManagerApproval

t 3 VP Approval

t 4 Issue Check

Loan Amount >= $100K

Loan Amount < $100K


Our GoalOur Goal• Assign users/roles to tasksAssign users/roles to tasks

By adhering to both intra-instance and inter By adhering to both intra-instance and inter instance authorization constraintsinstance authorization constraints

Identify/rectify certain anomaliesIdentify/rectify certain anomalies• InconsistencyInconsistency• Overlapping anomalyOverlapping anomaly• Depletion anomaly Depletion anomaly


Related WorkRelated Work• Bertino, Ferrari, Atluri (BFA) Model, RBAC 97, TISSEC 1999Bertino, Ferrari, Atluri (BFA) Model, RBAC 97, TISSEC 1999

enables specification of separation of duties and proposes methodologies enables specification of separation of duties and proposes methodologies to analyze their consistency to analyze their consistency

not capable of distinguishing one instance from the other, and therefore not capable of distinguishing one instance from the other, and therefore cannot model inter-instance constraints cannot model inter-instance constraints

Extend the specification language of the BFA model to handle inter-Extend the specification language of the BFA model to handle inter-instance constraints as well as handle conditions on temporal and instance constraints as well as handle conditions on temporal and workflow parametersworkflow parameters

• Crampton et al., SACMAT 2005 and IEEE Computer Security Crampton et al., SACMAT 2005 and IEEE Computer Security Foundations Workshop, 2004Foundations Workshop, 2004 Alternative authorization model to which our inter-instance constraint Alternative authorization model to which our inter-instance constraint

ideas could also applyideas could also apply• Botha and Eloff, IBM Systems Journal 2001Botha and Eloff, IBM Systems Journal 2001

Introduced concept of constraining authorization based on conflicting Introduced concept of constraining authorization based on conflicting users, tasks, roles, permissions, but does not handle inter-instance users, tasks, roles, permissions, but does not handle inter-instance constraintsconstraints

• Atluri, Bertino, Ferrari and Mazzoleni, IFIP03 Atluri, Bertino, Ferrari and Mazzoleni, IFIP03 Considered delegation rules (in addition to the SOD constraints)Considered delegation rules (in addition to the SOD constraints)

• Atluri, Warner, SACMAT 05Atluri, Warner, SACMAT 05 Considered conditional delegation, role activation and workflow Considered conditional delegation, role activation and workflow

dependency requirements (in addition to the above)dependency requirements (in addition to the above)


Constraint Specification Constraint Specification LanguageLanguage

• Constants Constants Temporal and workflow constants, users, roles, tasks, task Temporal and workflow constants, users, roles, tasks, task

instancesinstances• VariablesVariables

temporal variables, workflow input and output variables, temporal variables, workflow input and output variables, role and user variables, task and task instance variablesrole and user variables, task and task instance variables

• Predicates Predicates External Specification PredicatesExternal Specification Predicates Workflow Specification PredicatesWorkflow Specification Predicates Enforcement PredicatesEnforcement Predicates Status PredicatesStatus Predicates Conditional PredicatesConditional Predicates Comparison PredicatesComparison Predicates

• RulesRules


PredicatesPredicates• External Specification PredicatesExternal Specification Predicates

related(urelated(uii, u, ujj))

partner-of (upartner-of (uii, u, ujj))

same-group(usame-group(uii, u, ujj))

• Workflow Specification PredicateWorkflow Specification Predicate role(Rrole(Rii,t,tjj))

user(uuser(uii,t,tjj))

belong(ubelong(uii,R,Rjj))

....

critical-task-pair(tcritical-task-pair(tii, t, tjj))


PredicatesPredicates• Enforcement PredicatesEnforcement Predicates

cannot_docannot_douu(u(uii, t, tjj), ), cannot_docannot_douu(u(uii, t, tjjkk))

cannot_docannot_doRR(R(Rii, t, tjj), ), cannot_docannot_doRR(R(Rii, t, tjjkk))

must_executemust_executeRR(R(RBB, t, t22), ), must_executemust_executeRR(R(RBB, t, t22kk))

must_executemust_executeRR(R(RBB, t, t22), ), must_executemust_executeRR(R(RBB, t, t22kk))

abort(W), abort(W), abortabort(t(tjjkk))

• Status PredicatesStatus Predicates executedexecutedu u (u(uii, t, tjj

kk)) executed executedRR(R(Rii, t, tjjkk))

assignedassignedu u (u(uii, t, tjjkk))

succeeded succeeded (t(tijijkk))

aborted aborted (t(tijijkk))

collaborator(ucollaborator(uii, u, ujj))


PredicatesPredicates• Conditional PredicatesConditional Predicates

count and count and countcountnvnv

min, max, sum and avgmin, max, sum and avg

timestamp(timestamp(ttiikk,ts),ts)

time-interval(time-interval(ttiikk, t, tjj

ll))

• Comparison PredicatesComparison Predicates


Constraint specificationConstraint specification• A user is not allowed to do tA user is not allowed to do t22 if the total if the total

loan amount per day exceeds $1M.loan amount per day exceeds $1M.cannot_docannot_douu(u(uii, t, t22

kk) ) i, i, time-intervaltime-interval(t(t22kk, t, t22

ii) < “24 hours”, ) < “24 hours”,

sumsum(i, ((i, (outputoutput(t(t22ii).loan-amount), n)), n > $1M).loan-amount), n)), n > $1M

refers to a task in an instance of a workflow

Predicate provides timebetween two instancesof a task.

Parameters of workflowUsed in specifying constraints


Constraint specificationConstraint specification• There should not exist more than 4 There should not exist more than 4

instances of W such that the loan instances of W such that the loan customer is the same and the user customer is the same and the user executing texecuting t22 is also the same. is also the same.

cannot_docannot_douu(u(ujj, t, t22kk) ) i, i, countcountnvnv(u(ujj, executed, executeduu(u(ujj,t,t22

ii), n), n> 4, ), n), n> 4,

inputinput(t(t22ii).loan-customer = ).loan-customer = inputinput(t(t22

kk).loan-customer ).loan-customer

Counts number of different answers to query


Constraint specificationConstraint specification• There should not exist a group of n (say There should not exist a group of n (say

2) users represented by G and m 2) users represented by G and m instances (say 4) such that if t1 is instances (say 4) such that if t1 is executed by a user in G, texecuted by a user in G, t22 is executed by is executed by

the remaining users in G in more than m the remaining users in G in more than m instances.instances.

cannot_docannot_douu(u(uii, t, t22) ) (( ((countcount ((collaboratorcollaborator(u(uii, u, ujj), n), n = 3, ), n), n = 3,

executedexecuteduu(u(ujj, t, t11); );

cannot_docannot_douu(u(uii, t, t11) ) (( ((countcount ((collaboratorcollaborator(u(uii, u, ujj), n), n = 3, ), n), n = 3,

executedexecuteduu(u(ujj, t, t22); );

Indicates when users uii and ujj have executed tasks identified as being critical task pairs.


Constraint SpecificationConstraint Specification• The set of all constraints: CBThe set of all constraints: CB• More than one rule may be used to More than one rule may be used to

specify a constraintspecify a constraint• We can prove that CB is a stratified We can prove that CB is a stratified

normal programnormal program


Constraint AnomaliesConstraint Anomalies• InconsistencyInconsistency• Overlapping anomalyOverlapping anomaly• Depletion anomalyDepletion anomaly


InconsistencyInconsistency• Results from a conflict in the constraint base. Results from a conflict in the constraint base.

Due to one set of rules, a user must perform a taskDue to one set of rules, a user must perform a task due to another set of rules, a user is denied authority due to another set of rules, a user is denied authority

to perform the same task.to perform the same task.• There exist some users that are allowed to do a There exist some users that are allowed to do a

task as well as not allowed to do a tasktask as well as not allowed to do a task Checked statically by calculating the sets of Checked statically by calculating the sets of

roles/users that must be prevented from executing roles/users that must be prevented from executing task ttask tii and the set of roles/users permitted to execute and the set of roles/users permitted to execute task ttask tii and comparing them and comparing them

• Denied_UsersDenied_UsersSS, Denied_Roles, Denied_RolesSS, Permitted_Users, Permitted_UsersSS, and , and Permitted_RolesPermitted_RolesSS

If constraints concerning task instance tIf constraints concerning task instance tiikk depend upon depend upon

run-time parameters or conditions, new sets are run-time parameters or conditions, new sets are calculated at run-timecalculated at run-time

• Denied_UsersDenied_UsersRR, Denied_Roles, Denied_RolesRR, Permitted_Users, Permitted_UsersRR, and , and Permitted_RolesPermitted_RolesRR


Overlapping AnomalyOverlapping Anomaly• arises when the conditions for one arises when the conditions for one

constraint overlap with the conditions for constraint overlap with the conditions for another constraintanother constraint [30,40][20,50]; x>50,x>100[30,40][20,50]; x>50,x>100 Can be handled before workflow is instantiated Can be handled before workflow is instantiated

by matching the conditionsby matching the conditions If the result of the conflicting constraints is the If the result of the conflicting constraints is the

same, the less restrictive condition can be same, the less restrictive condition can be tightened.tightened.

If the result of the conflicting constraints is If the result of the conflicting constraints is opposite, additionally we have an opposite, additionally we have an inconsistency and the conditions must be inconsistency and the conditions must be made not to overlapmade not to overlap

• cannot_do[30,40],must_execute[20,50]cannot_do[30,40],must_execute[20,50]


Depletion AnomalyDepletion Anomaly• arises when due to previous assignments to arises when due to previous assignments to

tasks and workflow instances, there is no tasks and workflow instances, there is no one with the rights to complete particular one with the rights to complete particular tasks in current instances.tasks in current instances. Static depletion anomaly is easily detected when Static depletion anomaly is easily detected when

the sets of permitted users/roles contain no the sets of permitted users/roles contain no members.members.

• Empty Permitted_UsersEmpty Permitted_UsersSS and Permitted_Roles and Permitted_RolesSS

• can be rectified by modifying constraints.can be rectified by modifying constraints.

Conditional depletion anomaly occurs during run-Conditional depletion anomaly occurs during run-time when due to conditions and previous time when due to conditions and previous assignments, there is temporarily or permanently assignments, there is temporarily or permanently no one who can be assigned to a taskno one who can be assigned to a task

• Empty Permitted_UsersEmpty Permitted_UsersRR and Permitted_Roles and Permitted_RolesRR


Anomaly Detection and Task AssignmentAnomaly Detection and Task Assignment

Step 1 – Static Enhancement of CB

When Workflow Schema is Defined

Step 2 – Static Inconsistency

Identification and Analysis

Step 3 – Run-TimeInconsistency

Identification and Analysis

Step 4 – Run-timeUpdating of CB if

Conditions Warrant it.

Workflow Schema Defined Task Instance

Step 1 - Performed when workflow is defined.Step 2 – Performed when workflow is defined and when new rules are added.Step 3 – Performed whenever a task instance is initiated if there are constraint conditions met

by the parameters of the instance.Step 4 – Performed whenever assignments made will constrain assignments for future

instances of the workflow.


Step 1 – Static Enhancement of Step 1 – Static Enhancement of CBCB

• Derivation Rules are Applied:Derivation Rules are Applied: executed(uexecuted(uii, t, tjj

kk) ) assigned(u assigned(uii, t, tjjkk), succeeded(t), succeeded(tjj

kk))

collaborator(ucollaborator(uii, u, ujj) ) critical-task-pair(t critical-task-pair(tsjsj, t, tsksk), ), executed(uexecuted(ui,i, t tsjsj

mm), executed(u), executed(ui,i, t tskskmm))

related(urelated(uii, u, ujj) ) related(u related(uii, u, ukk), related(u), related(ukk, u, ujj) , u) , ui i

u ujj u ukk

partner_of(upartner_of(uii, u, ujj) ) partner_of(u partner_of(uii, u, ukk), ), partner_of(upartner_of(ukk, u, ujj) , u) , ui i u ujj u ukk

critical-task-pair(tcritical-task-pair(tijij, t, tikik) ) critical-task-pair(t critical-task-pair(tijij, t, tilil), ), critical-task-pair(tcritical-task-pair(tilil, t, tikik) , t) , tij ij t tilil t tikik

• Overlapping anomalies are rectifiedOverlapping anomalies are rectified


Step 2 – Static Anomaly Identification and Step 2 – Static Anomaly Identification and RectificationRectification

• Constraints that do not have run-time Constraints that do not have run-time conditions (Static Constraints) are conditions (Static Constraints) are separated from those that do separated from those that do (Conditional Constraints).(Conditional Constraints).

• For each task, the static constraints are For each task, the static constraints are applied to calculate the following sets: applied to calculate the following sets: Denied_UsersDenied_UsersSS, Denied_Roles, Denied_RolesSS, ,

Permitted_UsersPermitted_UsersSS, and Permitted_Roles, and Permitted_RolesSS

• If intersections between the denied and If intersections between the denied and permitted user/role sets, the schema is permitted user/role sets, the schema is inconsistent under any conditions and inconsistent under any conditions and must be modified.must be modified.


Step 3 – Run-time Anomaly Identification and Step 3 – Run-time Anomaly Identification and RectificationRectification

• Only occurs when a workflow task is instantiated Only occurs when a workflow task is instantiated that has conditional constraintsthat has conditional constraints If it does not, assignments are made using the If it does not, assignments are made using the

calculated sets Permitted_Userscalculated sets Permitted_UsersSS and Permitted_Roles and Permitted_RolesS.S.

• Real-time conditions are used to calculate Real-time conditions are used to calculate Denied_UsersDenied_UsersRR, Denied_Roles, Denied_RolesRR, , Permitted_UsersPermitted_UsersRR, and Permitted_Roles, and Permitted_RolesRR

• If inconsistencies or depletion anomalies are If inconsistencies or depletion anomalies are discovered, a system-specific rectification is discovered, a system-specific rectification is made.made.

• Otherwise, assignments are made from the Otherwise, assignments are made from the calculated sets Permitted_Userscalculated sets Permitted_UsersRR and and Permitted_RolesPermitted_RolesRR..


Step 4 – Ongoing Update of Step 4 – Ongoing Update of CBCB

• As tasks complete their execute, new As tasks complete their execute, new rules or modified rules are created when rules or modified rules are created when conditional constraints are met.conditional constraints are met. Added to make the computation of the sets of Added to make the computation of the sets of

Denied_UsersDenied_UsersRR, Denied_Roles, Denied_RolesRR, , Permitted_UsersPermitted_UsersRR, and Permitted_Roles, and Permitted_RolesR R more more efficient.efficient.


An ExampleAn Example• Workflow: T = {tWorkflow: T = {t11, t, t22}}

tt11: Review request and propose response.: Review request and propose response.

tt22: Approve response: Approve response

• Both tasks can generally be done by role Both tasks can generally be done by role RRAA consisting of members John, Lisa, Paul, consisting of members John, Lisa, Paul, Pam, and Sam.Pam, and Sam.

• When the workflow concerns a high-When the workflow concerns a high-valued customer, StarCo, a role Rvalued customer, StarCo, a role RBB whose whose members are Robert and Jane must members are Robert and Jane must perform task tperform task t22..


An ExampleAn ExampleOriginal CBOriginal CB

1.1. relatedrelated(Sam, Pam) (Sam, Pam) Sam and Pam have a relationship.Sam and Pam have a relationship.

2.2. relatedrelated(Pam, Robert) (Pam, Robert) Pam and Robert have a relationship.Pam and Robert have a relationship.

3.3. cannot_docannot_douu(u(ujj, t, t22kk) ) i, i, countcountnvnv(u(ujj, ,

executedexecuteduu(u(ujj,t,t22ii), n), n> 2), n), n> 2

A user can only execute two instances A user can only execute two instances

of task tof task t2 2 ..4.4. cannot_docannot_douu(u(ujj, t, t22

kk) ) executedexecuteduu(u(ujj,t,t11ii), n), ), n),

inputinput(W(Wkk).customer = ).customer = inputinput(W(Wii).customer, ).customer, relatedrelated(u(uii, u, ujj))

A user cannot execute task tA user cannot execute task t2 2 when when someone who has a relationship with someone who has a relationship with him has performed task thim has performed task t11 in any other in any other instance for the same customer.instance for the same customer.

5.5. must_executemust_executeRR(R(RBB, t, t22kk) )

inputinput(W(Wkk).customer = ).customer = “StarCo”“StarCo”

Someone from Role RSomeone from Role RB B must perform must perform task ttask t22 when the customer is StarCo. when the customer is StarCo.

Step 1: By virtue of rules 1 and 2, the Step 1: By virtue of rules 1 and 2, the CB is enhanced:CB is enhanced:

6.6. relatedrelated(Sam, Pam) (Sam, Pam)

Step 2: Permitted_usersStep 2: Permitted_usersSS(t(t11) = {John, ) = {John, Lisa, Paul, Pam, Sam}, Lisa, Paul, Pam, Sam}, Permitted_rolesPermitted_rolesSS(t(t11) = {R) = {RAA}, }, Permitted_usersPermitted_usersSS(t(t22) = {John, Lisa, ) = {John, Lisa, Paul, Pam, Sam}, Paul, Pam, Sam}, Permitted_rolesPermitted_rolesSS(t(t22) = {R) = {RAA}, }, Denied_usersDenied_usersSS(t(t11) = ) = , , Denied_rolesDenied_rolesSS(t(t11) = ) = Denied_usersDenied_usersSS(t(t22) = ) = Denied_rolesDenied_rolesSS(t(t22) = ) = No static anomalies.No static anomalies.

No run-time conditions for tNo run-time conditions for t11 so so assignments are chosen from the assignments are chosen from the static sets of permitted users and static sets of permitted users and roles.roles.


An ExampleAn ExampleUpdated CBUpdated CB1.1. relatedrelated(Sam, Pam) (Sam, Pam)

Sam and Pam have a relationship.Sam and Pam have a relationship.2.2. relatedrelated(Pam, Robert) (Pam, Robert)

Pam and Robert have a relationship.Pam and Robert have a relationship.



A user can only execute two instances A user can only execute two instances of task tof task t2 2 ..

4.4. cannot_docannot_douu(u(ujj, t, t22kk) ) executedexecuteduu(u(ujj,t,t11

ii), n), ), n), inputinput(W(Wkk).customer = ).customer = inputinput(W(Wii).customer, ).customer, relatedrelated(u(uii, u, ujj))

A user cannot execute task tA user cannot execute task t2 2 when the when the someone who has a relationship with someone who has a relationship with them has performed task tthem has performed task t11 in any other in any other instance for the same customer.instance for the same customer.

5.5. must_executemust_executeRR(R(RBB, t, t22kk) )

inputinput(W(Wkk).customer = ).customer = “StarCo”“StarCo”Someone from Role RSomeone from Role RB B must perform must perform task ttask t22 when the customer is StarCo. when the customer is StarCo.


Step 3: Workflow instance WStep 3: Workflow instance W11 begun begun for customer StarCo.for customer StarCo.

Permitted_usersPermitted_usersRR(t(t2211) = {Robert, ) = {Robert,

Jane}, Permitted_rolesJane}, Permitted_rolesRR(t(t2211) = ) =

{R{RBB}, Denied_users}, Denied_usersRR(t(t2211) = ) =

Denied_rolesDenied_rolesRR(t(t2211) = ) =

No anomalies so Pam is assigned No anomalies so Pam is assigned to task to task tt22

1 1 and Robert to task and Robert to task tt2211..

Step 4: Run-time conditions Step 4: Run-time conditions necessitate updating CB based on necessitate updating CB based on constraint 5:constraint 5:

7.7. cannot_docannot_douu(Robert, t(Robert, t22kk) )


Since a new rule was added, we go Since a new rule was added, we go back to step 2. Nothing changes back to step 2. Nothing changes so wait for new task instance.so wait for new task instance.







A user can only execute two instances of A user can only execute two instances of task ttask t2 2 ..



A user cannot execute task tA user cannot execute task t2 2 when the when the someone who has a relationship with them someone who has a relationship with them has performed task thas performed task t11 in any other instance in any other instance for the same customer.for the same customer.

5.5. must_executemust_executeRR(R(RBB, t, t22kk) ) inputinput(W(Wkk).customer = ).customer =

“StarCo”“StarCo”Someone from Role RSomeone from Role RB B must perform task tmust perform task t22 when the customer is StarCo. when the customer is StarCo.




Step 3: Workflow instance WStep 3: Workflow instance W22 begun for customer StarCo.begun for customer StarCo.

Permitted_usersPermitted_usersRR(t(t2222) = {Jane}, ) = {Jane},

Permitted_rolesPermitted_rolesRR(t(t2222) = {R) = {RBB}, },

Denied_usersDenied_usersRR(t(t2222) = {Robert} ) = {Robert}

Denied_rolesDenied_rolesRR(t(t2222) = ) =

No anomalies so Paul is No anomalies so Paul is assigned to task assigned to task tt11

2 2 and Jane is and Jane is assigned to task assigned to task tt22

22..Step 4: Run-time conditions Step 4: Run-time conditions

necessitate updating CB based necessitate updating CB based on constraint 5:on constraint 5:

8.8. cannot_docannot_douu(Jane, t(Jane, t22kk) )


Since a new rule was added, we Since a new rule was added, we go back to step 2.go back to step 2.





3.3. cannot_docannot_douu(u(ujj, t, t22kk) ) i, i, countcountnvnv(u(ujj, , executedexecuteduu(u(ujj,t,t22

ii), ), n), n> 2n), n> 2A user can only execute two instances of task A user can only execute two instances of task tt2 2 ..



A user cannot execute task tA user cannot execute task t2 2 when the when the someone who has a relationship with them someone who has a relationship with them has performed task thas performed task t11 in any other instance in any other instance for the same customer.for the same customer.

5.5. must_executemust_executeRR(R(RBB, t, t22kk) ) inputinput(W(Wkk).customer = ).customer =

“StarCo”“StarCo”Someone from Role RSomeone from Role RB B must perform task tmust perform task t22 when the customer is StarCo. when the customer is StarCo.




8.8. cannot_docannot_douu(Jane, t(Jane, t22kk) )


Step 3: Workflow instance Step 3: Workflow instance WW33 begun for customer begun for customer StarCo.StarCo.

Permitted_usersPermitted_usersRR(t(t2233) = ) =

Permitted_rolesPermitted_rolesRR(t(t2233) = ) =

{R{RBB}, Denied_users}, Denied_usersRR(t(t2233) )

= {Robert, Jane} = {Robert, Jane} Denied_rolesDenied_rolesRR(t(t22

33) = ) = Depletion anomaly – no Depletion anomaly – no one to assign to task one to assign to task tt22

33. . System specific handling System specific handling would take place.would take place.


ConclusionsConclusions• Workflow Systems must guard against collusion Workflow Systems must guard against collusion

to commit fraud.to commit fraud.• Systems typically are protected using separation Systems typically are protected using separation

of duty constraints.of duty constraints.• We propose extending this concept to prevent We propose extending this concept to prevent

less easily detected collusion.less easily detected collusion. Across instancesAcross instances Over extended periods of timeOver extended periods of time

• Support our proposal with constraint language Support our proposal with constraint language and process for consistent, valid assignment to and process for consistent, valid assignment to workflow tasks.workflow tasks.

• Planned work includes extending further to take Planned work includes extending further to take into account delegation, conditional delegation into account delegation, conditional delegation and revocation.and revocation.

Inter-Instance Authorization Constraints for Secure Workflow Management

Documents

Transcript of Inter-Instance Authorization Constraints for Secure Workflow Management