Modelling, Specifying and Implementing Workflow Security in Cyberspace Ehud Gudes 1 , Martin S. Olivier 2 and Reind P. van de Riet3 ,
Abstract Workflow Management (WFM) Systems automate traditional processes where information flows between individuals. WFM systems have two major implications for security. Firstly, since the description of a workflow process explicitly states when which function is to be performed by whom, security specifications may be automatically derived from such descriptions. Secondly, the derived security specifications have to be enforced. The paper considers the issues that need to be addressed by a secure workflow system. In particular it addresses the requirement that security for workflow systems need to be specified at the workflow level, and not at the level of the underlying components, such as the database or networks. One reason why it is necessary to consider security at this level is the dynamic nature of workflow systems, with access restrictions depending on the state of the workflow process. In addition, workflow systems may handle many instances of a given workflow specification and needs to be able to protect the instances according to the requirements posed by each. The intention of this paper is to provide an orderly framework for these concepts and to discuss a more generalized implementation architecture which can be based on existing technologies of the Web and Object-oriented systems. The framework is based on three levels: Modelling, Specification and Implementation; each level refines the concepts of the level above it. Modelling is illustrated by using a notion of Alter-Egos and a workflow modelling tool known as COLOR-X. How these and related concepts may be formally specified are considered in the second part of the paper. The specification is based on the formal language Z. The implementation section considers protocols, standards and architectures that may be used to realize such a secure workflow system. Since the implementation does not use any specific system but only very general components, it can be realized on various platforms.
Keywords Security and Database systems, Workflow, Cyberspace, Object-Oriented Databases, Role-based security 1) Department of Mathematics and Computer Science, Ben-Gurion University, Beer-Sheva, Israel,
e-mail:
[email protected]; 2) Department of Computer Science, Rand Afrikaans University, Johannesburg, South Africa, e-mail:
[email protected] 3)Department of Mathematics and Computer Science, Vrije Universiteit, Amsterdam, e-mail:
[email protected];
1 Introduction Workflow Management (WFM) Systems automate traditional processes where information flows between individuals. Although WFM systems have been in existence for a number of years, the trend towards greater interconnection will greatly impact such systems. On the one hand, interaction will involve more and more nonhuman participants. On the other hand the participants in workflow processes will become more and more unrelated: We envisage that workflow processes in Cyberspace will eventually involve participants who have had no contact prior to participating in the same workflow process. The key to secure implementation of such WFM systems is proper authentication and authorization of participants in a workflow process. It is our contention that Alteregos (see the next section) are particularly suitable for authentication, while roles are particularly suitable for authorization. Stated differently: we will assume that a potential participant will present an Alter-ego that will serve as proof of the participant’s identity and which, along with other information, will identify the participant’s role. In earlier papers we discussed the concept of alter-egos [26] and the derivation of security and privacy rules for a Workflow system using them [8]. In [8] we also presented an example implementation which was based on a specific Prolog based object-oriented system called Mokum [22]. The intention of this paper is to provide an orderly framework for these concepts and to discuss a more generalized implementation architecture which can be based on existing technologies of the Web and Object-oriented systems. The framework is based on three levels: Modelling, Specification and Implementation, each level refines the concepts of the above level. Current approaches to security on the Web are not well integrated. The protection of information during transmission (by encryption), the protection of sites against malicious access (by firewalls) and the protection of the database from unauthorised access are completely separated. A workflow system on the Web is an integrated system and faces all three problems. The main contribution of this paper is the view of the problem as an integrated one, and based on that, the proposed framework mentioned in the previous paragraph. The challenge is to be able to model security requirements as part of the (highlevel) workflow definition, precisely specify those requirements and implement (enforce) them — all within the context of the workflow system. Workflow systems differ from other systems because of 1) their dynamic nature and 2) the fact that although different instances of workflow processes deal with very similar data, the security restrictions for these instances are not identical. The paper will use the classical example of an insurance claim to illustrate these points: During the lifetime of a claim, access rights vary depending on the current state of the claim. In addition, a subject’s access rights may differ from one claim instance to another. We are not aware of work that has comprehensively and successfully addressed these two characteristics of workflow systems in an integrated manner. The paper is structured as follows: The following section gives some background on Alter-egos, workflow and security. Section 3 introduces the insurance claim example that is used in this paper and presents our modelling tool. This section also presents some of the more important security rules for this example. 2
Section 4 then gives a more formal underpinning of WFM, using this example. It uses the Z specification language to precisely define the various rules, and the action to be taken when a security rule is violated. Section 5 discusses an implementation strategy for this workflow system. It first discusses the implementation of some important components such as secure message passing, and secure object references using existing Web technologies (e.g. Encryption, Corba, Firewalls) and then presents an Architecture which uses these components and which can implement the workflow system specified earlier. Section 6 contains the conclusions of the paper.
2 Background 2.1 Alter-egos Individuals, either in an office environment, or in their homes, will be represented in Cyberspace by objects, called Alter-egos, in the sense of Object-Oriented Technology, They were introduced in [26], where it was shown how these Alter-egos can be structured and how Security and Privacy (S&P) aspects can be dealt with. Questions around Responsibility and Obligations of Alter-egos which are inherent in a humanbased workflow system have been discussed in [23, 24]. Although we will not give a detailed description of these Alter-egos here, it will be necessary to give an overview for understanding the full capacity of this concept in relation to the Insurance claim example. Conceptually the Alter-ego is one object in which all relevant details of an individual person is kept and which can execute actions. It consists of many sub-objects, each one residing in a different environment/site. Such environments can be the Civil Administration in which the individual’s name, address, and other personal matters, such as marital status, are kept, a Bank, in which financial accounts are kept, an Insurance company, in which policies are kept, or the individual’s PC in which strictly personal information is kept. Logically, these sub-objects are treated as one object, physically they are stored in different sites and security mechanisms are used for protection. Privacy rules stipulate who can see/change what. For example, name and address can be seen by the Insurance company, but the Civil Administration is the only one who can change a name or an address. The Tax office can see certain financial personal information. To see that the sketched situation is not pure science fiction, the Dutch Tax office currently gives the tax payer the possibility to get an electronic form from the Web, to fill it in and to return it. One step further and the Dutch tax payer is asked to do his financial administration using a spreadsheet provided by the Tax office. The Tax office then is able to automatically read this administration annually (or even more often) and the Tax payer need not fill in the Tax forms any more. The use of Alter-egos to provide high-level security has been discussed in an earlier paper [26]. The main idea was that if the underlying communication system of Cyberspace ensures that every message contains an unforgeable Alter-ego of the sender (or initiator), one can design more flexible and higher level protection mechanisms than current systems that rely mainly on encrypting messages between the origin and the target sites.
3
2.2 Workflow In Workflow management (WFM) applications there are tasks to be completed by one or more organizations, but the organization procedures require that this task will be carried out in steps where each step is executed by a different individual and no step can be performed before the steps it depends on are completed [7]. Currently there are several types of workflow models, including a model proposed by a standard group [4]. We shall use a certain WFM-tool, COLOR-X [24], developed by the group in Amsterdam which was originally developed to model Information and Communication Systems using linguistic knowledge, but is general enough to model workflow systems as well. This will be demonstrated via the example in the next section. WFM tools are currently being used to specify how people and information systems are cooperating within one organization. There are at least three reasons why WFM techniques are also useful in Cyberspace. First, organizations tend to become multi-national and communication takes place in a global manner. Secondly, more and more commerce is being done electronically. This implies that procedures have to be designed to specify the behaviour of the participants. These procedures may be somewhat different from ordinary WFM designs, where the emphasis is on carrying out certain tasks by the users, while in commerce, procedures are based on negotiating, promises, commitments and deliveries of goods and money. However, as we will see, these notions are also present in the WFM tool we will use. Thirdly, people will be participants in all kinds of formalized procedures, such as tax paying or home banking.
2.3 Workflow and Security Since a workflow process is usually carried out by separate individuals with separate responsibilities and roles, these individuals naturally have different access permissions to global and private data. Specifying and enforcing these access permissions is the main task of this paper. A Workflow Authorization Model is proposed in [1, 2]. Authorization Templates are associated with each workflow task and used to grant rights to subjects only when they require the rights to perform tasks. A Petri net specification model is also given. Where [2] focusses on synchronising workflow and authorization flow issues using a multi-level security model, the current paper focusses on the relationship between individuals (represented by Alter-egos) and the roles they occupy in such workflow processes. An important aspect of the current paper is the enforcement of dynamic and history-based access control which is very typical and useful in workflow systems. The model proposed by Huang and Atluri [10] is also based on Petri nets. It uses a concept of Roles similar to ours, and the concept of authorization constraints. Although separation of duties can be enforced in this model, it is not as general as the Alter-Ego-based authorization rules in our model. On the other hand, since their model is more restrictive, it allows proving properties such as the safety property. Castano and Figini [5] proposed a model and a prototype of a secure workflow system. The security rules supported are static in nature and context independent, while in our model, the rules can be completely dynamic and context dependent.
4
2.4 Alter-egos, roles and workflow security As noted earlier, it is our contention that Alter-egos are particularly suitable for authentication, while roles are particularly suitable for authorization. In more detail, Roles are important for the static aspects of protection, since they specify the potential access perimeters of individuals holding the Role. However, Alter-egos can be used further to enforce dynamic aspects (e.g. that the approver of a claim will be different than its submitter, see next section ) since they identify exactly the individual holding the Role. Another aspect is related to the Responsibility issue. While roles represent in some sense abstract responsibility (an approver has responsibility to “approve” a claim) Alter-egos can represent responsibility in a more precise nature, can be tied to a person, and can log all activities on behalf of that person. Since responsibility is tied with a specific Alter-ego, there must be a phase in the workflow process where an Alter-ego is selected to perform a particular role (e.g. the approver’s alterego). Although we will not discuss this selection process in detail, it can obviously be dependent on issues such as load or availability which relate directly to the person identified by the Alter-ego. Recently, one of us has compared security aspects of Enterprise Resource Planning systems(ERP) and Database systems [27]. An ERP system integrates all information within an Enterprise about the employees, their tasks and the products they deal with, such as claims issued by claimants (see next section). It is evident that the notion of Alter-ego is very suited to be used as integration factor: in the (static) (hierarchical) organization of the enterprise and in its (dynamic) functioning. In a WFM the specific capabilities of an employee and the specific tasks to be carried out can be brought together.
3 Modelling workflow — The Insurance-claim Application The following is a typical example where WFM techniques are being successfully incorporated already. It deals with the procedure within an Insurance company to deal with a claim issued by an individual. The example here is a small fraction of a more extensive example in which external agencies, such as a Travel Company and a Bank are also involved and in which the internal organization of the Insurance company is more realistic than the one we present here. All communication is supposed to take place on the Internet. All persons and institutes participating in the process are represented by Alter-egos. The example deals hence with a situation as it might occur in Cyberspace. The example runs as follows: A claimant submits an insurance claim, which is either approved or rejected by some approver. If the claim is not approved (or rejected) within some specified period, the approver is reminded to give attention to this claim. The fragment is depicted graphically in Figure 1. For a more extensive example, see [25]. The following requirements are obvious, even from this simple example: 1. The approver has to be duly authorized to approve the claim. The requirements for such authorization depend on the specific application; the mechanisms to enforce such requirements are the concern of this paper. 5
' $' $' $' $ & %& %& %& % -
?
-
Submit
Time-Out
Deny
Approve
Claim ClaimClass: Create by Person as Claimant
After some time send reminder by insurance company
Claim: Deny by Clerk or Expert as Approver
Claim: Approve by Clerk or Expert as Approver
?
6
6
6
Figure 1: Fragment of a workflow process 2. Access to the documents involved in the workflow depend on the roles individuals play in the workflow process. A specification for the same process, but using a COLOR-X diagram, is given in figures 2 and 3. Note that in figure 2 we used the following conventions: A box in figure 2 denotes an entity or type. A line is a relationship and a line with open arrow is an is a relationship. The exclusion (#) label indicates exclusion. In figure 3 we have:
each box of actions has a mode: PERMIT, NEC or MUST. The latter one means an obligation based on some negotiating in the past: as we are not sure that the action is actually carried out within the prescribed time it is necessary to define a counter measure. The mode NEC means we can be sure the action is necessarily carried out by the system. PERMIT is self evident. the actions are described in a formal language involving the participants and their roles; the lightning arrow denotes a situation in which the conditions in the identification part (denoted by id) are not satisfied. The result actions may be: a reminder to be sent, an abort of the workflow process, or some other action. We choose here the “reminder” action.
Figure 2 defines the static structure of the entities involved: an employee and a claimant are persons; an approver, a clerk, an expert and a cashier are employees. A claim is submitted by the claimant and received by the insurance company. Employees are employed by the insurance company. The approver and the claimant must be different persons. Figure 3 gives an impression of the dynamic part of the example: Without any restriction (PERMIT) a person can submit a claim to the insurance company at time T1. (For “person” one could read “Alter-ego”). The approver of the insurance company (see left-hand side) has the obligation (MUST) to approve or deny the claim within the prescribed period of time (T2 < T1 + period). For this simple example: if the claim is smaller than $ 100 the approver must hold the role of a clerk, otherwise the role of an expert. In the situation of the more extensive example other 6
person
claim employee go
ag
claimant
submit employ
rec insurance_company
approver
#
clerk
expert
cashier
Figure 2: The COLOR-X Static Object Model Diagram for the Insurance Claim example
7
1
PERMIT: submit(ag=person P)(go=claim CL) (rec=insurance_company IC)(tmp=temp T1)
2
MUST: verify(ag=approver AP)(go=CL)(tmp=time T2)
id: is_a(approver)(clerk)(sit: CL.amount100) id: T2< T1+period
3
NEC:
send(ag=IC)(go=reminder R1)(rec=approver AP) id: T1=NOW
4
NEC: 1. send(ag=IC)(go="approve")(rec=person P) 2. send(ag=IC)(go="deny")(rec=person P)
1 5
NEC: send(ag=IC)(go=claim CL)(rec=cashier CA)
2
Figure 3: The COLOR-X Event Model Diagram for the Insurance Claim example
8
employees for these roles have to be selected and the task of approving is delegated to these employees. In the normal case, when the approver is ready with the task within the prescribed period, the approver sends the result to the submitter, and, in case of approval, also a message to the cashier to do the payment. As these actions are done under the guidance of the system itself (in the form of a Work Flow Engine) the mode of these operations is NEC. It is possible that the approver is not ready with the task within the prescribed period of time, then a reminder is sent to the approver. In this simple example sending reminders can be done indefinitely, but in the more extensive specification there is a limit of course. From the example above, we can derive both static (Role-based) and dynamic (Alter-ego based) security requirements. Their precise specification and implementation is discussed in the following sections.
4 Formalisation In order to express the model clearly, the concerned notions will be formalised in this section, using Z. The basis of the formalisation will be Petri-nets, but the emphasis here is on the events that accompany the activation and deactivation of activities, rather than the activation/deactivation events themselves. Note that our activities correspond to places in Petri-nets and our connectors to transitions. Readers not familiar with Z should be able to follow the intention of the specification since Z is based on formal logic and set theory, with logical operators (^, ,, etc) and set operators (2, [, etc) using their familiar notation and other operators (such as bag membership, @ ?) often easy to infer. Z statements are grouped into schemas (and other structures of lesser importance for the moment). Variables that are primed (eg x 0 ) indicate the value of the unprimed variable (x ) after the schema in which it appears, has been applied. Provision is also made for variables serving as input for a schema (eg x ) and as output (eg x ). schemas do not allow any changes to be made (in x ). schemas, other words, it is assumed that for every variable x it specifies, x 0 on the other hand, are intended to effect change and for every variable x it is necessary to specify how x 0 should be computed; if a specific x remains unaltered, it is explicitly stated (x 0 x ). Readers requiring further information are referred to one of the many textbooks on the topic, such as [6]. The formalisation is based on three layers. On layer one the intention is to protect the underlying data objects (that are to be manipulated by the workflow system). On layer two, the generic security requirements of all workflow systems are considered, while layer three considers mechanisms to support security for a specific workflow application. We will refer to layer one as the data object layer, layer two as the workflow process layer and layer three as the application layer.
?
!
=
=
4.1 Layer 1 (Data Object Layer) Layer 1 is the underlying database. We assume a class-based system: All objects are described by classes. Stated differently, every object is an instance of some class. Objects may be used by sending messages to them. We make no assumption about the nature of classes, objects and messages, but
9
simply assume that they exist.
[CLASS ; OBJ ; MES ] Note that the definition is general enough to be used in object-oriented, as well as relational systems (where classes correspond to relations, object to tuples and messages to SQL statements). The security complexities introduced by inheritance in a fully object-oriented system have been studied elsewhere (see [18, 13] for some examples) and are not considered in this paper in order to be able to focus on the workflow security issues. Our assumption that every object is an instance of some class is modelled by the class function that maps every object to its corresponding class:
class : OBJ ! CLASS To model security, three types of subject (SUBJ ) are identified: the system itself, various users and a no subj to identify activities that have no associated subject (and therefore cannot be performed — yet).
SUBJ
::= no subj j system j user hhN ii
It is important to note that a user identifier is intended to uniquely identify a user:
8 s ; t : SUBJ ; i : N s = user (i ) ^ t = user (i ) ) s = t This subject identifier has to form part of the Alter-Ego that identifies each subject; it is some globally unique identifier similar to a social security number which is currently unique on a national level. Access control in a database such as the one described above requires that the subjects who are allowed to send particular messages to particular objects have to be identified. One premise of this paper is that access may be granted when required and revoked again as soon as it is no longer required. Since the same access permission may be required for more than one higher layer activity, it is possible that the same right may be granted multiple times. When one concerned activity completes, and the rights required for that activity are revoked, the rights should still exist, if required for other activities. To effectively model this requirement, a bag of access control tuples is used:
Auth == [mac : bag(SUBJ OBJ MES )] Here the Auth schema defines mac (message access control) as a bag of triples. An entry in mac permits the identified subject to send the identified message to the identified object. The intention is that relevant triples will be added to the bag when an activity commences and removed when the activity completes. Using a bag means that granting and revoking access to the same message for different activities may partly overlap without problems. Note that the access control models supported by most database systems cannot handle nested or overlapping grant-revoke operations; a set of access control triples 10
more accurately reflects the operation of such systems. How the required bag structure may be mapped to the typically supported set structure falls outside the scope of the current paper. The definition the decisions that may be made for access control (DECIDE ) are self explanatory.
DECIDE ::= no j yes It is now simple to formalise access checks to objects in the database: given the subject, object and message that the subject has sent to the object, it is only necessary to verify that the (subject, object, message) triple occurs in the access control bag — see figure 4.
MessageCheck
Auth subj ? : SUBJ ; obj ? : OBJ ; mes ? : MES allow ! : DECIDE allow ! = if (subj ?; obj ?; mes ?) @ ? mac then yes else no Figure 4: Checking access
4.2 Workflow Process Layer: Basic definitions A workflow system consists of a series of activities that are interconnected by connectors. The actual activities depend on the (layer 3) application(s). Suppose, for example, that the workflow system described earlier (figures 2 and 3) is to be implemented. Then the activities supported by the system may be identified as follows:
ACT ::= Submission j Approval j PayOut j Reminder On the workflow process layer (layer 2) the precise list of activities is not important; it is only important that some such list will be defined on layer 3. The activities are interconnected by connectors. In practice, connectors will probably consist of some identifier. Since the nature of such identifiers is immaterial, it is left unspecified:
[CON ] A workflow process definition consists of a series of activities and connectors that are interconnected. Before we consider this interconnection, it should be stressed again that multiple process instances may be active at any given moment — all using the underlying workflow process definition. It is therefore also necessary to be able to identify the process instance, using some process instance identifier:
[PROC ] 11
A process instance is ‘executed’ by the workflow system by ‘instantiating’ activities. While only a single Submission activity is defined in our claim example, a number of subjects may be submitting claims concurrently. Each submission creates a new process; each process has its own submission activity. If we assume that only one instance of an activity may be active in any given process instance at any given time, activity instances may be uniquely identified by a combination of the process and activity identifiers:
ACT INST == PROC ACT An activity instance may be in various states: Initially it will be dormant . When a connector fires, one or more activities may become enabled , meaning that the activity has to be performed. The system will then activate the activity and assign a responsible subject. Once this subject completes the activity, the state of the activity will be changed to completed , with an indication of which subject was responsible for the activity, as well as which output connector the token should be passed to. Once that token fires, the state of the activity instance will revert to dormant .
STATE ::= dormant j enabled j active hhSUBJ ii j completed hhSUBJ CON ii As noted earlier, some objects are instantiated for the exclusive use of some workflow process instance, while others will be shared by all (or some) process instances. To be able to distinguish the USAGE of objects later, two primary possibilities exist: local and global . Since the workflow system is assumed to be used on some underlying system, it is entirely possible that some data objects are not used by the workflow system at all.
USAGE ::= no usage j local j global 4.3 Process modelling Figure 5 describes the assumed structure of workflow process descriptions: the messages that may be sent to perform the activity, the connectors that precede an activity (act input ) and the connectors that follow the activity (act output ). Note that this fully defines the graph that describes the workflow definition. The (workflow) usage of the various classes are also defined here.
Wfpd act mes : ACT !7 P(MES CLASS ) act input : ACT $ CON act output : ACT $ CON class usage : CLASS ! USAGE Figure 5: Workflow process definition
12
Again, the only assumption on the workflow process layer is that the graph that describes the workflow system exists; on the application layer the actual composition of act mes , act input , act output and class usage have to be described, depending on the actual workflow application(s). Given the description of the (static) workflow process structure in figure 5, the (dynamic) states of the process instances are mapped onto the static structure in figure 6. act state maps an activity instance identifier (identifying the process instance and the activity class) to the current state of the activity. The state of a connector is represented by the tokens that have arrived from preceding activities and not yet passed on to subsequent activities. The final line of the schema enforces the fact that only tokens that have arrived from a preceding activity are allowed in a connector: second is the second element of the pair and therefore identifies the activity ‘class’ of the activity instance from which a token has arrived at a connector. It is also necessary to identify those objects that are local to the particular process instance; obj local to either identifies the process for which the object has been created, or assumes the value all for global objects (‘local’ to all objects).
ProcState Wfpd act state : ACT INST ! STATE con state : bag(CON ACT INST ) obj local to : OBJ ! PROC 8 o : OBJ class usage (class (o )) = global , obj local to (o ) = all 8 c : CON ; : ACT INST (c ; ) @? con state ) (second ; c ) 2 act output Figure 6: Processing states of process instances
4.4 Security structures We assume that any message that is sent in the workflow system has an associated sender that identifies the subject who has sent the message. Some operations are restricted for use by the system. Where this is the case the specification given in figure 7 will be used.
OnlySys sender ? : SUBJ sender ? = system Figure 7: Used when only system may perform an operation
13
4.5 In operation For a complete specification, it is necessary to describe the initial state of the system, how a process instance is instantiated and how control is transferred from one activity to the next, until the instance terminates. Such a description is lengthy and not directly of concern to the topic of the current paper, but may be necessary to consult if one wants to follow the specifications that are central to the current paper. The specification of these operations are therefore given in the appendix. Of direct concern in the current paper are the Grant and Revoke operations, which will be discussed below. Before that is done, the relationship between Grant , Revoke and the other operations (given in the appendix) will briefly be considered. This relationship is depicted in figure 8. Although it is possible to specify the behaviour of the system to change the state of workflow activities in Z, it is easier to follow (and hopefully as precise) if it is done in procedural form. The notation used in figure 8 should be self-explanatory. Note that FireCon will fire an enabled connector, thereby enabling a subsequent activity; an enabled activity will be assigned a subject by Grant , until the activity completes. At that point, Revoke will remove the concerned subject’s access rights, after which Deactivate will return the activity’s state to dormant.
SystemEventHandler sender ! = system 8 p : PROC ; a : ACT whenever act state (p ; a ) becomes enabled : Grant [proc ! = p ; act ! = a ] completed (s )with s : SUBJ s 6= no subj : Revoke [proc ! = p ; act = a ] completed (no subj ) : DeactivateAct [proc ! = p ; act ! = a ] 8 p : PROC ; c : CON whenever con state (p ; c ) becomes con enabled : FireCon [proc ! = p ; con ! = c ]
Figure 8: Handling the system events Figure 9 describes the Grant operation. The system somehow has to select an appropriate subject taking into account issues such as current workload of the available subjects. This is obviously not a security concern and therefore not modelled in our specification. However, it is a security concern that the selected subject may indeed be selected according to the security policy. Since this policy is tied to the application, this issue will be considered in section 4.6. There modifications to the basic Grant operation will be considered to enfore application layer security specifications. The important points to note in the Grant operation at the current layer are the following:
Only the system may grant a subject the right to perform an activity; 14
The activity instance should be activated, but no subject should have been assigned yet;
mac is the authorization bag as described earlier; and mac is updated to authorize the subject to send all messages that are required to perform the activity. (act inst message identifies all these required messages; it is described in the appendix.)
Grant ProcObjs ProcState Auth OnlySys act ? : ACT ; proc ? : PROC ; subj ? : SUBJ act state (proc ?; act ?) = active (no subj ) mac 0 = mac ] settobag (act inst mes (subj ?; proc ?; act ?)) act state 0 = act state f(proc ?; act ?) 7! active (subj ?)g con state 0 = con state Figure 9: Granting a subject access to an activity The moment that a subject completes an activity, the system will revoke access from the subject using Revoke (see figure 10).
Revoke Auth ProcState ProcObjs OnlySys act ? : ACT ; proc ? : PROC subj : SUBJ 9 c : CON act state (proc ?; act ?) = completed (subj ; c ) mac = mac 0 ] settobag (act inst mes (subj ; proc ?; act ?)) Figure 10: Revoking access from the responsible subject
4.6 Layer 3 Workflow in Cyberspace inherently deals with the coordinated cooperation of agents in Cyberspace to complete some task. For a workflow to be considered secure, agents have to be limited to act when and where in the workflow process they are supposed 15
to act. In addition, it has to be ensured that agents are related in appropriate ways and not related in inappropriate ways. To illustrate, one agent acting in one activity may be required to be the manager of another agent acting in another activity of the same process. Similarly, two agents in different activities may be required to work for different organisations. This is typical of application layer constraints. The intention of this section is to consider an approach to specifying these constraints; towards the end of this section it will be argued that the Grant operation given above in figure 9 can be modified to enforce these application layer constraints. As has been argued above, information about when and where an agent may act in a workflow process may often be derived from the workflow specification. (See [14, 8] for more details.) This section considers the additional — often application-specific — specifications detailing the required or inappropriate relationships between agents. In [15] a number of specification techniques have been proposed and discussed. This section only considers the Unacceptable History Approach (UHA). It is based on the discussion in [15], but has been adapted to reflect the situation in Cyberspace.
4.7 Unacceptable history approach This approach to express policies is based on a history of actual authorisations:
history : bag(SUBJ PROC ACT ) It is simple to ensure that the procedure that grants an authorization ‘logs it’ by adding any authorisation triple it issues to history . In this case general authorisations are given as illustrated by the following example:
8 s : SUBJ ; p : PROC (s ; p ; Submission ) @? history ) s 2 customer where customer is a set (or ‘role’) of all insurance company customers. General policies identify the required roles for subjects to act in an activity of a workflow process. General policies here are characterised by the fact that they are quantified over all subjects and processes and place restrictions on the subjects. The name of this approach was selected from the mechanism used to specify specific policies. Specific policies apply to specific workflow process instances (such as the processing of a particular claim) and restrict the relationships between agents in the workflow process. In general the occurrence of one event in history prohibits other events. To illustrate,
8 s : SUBJ ; p : PROC (s ; p ; Submission ) @? history ) : (s ; p ; Approval ) @? history specifies that the submitter of a claim cannot approve it. Note again that a universal identity for s is required in Cyberspace — if a person uses one identifier in his/her role as a customer of the insurance company and another in his/her role as an employee of the company, this check cannot be enforced. This again illustrates the need for Alter-Egos. 16
If a manager function is defined that maps every customer to his/her account manager,
manager : SUBJ !7 SUBJ the following policy specifies that a claim has to be approved by the account manager of the claimant.
8 s ; t : SUBJ ; p : PROC (s ; p ; Submission ) @? history ) (: (t ; p ; Approval ) @? history ) _ t = manager (s ) If a policy requires that the same subject may not be responsible for any two or more activities in any given process instance, it may be specified as follows:
8 s : SUBJ ; p : PROC ; a ; b : ACT (s ; p ; a ) @? history ^ a =6 b ) : (s ; p ; b ) @? history An alternative policy may require that two subjects cannot mutually approve one another’s claims (avoiding collusion):
8 s ; t : SUBJ ; p ; q : PROC
[ (s ; p ; Submission ); (t ; p ; Approval ); (t ; q ; Submission )]] v history ) : (s ; q ; Approval ) @? history
It is obvious from the examples above that the unacceptable history approach is both powerful and concise. Below, in section 5.3, we will consider implementation issues for this approach. The essence to implement the approach is only sketched briefly here. Convert all general policies to a set of the form
positive : P(SUBJ ACT ) to identify every subject s who may in principle perform activity a . Note that positive is intended to be a static set that is not modified over time. Let
negative : P(SUBJ PROC ACT )
(
)
be a set where s ; p ; a 2 negative indicates that subject s is not allowed to perform activity a of process p — overriding any positive authorisations that may exist. In other words, the set of potential accessors is restricted to
potential = f8 s : SUBJ ; p : PROC ; a : ACT j (s ; a ) 2 positive (s ; p ; a )g n negative The challenge now is to convert every specific constraint to a sequence of triggers such that when an event referred to in any constraint occurs, it is verified if any future events have been excluded by the event that has occurred. If any such event 17
(s ; p ; a ) (subject s performing activity a of process p ) has indeed been excluded, it may be added to the negative set. Grant (see figure 9) now simply has to check that (subj ?; proc ?; act ?) 2 potential . If an event re-enables a subject to perform some
activity, the entry may also be removed from negative . It is, however, important to note, that an event can never grant somebody permission to perform an activity if that somebody has not been authorised in principle — that is, if a suitable entry does not occur in positive . Although the dynamic conversion of these constraints to entries in the negative set is straightforward (a simple program in a logic programming language will do it), an efficient conversion mechanism is still required, but falls outside the scope of the current paper. See [15] for some additional remarks on this conversion.
5 System Implementation The implementation of the above model largely depends on the underlying layers of software. In a previous paper we suggested an implementation which was based on the distributed version of the Knowledge-based object-oriented system Mokum [8]. Here we want to outline a general architecture which can be based on any secure objectoriented system. We first suggest techniques to implement several components of the system, such as implementing Roles and Alter-egos, implementing the secure object layer, and implementing the Unacceptable history log. Then we propose a system architecture which uses the above components to implement the specifications discussed in the previous section.
5.1 Implementing Roles and Alter-egos As mentioned in section 3, a Workflow system is a very dynamic system. Roles need to be created, deleted, changed, etc. The administration of roles is therefore a critical component in the implementation. For that purpose we assume the existence of the Workflow security administrator. This administrator handles the following tasks: 1. It authenticates each new user and creates for her the appropriate role. 2. It is consulted whenever the dynamics of the situation requires the change of roles. For example, if for a particular claim, the Expert role is required, the administrator is consulted to check whether the current Approver’s alter-ego can amplify its role to become an Expert. If not, it checks whether there is already an active Expert role in the system and if there is, sends to the Approver node its identity, and if it does not exist, it will wait for the right alter-ego to be instantiated and authenticated with this Role. To implement roles one usually uses a special object (database) which is dedicated to maintain the Role information. One approach of doing that using a Java class was proposed by Ting et al [21]. In the following we will not detail the exact implementation but basically assume that the Role object exists with the standard methods such as add-role, delete-role, modify-role-permissions, and that the Security manager object is the only object allowed to execute these methods.
18
To implement Alter-egos, we assume it to be represented as a complex object as discussed in [26, 23]. Such complex objects will have several interface functions, such as: fetch e-mail address, or get account information. These functions will be used by the various agents of the workflow system as described in Section 3. The alternative, in case of the insurance application, is to pass this information as part of the claim object, but this may cause some privacy problems as discussed in [26] (e.g. the approver could see account information which he has no business to see. . . ). We therefore prefer the first approach of passing only the alter-ego object identification with each message in the workflow system. The workflow agent will use the alter-egos object interfaces to obtain the required information.
5.2 Implementing secure objects and messages In order to securely implement the system described above, it is necessary to ensure that the underlying infrastructure is secure. Secure communication protocols are obviously essential. Before we review such protocols, we briefly consider CORBA to support secure objects. 5.2.1
Implementation based on CORBA
CORBA which is becoming one of the major standards for Object-oriented software systems has published the Security reference model specifications [17]. Many of our concepts map directly into the CORBA architecture. Our Alter-ego will represent a “principal” in CORBA. In terms of protecting messages and assuring message integrity, CORBA provides some facilities, but in our opinion these facilities are redundant in Cyberspace because of the existence of secure communication protocols (see section 5.2.2). The active customized code for each participant will be coded within the “access decision functions” of CORBA, and is enforced automatically by the ORB (Object Request Broker) before any Object invocation. Auditing can also be specified by the CORBA’s model and also implemented by the ORB. In addition Non-Repudiation services are also provided for reasons of Accountability. Although Roles as used in this paper are not supported in the CORBA model, other means such as Domains may be used to implement them. The problem of administration of authorization information is discussed in the [17], but a full specification is not given. Since the security reference model is not yet implemented and not even accepted, one can resort to existing CORBA services to implement our model. One such approach can follow the scheme suggested by Sheth in his CORBA based Workflow architecture [12]. In this architecture, there is a Task manager associated with every task (object in our case), which executes the interface code defined in the IDL file. We will need to add to such a task the active security checks and the ability to re-initialize its parameters each time it receives a message from the Application administrator requiring it. 5.2.2
Using Secure communication protocols
The recent literature and the World Wide Web has much information about secure communication protocols. Lipp and Hassler [11] present a survey of such protocols. They 19
can be at the message level such as Netscape SSL or Microsoft PCT [29] or depend on the requirements of the application which is HTTP or higher, such as SHTTP. SHTTP supports end-to-end secured transactions which can be initiated symmetrically, so that servers and clients are treated equally with respect to their preferences. Message protection may be provided by signing, authenticating, or encrypting the message, or by applying any combination of these. There are basically two types of messages in the Workflow system described above. There are the standard messages between the participants’ Alter-egos. These messages are assumed to contain the Sender’s pair (Role, Alter-ego) and the receiver’s Role. The integrity of messages provided by the lower level protocols is sufficient. Once the Alter-ego is authenticated, and a Role is assigned, the pair (Role, Alter-ego) is assumed to be part of every message (e.g. in its header) and this is sufficient for applying the higher-level customized security checks. The existence of the pair (Role, Alter-ego) — actually the triple (Site, Role, Alterego) — can also be used by security firewalls. The firewall will be associated with the workflow application and will reject any message which does not have in the header the (Alter-ego, Role) pair.
5.3 Access control In Cyberspace, access control is ideally handled by a capability or ticket scheme similar to that provided by Kerberos [19]. Not only does such a scheme allow authentication and authorisation to be distributed, but it also means that the subject using the service need not be known to the server providing the service. We suggest that a similar scheme has to be used in workflow systems in Cyberspace. Such ticket granting servers (TGS) will then receive requests from a subject s to perform some activity a for some process instance p . Based on the general policies referred to in section 4 the TGS will be able to verify that s is indeed a member of a role who may perform activity a . However, before issuing the ticket, the TGS will have to ensure that the particular subject has not been prevented from performing the specific activity by a specific policy. More precisely, the TGS has to behave as specified in the Grant operation. Remember that specific policies are specified in terms of a history log. Also note that the policies may be specified towards the future or the past: one rule may specify that some entry in the log disallows another entry at some future time in the log; another rule may specify that, if an entry is to be made in the log, another entry should not already be in the log (see section 4 for more examples). In both cases it is possible to reformulate the rule to a format where an earlier event prevents later events from occurring: in the case where a later l event prevents one or more earlier events e from occurring, occurrence of the earlier event e disallows the later event l (otherwise the rule that l prevents e will be violated). In both cases therefore a TGS that issues a ticket for the earlier event, should inform all other concerned TGSs that the later event l should be disallowed. For simplicity we assume that only a single TGS can issue a particular ticket. As will be shown in the architecture described next, the TGS authority is fulfilled by an agent called ISA — Workflow instance security administrator — which fulfils the TGS responsibilities for a specific workflow instance.
20
5.4 Workflow System Architecture Our Workflow system architecture is depicted in figure 11. It is somewhat similar to an architecture described in [9]. It assumes of course the existence of the basic elements described in the previous section. The system is made of system components and workflow agents. System components are built-in software objects which exist for the entire system and are permanently “alive”. Workflow agents perform particular a specific task or activity on behalf of some Alter-ego and are created and terminated with the creation/termination of a workflow instance. The major system components are:
SA — Security Administrator This component is responsible for administrating the Role database, the Authorization rules database and the authentication of Alter-egos. A Workflow is initiated only after validation by the SA. The SA is also responsible for creating an ISA — Instance security administrator for the specific workflow instance. The ISA contains the UHA log and will perform the dynamic security checks. WFM — The Workflow Manager This component is responsible for controlling the workflow instance. It calls the WFSC - Workflow scheduler to select the specific alter-ego agent to perform the task. The WFSC is also consulted whenever there is a need to delegate workflow actions, e.g. when a workflow agent fails and another agent has to replace it, or when delegation must occur because of a security check (e.g. the Approver equal submitter case). It also communicates with the WFC — Workflow communicator to send/receive messages from other nodes, and with the ISA to check whether a specific instance should be continued or aborted. The WFM also sends a message to the ISA each time a new event occurs, at that time the ISA creates an entry in the UHA according to its local authorization rules database. Note that the ISA which is associated with a specific workflow instance, is created mainly for performance reasons, its functionality can be subsumed by the security administrator. WFA — The Workflow Agent The workflow agent performs the actual work assigned to it by the workflow manager. In terms of security there are two kind of checks. Each WFA has code (guards) which verify that the required task can be executed by the Role associated with the message (note, Roles and Alter-ego of the sender are associated with each message in the system). The dynamic tests are checked by the ISA using the UHA log file. If both tests succeed then the workflow continues, otherwise it is aborted. Database objects UHAO — unacceptable history object RO — Roles object ARO — Authorization rules object WFSO — Workflow specification object LARO — local authorization rules object (this is basically a copy of the relevant 21
SA
ARO
RO
ISA
WFC
WFSC
UHAO
WFM
WFSO
WFA
WFA
WFA
... WFO
WFO
Legend:
Node Component Data object Figure 11: The Workflow System Architecture
22
WFO
part of the ARO to this workflow instance) WFO — local objects needed for the operation of the workflow agent Note that in figure 11 the major components are in different nodes, but the mapping of components to nodes is quite arbitrary, using the secure object layer discussed above, it is only a performance problem and not a security issue. To demonstrate the flow in this system we present next the sequence of messages that will occur with a new claim. Each message has the following parameters:
Type of message Sending alter-ego Target component or agent Data object referenced Role of sender
1. msg(enter, claimant-id, SA, claim, User) SA administrator authenticates the user and assigns it a role Submitter 2. msg(submit claimant-id, WFM, claim, Submitter) WFM verifies the role. then creates a new workflow instance by creating an ISA and an approver WFA (not shown) 3. msg(record, WFM-id, ISA, claimant-id,WFM) Workflow manager sends to ISA the id of the submitter to be recorded in the history log. 4. msg(approve,WFM-id,Approver,claim,WFM) Workflow manager sends the claim to the approver 5. msg(check_history,WFA-id,ISA,claim,WFA) Agent approver sends a message to ISA to check for unacceptable events. if WFA-id = claimant-id then the security check fails and the workflow is aborted. if not, suppose the claim is over the limit specified for this approver. 6. msg(delegate_approve,WFA-id,WFM,claim,WFA) Workflow now needs to select a different workflow agent (representing another alter-ego) 7. msg(select_expert,WFM-id, WFSC,claim, WFM) WFSC returns a new alter-ego agent for approval. this agent may exist or may need to be created.
23
8. msg(approve,WFM-id,newWFA,claim,WFM) the approve message is sent to the newly selected agent
6 Conclusions This paper considered security in a workflow system. It has been argued that the notion of Alter-egos is central in such workflow systems. The participation of an Alter-ego in each message enables the complete authentication and some specific individual-based checks that are required in such an environment. The paper presented a three-level framework: modelling, specification and implementation. Since the implementation has not used any specific system but only very general components it can be realized on various platforms. It is clear that the Alter-ego concept which is central to this paper raises important social and legal issues. Until they are resolved any such implementation can only demonstrate the usefulness of the concepts, before putting them to a productive use.
References [1] Atluri, V., and Huang, W.K., “An Authorization Model for Workflows,” in Bertino, E., Kurth, H., Martella, G., and Montolivo, E. (eds), Computer Security — ESORICS 1996, Springer, 1996, pp. 44–64. [2] Atluri, V., and Huang, W.K., “An extended petri net model for supporting workflow in a multilevel secure environment,” in P. Samarati and R.S. Sandhu, Database Security X: Status and Prospects, Chapman & Hall, 1997, pp. 240–258. [3] Bertino, E., Bettini, C., and Samarati, P., “A Time-based Authorization Model,” Proc. ACM Int. Conf. on Computer and Communication Security, Fairfax, Va, Nov. 1994, pp. 126-135. [4] Casati, F., Ceri, S., Pernici, B., Pozz, G., “Conceptual Modelling of Workflows” Proc. of the Object-oriented and Entity-Relationship Conf., Australia, 1995. [5] Castano, S. and Fugini, M., “Rules and Patterns for Security in Workflow Systems,” Proceedings of the IFIP WG 11.3 Working Conference on Database Security, Porto Carras, Greece, August 1998. [6] Diller, A., Z: An Introduction to Formal Methods, Second edition, Wiley, 1994 [7] Georgakopoulos, D., Hornick, M., and Sheth, A., “An overview of workflow management: from process modelling to workflow automation infrastructure,” Distributed and Parallel Databases, Vol 3, No. 2, 1995, pp. 119–154. [8] Gudes, E., Van de Riet, R.P., Burg, J.F.M. and Olivier, M.S., “Alter-egos and Roles — Supporting Workflow Security in Cyberspace ”, in T.Y. Lin and S. Qian (Eds.), Database Security XI: Status and Prospects, Chapman & Hall, 1998, pp. 182–195 24
[9] Hawryszkiewycz I. and J. Debenham, “A Workflow System based on Agents”, Proceedings, 9th DEXA Conference, Vienna, Austria, August, 1998, pp. 135– 144. [10] Huang, W.K. and Atluri, V., “Analyzing the Safety of Workflow Authorization Models,” Proceedings of the IFIP WG 11.3 Working Conference on Database Security, Porto Carras, Greece, August 1998. [11] Lipp, P., and Hassler, V., “Security concepts for the WWW,” Proc. 2nd Int. Conf. on Communication and Multi-media security, Essen, Germany, 1996, pp. 85–95. [12] Miller, J.A., Sheth, A.P., Kochut, K.J., and Wang, X., “CORBA-based run-time architecture for Workflow management systems,” Journal of Database Management, Vol 7, No. 1, Winter, 1996, pp. 16–27. [13] Olivier, M.S. and Von Solms, S.H., “A Taxonomy for Secure Object-oriented Databases”, ACM Transactions on Database Systems, 19, 1 (1994) 3–46. [14] Olivier, M.S., “Using workflow to enhance security in federated databases,” Proc. 2nd Int. Conf. on Communication and Multimedia Security, Essen, Germany, 1996, pp. 61–72. [15] Olivier, M.S., van de Riet, R.P. and E. Gudes, “Specifying Application level security in Workflow systems,” in R. Wagner (Ed.), Database and Expert System Applications, IEEE Computer Society, 1998, pp. 346–354 [16] Object Management Group, The Common Object Request Broker: Architecture and Specification, OMG Document number 93.12.1, December, 1991. [17] Object Management Group, URL “http://www.omg.org:80/docs/orbos/”. Documents: 96-08-03.ps, 96-08-04.ps, 96-08-05.ps, and 96-08-06.ps. [18] Rabitti, F., Bertino, E., Kim, W. and Woelk, D. A Model of Authorization for Next-Generation Database Systems, ACM Transactions on Database Systems, 16, 1 (1991) 88–131. [19] Schneier, B, Applied Cryptography J. Wiley, 1996. [20] Serban, R., Dehne, F., and Van de Riet, R.P., A first step towards distributed Mokum, Technical Report 428, Computer Science Department, Vrije Universiteit, Amsterdam, 1997 [21] Smarkusky, D.L., Demurjian, S.A.Sr., Bastarrica, M.C., and Ting, T.C., “Security Capabilities and Potentials of Java,” Proc. 12th Annual IFIP WG 11.3 Conf. on Database Security, Porto Carras, Greece, August, 1998. [22] Van de Riet, R.P., and Beukering, J., “The integration of security and integrity constraints in Mokum”, in Biskup, J., Morgenstern, M., and Landwehr, C. E. (eds.), Database Security, VIII, Status and Prospects, IFIP, North-Holland, 1994, pp. 223-246.
25
[23] Van de Riet, R.P., and Burg, J.F.M., “Modelling Alter-egos in Cyberspace: who is responsible?”, Proc. of WebNet 96, San Francisco, 1996, AACE, Charlottesville, USA, pp. 462-467. [24] Van de Riet, R.P., and Burg, J.F.M., “Linguistic Tools for Modelling Alter Egos in Cyberspace: Who is Responsible?” Journal of Universal Computer Science, Vol 2, number 9, Springer,1996, pp. 623-636. [25] Van de Riet, R.P., and Burg, J.F.M., “Modelling Alter-egos in Cyberspace using a Work Flow Management Tool: who takes care of Security and Privacy?”, Submitted. [26] Van de Riet, R.P., and Gudes, E., “An object-oriented database architecture for providing high-level security in Cyberspace,” in P. Samarati and R.S. Sandhu, Database Security X: Status and Prospects, Chapman & Hall, 1997, pp. 120– 144 [27] Van de Riet, R.P., Janssen, W. and de Gruijter, P, “Security moving from Database systems to ERP systems,” in R. Wagner (Ed.), Database and Expert System Applications, IEEE Computer Society, 1998, pp. 273–280 [28] Weeks, J.A., Cain, A., and Sanderson, B., “CCI-Based Web security: a design using PGP,” URL “http://sdg.ncsa.uiuc.edu/˜ jweeks/www4/paper/current rev.html” [29] MicroSoft Corp., URL: http://microsoft.com/intdev/security/misf13 4.htm
Appendix: Initialising, initiating, activating and deactivating processes and activities We assume that the system is initially ‘empty’—see figure 12.
Init ProcState Auth 8 p : PROC ; a : ACT act state (p ; a ) = dormant con state = [ ] mac = [ ] Figure 12: The initial state of the system Once the system is operational, specific workflow processes may be instantiated. Figure 13 describes this action. Note that the system assigns some unique process identifier. Also note that a process is instantiated by enabling an activity that has no input connectors.
26
InitWf ProcState act ? : ACT proc ! : PROC act input (j fact ?g j) = 9 p : PROC (p ; act ?) 62 dom act state ^ proc ! = p act state 0 = act state f(proc !; act ?) 7! enabled g proc ! 6= all Figure 13: Initiating a workflow process instance In addition to activities that are enabled because a new process instance has been created, the system may also enable new activities when the state of the connector allows it. Figure 14 describes what happens when a connector is fired.
FireCon
ProcState OnlySys con ? : CON ; proc ? : PROC let from == act output (j fcon ?g j) let from tokens == settobag (fcon ?g (fproc ?g from )) con state = con state 0 ] from tokens let to == act input (j fcon ?g j) (8 a : ACT a 2 to ) act state (proc ?; a ) = dormant ) ^ act state 0 = act state fa : ACT j a 2 to (proc ?; a ) 7! enabled g Figure 14: Firing a connector Sometimes it will be necessary to convert sets to bags. This is accomplished by the following specification:
[X ] settobag : P X ! bag X 8x : X; p : PX x 2p,x @ ? settobag (p ) ^ x 2 p , (settobag (p ))]x
=1
It is useful in a number of places to be able to determine the identities of messages (and objects) that a subject needs access to, to be able to perform an activity; act inst mes in figure 15 computes this. This will be useful, amongst others, to grant the responsible subject access to the required methods. Note that all global relevant objects and all relevant objects local to the instance are considered. 27
ProcObjs ProcState OnlySys act inst mes : SUBJ PROC ACT !7 P(SUBJ OBJ MES ) act inst mes = fs : SUBJ ; p : PROC ; a : ACT (s ; p ; a ) 7! fm : MES ; o : OBJ ; c : CLASS j (m ; c ) 2 act mes (a ) ^ class (o ) = c ^ (obj local to (o ) = all _ obj local to (o ) = p ) (s ; o ; m )gg Figure 15: To determine messages that may need to be sent during an activity activation Once activated, the responsible subject is able to perform the required actions. Eventually the activity will complete and be formally concluded by the responsible subject using CompleteAct as described in figure 16. Note that only the responsible subject is able to complete the activity.
CompleteAct ProcState Auth proc ? : PROC ; act ? : ACT ; sender ? : SUBJ next con : CON act state (proc ?; act ?) = active (sender ?) next con = SelectCon 3 next con 2 act output (j fact ?g j) act state 0 = act state f(proc ?; act ?) 7! completed (sender ?; next con )g con state 0 = con state Figure 16: Completing an activity Once access rights have been revoked from the subject, the activity may return to the dormant state. This is done using DeactivateAct (figure 17).
28
DeactivateAct
ProcState OnlySys proc ? : PROC ; act ? : ACT con : CON 9 s : SUBJ act state (proc ?; act ?) = completed (s ; con ) act state 0 = act state f(proc ?; act ?) 7! dormant g con state 0 = con state ] [ (con ; (proc ?; act ?))]] Figure 17: Returning an activity instance to the dormant state
29
