Towards a role based framework for distributed systems management

TOWARDS A ROLE BASED FRAMEWORK FOR DISTRIBUTED

SYSTEMS MANAGEMENT

Emil C. Lupu, Morris Sloman

Department of Computing

Imperial College180 Queen’s GateLondon, SW7 2BZ, UK

Email: e.c.lupu@doc.ic.ac.uk, m.sloman@doc.ic.ac.uk

Abstract

Roles have been widely used for modeling the authority, responsibility, functions andinteractions associated with manager positions within organizations. In this paper we discussthe issues related to specifying roles for both human and automated managers of distributedcomputer systems. The starting point is that a role can be defined in terms of theauthorization and obligation policies, for a particular manager position, which specify whatactions the manager is permitted or is obliged to do on a set of target objects. This permitsindividuals to be assigned or removed from positions without respecifying the policies for therole. However these policies are insufficient for fully specifying relationships betweenmanagers and the targets they manage or between different manager roles. There is a need tospecify the interaction protocols and how managers coordinate and synchronize theiractivities.

The role based framework consists of a set of tools enabling the creation of roles frompolicies, the specification of the concurrency constraints for role activities and thespecification of protocols for role interaction. In addition, the issues related to conflicts whichcan occur between policies within a role or between interacting roles are briefly discussed.

Keywords:

distributed systems management; management roles; role interactions;management policy; obligation; authorization; policy conflicts.

1

1. Introduction

Role Theory, which is widely used for enterprise modeling, postulates that individualsoccupy positions in an organization [1, 2]. Associated with each position is a set of activitiesincluding required interactions that constitute the responsibilities of that position. A role thusidentifies the authority, obligations, functions and interactions, associated with a positionsuch as vice president, board director, security administrator or operator responsible forreactor number three.

Networks and distributed systems can be very large and complex requiring the partitioning ofmanagement responsibility according to management functions such as securityconfiguration, fault or performance management, but the partitioning may also reflectorganizational, geographical or even network layer boundaries. There are thus likely to bemany different roles associated with the management of such systems. Role theory providesus with very useful concepts for a management framework and has been applied to otherareas of Information Technology such as organizational analysis and office automation.The development of new IT techniques has introduced the ideas of assisting human managersin their tasks. The efforts have been oriented in two directions: assisting the manager at theinformation level and providing support for office automation. Three approaches can bedistinguished: Computer Supported Cooperative Working (CSCW) attempts to provide toolsfor office assistance [3-6], the object-oriented approach models the knowledge andcharacteristics of different roles [7-9] and the process oriented approach is directed towardsoffice automation [10-12].

In large systems it is essential to distribute management tasks where required and if thisdistribution follows the organizational structure the management system can be integratedwithin the current functioning of the organizations. Clear specifications of the managementpolicies, representation of the organizational structure and partial automation of themanagement tasks are needed in order to realize and integrate a management framework. Ourinitial motivation for implementing roles in the management system was to simplify thespecification of policies so that they do not have to be changed when managers are assignedto new positions. The idea of “intelligent” automated agents which can be assigned to aparticular role has been used in Distributed Artificial Intelligence and is being applied inareas such as information location for the world-wide web. The people assigned to roles donot work in isolation but interact and cooperate with other roles. Building on concepts fromrole theory and organizational analysis, we intend to provide a framework where both humanand automated agents coexist and which provides support for the communication andcoordination between these agents. The overall motivation for implementing roles in acomputer system, which supports people is thus to simplify the specification of the systemand to provide a framework which can model the organizational structure. Although we areaiming this at the Network and Distributed Systems Management, we consider that ourframework and tool support will be useful for office automation and role based access controlas well [13].

The starting point for this work has been to define a manager role as the set of authorizationand obligation policies for which a particular manager position is the subject [14] so insection 2 we explain the concepts and notation used for specifying management policies forthe actions of both human and automated agents. Section 2 also describes domains as ameans of grouping objects to which a policy applies. In section 3 we elaborate on theconcept of a role as a set of policies and indicate why this is insufficient for a role framework.In section 4 we discuss how role interaction can be specified and in section 5 we indicate howconcurrency issues such as parallelism and synchronization can be specified. In section 6 wepresent issues relating to conflicts of policies within and between roles. This is followed byan example of how the framework could be used to specify roles.

2

2.Domains and Policies

Large distributed systems may contain millions of objects so it is impractical to specifypolicies for individual objects. Objects are grouped in domains for specifying a commonmanagement policy or to structure and partition management responsibility. A domain is acollection of objects (actually references to object interfaces) which have been explicitlygrouped together for the purposes of management (c.f. file system directories or folders). If adomain holds a reference to an object, the object is said to be a direct member of thatdomain. A domain is an object, so may also be a member of another domain and is said to bea subdomain. Its members are indirect members of the parent domain. A domain serviceis provided for the manipulation of the membership information. Further, domain scopeexpressions can be specified determining the set of objects to which a policy applies. Forexample D1-D2-O3 represents the objects that are members of D1 with members of D2 andobject O3 excluded. Our concept of a domain is very similar to that of a directory in a typicalhierarchical file system. The policy which applies to a domain will, by default, propagate tosubdomains and to the objects within them, although this propagation can optionally bedisabled. A User Representation Domain (URD) is a persistent representation of thehuman within the computing system. When a person logs in, an adapter object (cf. loginshell) is created within the URD to act as the interface process between the person and thecomputer system. Other agents representing the human could also be created in the URD.Details on the domain structure and the relevant services can be found in [14, 15].

Policies establish a relationship between manager and managed object domains. Domains canhowever exist independently of policies, they are a method of grouping objects in a largesystem for management purposes. A policy expresses either an authorization – whatactivities the managers are permitted or forbidden to perform or an obligation – whatactivities the managers must or must not perform on the managed objects. The mode of thepolicy distinguishes between positive authorization (permitted: A+), negative authorization(forbidden: A-), positive obligation (must: O+) and negative obligation (must not: O-). Thegeneral format of the policies is given below with optional arguments within brackets:

policy_id mode [ trigger ] subject { action } target [ when constraint ] ;

The subject represents the set of managers assigned to carry out the actions on the set oftarget objects. Both sets are specified using domain scope expressions. Obligation policiescan be triggered by time or by composite events detected within the monitoring system [16].Constraints limit the applicability of the policy e.g. between the hours of 09.00 and 17.00.The policy format and use is described in [17]. Examples of policies are:

payment_1 O+ at [31/Dec/_] accountant

{ pay(percentage_of_profits, credit_transfer, pounds_sterling)} subcontractor ;

/* On 31 of December of every year the accountant is obliged to paya percentage of the profits in pounds by credit transfer to thesubcontractor. */purchase_1 A- u:users { purchase() } services

when u.type == anonymous ;

/* Anonymous users are forbidden to purchase services. */Policies can specify actions at different levels of abstraction. A refinement hierarchy cantherefore be built from the more abstract policies, which can only be interpreted by humans,to the enactable leaf level policies or rules which can be interpreted by automatedcomponents. Tools for policy editing and services have been implemented and are describedin [17].

3

3.Concepts for Role Based Management

In this section we elaborate on how the concepts of domains and policies can be applied tomodeling roles. In [1] a Role is defined as “a collection of rights and duties” and a Positiondescribes a status within the organization. The role specifies management actions (i.e.policies) which represent the behavior or dynamic aspects of the position which is essentiallya static concept. We loosen this definition to consider a role to be composed of a ManagerPosition Domain and a dynamic part consisting of a set of authorization and obligationpolicies which have the position domain as a subject. Assigning a manager to a positionmerely implies including the manager’s URD into the position domain. Role policies willpropagate to the URD and apply to the adapter object or other agents in the URD (see Fig. 1).Multiple URDs may be included in a position domain to represent sharing of a position by anumber of managers and a URD can be included in several position domains if the managerperforms multiple roles [14]. The advantage of using a position domain as the subject of thepolicies is that individuals (or automated agents) can be assigned to or withdrawn from a rolewithout having to respecify policies. In addition a position can temporarily exist withoutappointed managers to represent a vacant role. Note that the role policies can specifyactivities relating to target managed objects or other manager positions indicating arelationship such as supervision.

Human ManagerAssigned to RoleSubjectManager Position Domain User Representation DomainManager adapter objectURDTarget Managed Objects RoleRole obligation and authorisationpoliciesTarget ManagersFigure 1 Position Domains and Roles

A manager must be able to delegate his duties and/or his access rights to another provided heis authorized to do so. The need for delegation occurs in various situations such assubcontracting between organizations, when a manager is on leave and someone else takeson his roles or a manager assigns a role to another manager. A very simple form ofdelegation of a role from Manager A to Manager B can be achieved by replacing A’s URDin the position domain by B’s URD.

In general polices propagate to subdomains of a parent domain which is a subject or target ofa policy. Propagated policies may apply to a position domain but are not a component of therole associated with that position. For example the College policy for the use of computerspropagates to all the research students but is not a specific part of the obligations andauthorizations of their research role. A manager having his URD included in otherorganizational domains (research groups, experts on a particular subject) will be subject toother policies than those specified within the role(s) he is assigned to.

It would be very useful to be able to define a role template which can then be parameterizedwith specific target domains. It would thus be possible to define the role policy set as a classfrom which particular instances can be created. For example a role class could be defined fora region manager and this could be used to create North, South, East and West regionmanager roles. Each of the four roles instances has its own manager position and specific

4

target domains, but specifies the same policy activities and constraints for each role. Anadvantage of an object-oriented approach to specifying roles and policies classes is thatinheritance can be used to define new role classes in terms of the existing ones [18]. Policyclasses (used for defining role classes) are templates with variable subject or target domains.For example many companies have standard templates for their contractual agreements withsubcontractors. The template specifies standard terms and conditions for obligations of thecompany and contractor without knowing which of the company agents will implement themand to which subcontractors they apply.

It is possible to identify many different relationships between manager positions within anorganization. There is typically a hierarchical relationship which reflects organizationalstructure e.g. President, Vice-president, regional managers, site managers within a company.These hierarchical relationships include issues of delegation of responsibility from a superiorto a junior manager, supervision of activities of a junior and a junior manager reportingevents or status to a more senior manager. A second form of relation occurs as part of thetasks performed by managers [19]. For example the design and production managers have tonegotiate a start date for production of the new components and the designs have to becompleted before production can start. These task relationships include resource sharing,information access and coordination. Some roles provide a service to others and so client-server and contractual relationships have to be considered. The role framework has to bevery flexible to accommodate peer-to-peer as well as hierarchical relationships and to permitmulti-party interactions. A committee with chairman, secretary and cooperating members isa good example of mixing all the above types of role relationships.

Relationships cannot be fully specified by policies as there is a need to define interactionprotocols in terms of message content and permitted message sequences e.g. for contractnegotiation (see section 4). Multiple managers may be assigned to a role and concurrentlyperform the role policy activities so there is a need to synchronize completion or ordering ofactivities within a role. Policies can use events disseminated by the monitoring system tosynchronize their activities, but this is a low-level and difficult means of specifyingcoordination and synchronization between roles so there is a need for a higher level notationfor the specification of concurrency constraints (see section 5). For other studies relating tointer role relationships and possibilities for their graphical representation see [20-23].As represented in Fig. 2 our framework identifies for a role position: (i) the authorization andobligation policies related to target objects which may be other managers or shared resources,(ii) the relationships between roles which reflect the organizational structure, and (iii) bothintra- and inter-role concurrency constraints.

For Each Related Role

Oligation &Authorisation PoliciesFor Target Managed Objects Oligation &Authorisation PoliciesConcurrency Constraints SpecificationInteractionProtocolSpecificationManagerPositionDomainIntra-role Concurrency ConstraintsSpecificationFigure 2 Components of an Extended Role

5

4.Role Interaction

Managers performing different roles have to interact in order to achieve their tasks, co-ordinate their actions, share information and agree on their commitments. This sectionattempts to elaborate on the issues of interaction protocols between roles and proposes aframework suitable for both human and automated managers. The interaction protocol isrelated to the role activity and is a part of the specification of a relationship. When using theterm role interaction we refer to interactions between manager objects within role positiondomains.

4.1.Related work

Communication protocols in computer networks and telecommunication disciplines haveoften been specified using finite state machines or Petri-Nets. This approach is largelyunsatisfactory when dealing with complex interactions among human agents – the mainlimitations of these notations being:

•All the possible ‘states’ of the agents in the interaction have to be foreseen.

•Two party interactions can be specified but the notation introduces undesirable

complexity for multi-party interactions.

•The messages exchanged have no semantic value – they are transitions from one state

to another.A different approach, by computer scientists from an organizational and artificial intelligencebackground, attributes a meaning i.e. a semantic value to the type of exchanged messages andderives knowledge on the behavior of the manager from the message. This meaning is termedan “illocutionary” value. For example a statement such as “The URL of our documentarchive is ftp://dse.doc.ic.ac.uk/dse-papers” has an assertive value on the state of thesystem while a statement such as “I will perform the backup of the system by 9.00 pm” has acommisive value on the activities of the manager. The first system introducing such ideaswas The Coordinator [24, 25]. Winograd identifies the concept of Conversation for Action(CfA) based on the Speech Act theory [26]. Higher level protocol specifications follow thisline, among them logics such as Modal Action Logic [27], Conversational Clichés [28] andInformation System design [29]. This work is largely inspired by the desire to support co-operation between agents representing human managers.

De Greef’s notation [11] inherits features of a logic programming language, provides sets andintroduces the notion of agents. The notation is powerful enough to express multi-agentalgorithms such as the Contract Net [30]. Support for multi-agent interaction is provided bythe use of sets of receiver agents and by the ability to collect messages from multiple senders.The interaction specification is the description of a network style graphical specification alsoused in Winograd’s work. This notation has been implemented in April [31].

An approach based on Petri-Nets has been taken by Singh in [32], where interactions refer toa bi-directional synchronous mechanism for the coordination of agents. Multi-partyinteractions can be specified constraining all the interacting agents to synchronize. A graphicrepresentation can be used for interaction specification with the horizontal dimensionrepresenting the different interacting roles and the vertical dimension representing time.Singh’s specifications have a direct translation into Petri-Nets.

4.2.Issues for Role Interaction

The issues relating to a role interaction protocol are identified and discussed in thefollowing.

6

Human vs. Automated interactive entities

A communication protocol between automated agents has to be deterministic. Althoughheuristic approaches can be developed which include choices to represent non-determinism inthe protocol, the behavior of the automated agent then becomes unpredictable. Interactionsoccurring between human managers are always partly non-deterministic due to humanchoice. For example, a human manager might respond to a counter proposal by a request forfurther details even if this was not specified in the initial protocol. Most of the work in thearea constrains the human managers to the pre-defined protocol and concentrates oncapturing the illocutionary value of the messages exchanged. The protocol we are aiming atshould provide a flexible framework for communication between the human agents as well asa deterministic approach for communication between automated managers. Determinism forautomated managers can be ensured by restricting the use of the choice operators.Two-party vs. multi-party interaction

The problem of multi-party interactions is an underlying concern when modeling interactionsamong agents. Although techniques such as the Contract Net have been available for a longtime, most of the recent work does not deal with multi-party interactions. We believe thatmulti-party interactions are essential e.g. for specifying joint decisions or task allocation forroles. De Greef’s notation [11], and the April [31] language identify the need for sets in theinteraction specification language to express the multiple senders or receivers in aninteraction and for collecting the multiple messages received by one manager.The illocutionary value of the messages exchanged

In order to automatically derive a meaning from the messages exchanged they must be typed(request, reply, proposal, statement, etc.) and a finite Universe of Discourse (UoD) [29] mustdefine the set of all the types of messages used within the interaction. An illocutionary valuecan then be given to each type of message and rules can be built for deriving knowledge ofthe state of the system and the activities of the managers. We do not discuss illocutionaryvalue in this paper but make provision for it and recognize its benefits for assisting themanagers in their tasks.

The content of the exchanged messages

In the early studies of the interaction protocols the value of the message is the value of theillocutionary act it represents. These are entirely predefined in the protocol and a message hasthe same value regardless of the stage the interaction protocol has reached. Schmidt andSimone describe the case of a “bug form” which is filled in by the various managers in theprocess of the development of a software product [33]. The success of this protocol reliespartially on the fact that the constraints placed upon the different managers and the pastinteractions between them are explicitly represented within the exchanged message – the bugform. In particular, when the designer receives the bug form he has knowledge of thedifferent other stages – tests, specification scheme, etc. This highlights one of the mainlimitations of the actual protocol specification. In both The Coordinator and the de Greefspecification language, a received message triggers the same action regardless of the previous“history” of the exchanged messages1. Specifications like “release patch only after receivingtwo testing reports“ are desirable and should be accommodated.

1 In April [31] (an implementation of the de Greef specification language) variables can be maintained locally in

order to remember the previously exchanged messages. This approach is not satisfactory since it implieskeeping logs of the messages exchanged with each manager.

7

Interaction as a means of specifying synchronization

This approach is largely adopted in [32] where all the different parts involved in multi-partyinteractions have to synchronize. Although interactions can specify part of thesynchronization between managers, the synchronization is distributed in the role or managerspecifications among the different interaction protocols and is difficult to determine oranalyze. In particular, synchronization specification, based on interaction, cannot includeevents relating to the completion of a task. For example, using messages, it is difficult tospecify that a manager has to report to the sales director when a customer contract is signedand must then arrange delivery of materials to the relevant subcontractors and arrange for themanufactured components to be delivered and assembled before delivery to the customer.This requires interactions based on common events or messages in the manager, salesmanager, customer and subcontractors. A high level notation which includes events forbeginning/end of activities is desired. Concurrency specification is detailed in section 5.

4.3.The Proposed Interaction Specification Notation

The specification notation is separated into a global specification of the sequence of messagesand a local production rule-based specification for each manager, in order to achieve theflexibility for an interaction system that includes human managers. The global specificationincludes the description of the interacting parts and of a pre-defined sequence of messages. Itwill be graphical, but can be automatically transformed into a set of production rules whichcan then be changed, if necessary, within a manager.4.3.1.Configuring a sequence of messages

The global specification is aimed at giving a high level means of specifying the minimalsequence of messages exchanged in an interaction between the related parties. It thereforecontains the message types exchanged by the managers and offers a global view of theinteraction. Configuring a sequence of messages to define permitted message ordering can beachieved with the network style specification used by both de Greef and Winograd. This alsohas the advantage of representing the interaction as a finite state machine with each staterepresenting a manager at some point in the interaction [11, 25]. It is therefore possible totranslate this global specification into sets of production rules by representing the variousregular expressions recognizing each state of the finite state machine. The regular expressionsmatch a sequence representing the history of the exchanged messages (present in theincoming message) and trigger production rules. The production rules are distributed to eachmanager and constitute the local specification of the protocol. This representation by regularexpressions is possible because the messages are typed and the Universe of Discourse isfinite. The following example shows the sequence of messages for the haggling over a pricebetween a buyer and a seller (from [11]).

6B: rejectS: proposeB: acceptB: counterS: acceptS: counterS = seller B = buyerS: reject12345Figure 3 The haggling protocol

8

This specification is minimal but represents the messages that are essential for the interactionto proceed and the initial/final states of the protocol.

4.3.2.A local specification for the messages exchanged and the production rules.The content of a message

The exchanged message should contain the sequence of the types of the previous exchangesin the interaction (we assume here trusted interactions). This is like the bug form whichcarries the signature of the different agents finding, analyzing or correcting the bug. Includingthe type (but not the content) of the previous exchanges in the message allows the receivingmanager to have knowledge about the previous steps of the interaction. The message shouldalso contain the source manager and the destination managers. A special feature that willenable changes in the protocol is to allow the sender of the message to specify additionaltypes of desired answers. Figure 4 shows a typical “message form” representation.

From: A1Log : Counter.PropContent:To: A2Answer: requestFigure 4 A message form

In textual form a message is represented by:

message: ‘TO:’ , ‘FROM:’ ,

‘LOG:’ /* sequence of the types of messages exchanged during

the interaction */‘CONTENT:’

‘ANSWER’:

As an example the message

[TO: accountant, FROM: Mr. Beecham, LOG: request.payment,

CONTENT: card_no: xxx exp_date: xxx, ANSWER: more_id]

means that the accountant has received a payment from Mr. Beecham subsequent to a requestfor payment. The payment was made by a credit card and Mr. Beecham offers the accountantthe possibility to reply by requesting additional identification elements. ‘request’, ‘payment’and ‘more_id’ must belong to the Universe of Discourse and the sequencerequest.payment.more_id can match a regular expression and trigger one of the rulesdefined in the protocol of the accountant.Formal specification

A production rule is composed of a regular expression, a guard and a block of instructionsgiving the different reply possibilities. The regular expressions match the sequence of typesof the messages exchanged ( Log field of the incoming message) and trigger the rules. Guardsare predicates expressed on the contents of the message. The guards provide the means todistinguish between messages of the same type and with the same history in order to trigger

9

different rules. The body of the production rule is formed of a sequence of activities to beperformed. Sending a message (including replying to the incoming message) is considered asan activity. Different alternatives are separated by the keyword ‘or’. This keyword gives afreedom of choice for the human manager but its use is restricted for automated managers.Alternative answers can also be expressed within the message by specifying the type of theanswer accepted in the ‘answer’ field of the message.

It should be easy to include the possibility of deriving commitments or abstracting plans in asystem based on production rules triggered by regular expressions. Interactions based onabstraction of plans are investigated in feature interaction within intelligenttelecommunication systems [34, 35].

Production rules for the protocol specification

The possible replies a human manager can send to a message are given by the set ofproduction rules local to the manager. In the following example, we represent the sending ofa message by a tuple [type, content, additional answer] -> destination. Theproduction rules for the buyer and seller in the haggling protocol shown in Figure 3 are asfollows.Seller

(1) [propose, price, ] -> buyer

(3) propose.{counter}.counter =>

[reject, reasons, ] -> buyer

or {[accept, , ] - > buyer ; order_delivery } or [counter, new_price, ] -> buyer,(4) *.accept => order_delivery;(5) *.reject =>

Rule (1) specifies that the seller should initiate the interaction by proposing a price.Rule (3) specifies that after receiving the initial proposal and one or more counter-offers, the seller can reject the last counter-offer by giving reasons, can accept it andorder the delivery of the product or can make a new counter-offer. Rule (4) indicatesthat the seller must order delivery if the proposal is accepted and rule (5) indicates noaction if the proposal is rejected.

Buyer

(2) propose.{counter} => [reject, reasons, ] -> seller or [accept, desired_delivery_date, ] -> seller or [counter, new_offer, ] -> seller(6) *.reject =>

(7) *.accept => payment;

Rule (2) specifies that after receiving a proposal and zero or more counter offers, thebuyer can reject giving reasons, accept with a desired delivery date or return a counteroffer with a new price.

The advantage of such a notation is that new rules can be very easily added to change thealternatives defined by the protocol. Also a rule can be changed without needing to recompilethe whole protocol specification again. For example, rule (8) could be added for the seller topermit rejection of an offer only after at least two counter offers (assuming reject is notpresent in rule (3) :

(8) propose.counter2.{counter} => [reject, reasons, ] -> buyer

10

Dynamic aspects

In order to indicate the dynamic features that can be used in this framework we assume thatthe seller offers the possibility to the buyer to request additional information about theoffered item. The seller needs to indicate an extension to the universe of discourse which isaccomplished by a counter message with moreinfo as a parameter in the answer field i.e.the seller now can now respond to a moreinfo message. Rule (9) is derived from rule (3)to achieve this.

(9) propose.{counter}.counter => [counter, newask, moreinfo] -> buyer

or [reject, reasons, ] -> buyeror [accept, delivery, ] -> buyer

The rules for the buyer would need to be extended to permit the generation of a moreinforequest, but this is not shown.Discussion

Including humans along with automated managers in a management framework introducestrade-offs between the flexibility and assistance desired by a human manager and theefficiency aimed at in automation. This is particularly true in the case of interactionprotocols. Classical network interaction protocol specifications such as ESTEREL [36]assume a deterministic specification and concentrate on the efficiency of the interaction. Theprotocol specification is compiled and can be used to generate outline code for anapplication. It is assumed that the protocol specification remains unchanged during thelifetime of the applications. The various alternative answers to a message are all known whenthe protocol is specified and the activities are all performed within the application. Specifyingprotocols which can change in ESTEREL would mean foreseeing and making provision forall the possible permitted answers (answer field of the message) and thus expressing choiceswhich may possibly cover all the Universe of Discourse. Introducing human managers in theset of interacting agents implies making provision for the human choice although this limitspart of the protocol to human implementation. In order to adapt the protocol to the manager’srequirements the specification must be flexible enough to allow changes without completerecompiling, as is possible with the rule based interpretative approach. Finally in order toassist the human manager, knowledge should be derived from the exchanged messages orfrom the history of the protocol i.e. the set of previous messages within the interaction.

5.Concurrency of Activities within Policies

As mentioned previously there is a need to specify the parallelism and synchronizationbetween the activities within roles and between roles. There are many well known notationsfor specifying concurrency among processes – among them CCS, CSP and Petri-Nets arewidely used. Our aim is not to provide a new calculus system for the specification ofconcurrency but rather to provide an easy way of specifying sequences of activities within therole framework. In this section we propose a graphical notation based on Petri-Nets whichcan then be translated into a textual notation.5.1.

Graphical Concurrency Notation

An activity expression is represented by square box with a transition (circle) preceding andfollowing representing an event (token). The required concurrency operators are representedin Fig. 5.

This Petri Net style representation offers the advantage of representing the events as tokenstriggering the different activities, but this does increase the complexity of the representation.Although Petri Nets style representations are convenient for human usage they really need tobe translated into a textual notation for computer based interpretation.

11

a1a1 ; a2

a1 followed by a2a1

a2

a1a2a1 || a2

a1 and a2 can be executed concurrently

a2a1a1 # a2

a1 and a2 conflict, so they can not be

executed at the same time

on condition do a1

a1a2a1 | a2

the token is given to only onetransition along the dashed lines

a1a2a1 & a2

both tokens are needed for the transition along the dashed lines

Figure 5 Petri Net style concurrency representation

5.2.

Textual Concurrency Notation

A role consists of policies which specify activities. We refer to the activity a2 within thepolicy P3 of the role “Accountant” by Accountant:P3:a2. A sequence of activitiesseparated by semicolons forms a block enclosed in brackets:

{accountant:p2:register_payment ; accountant:p3:issue_check}.

An activity can be followed by a sequence:

R1:p2:act2 {R2:p3:act4 ; R1:p3:act5}.

However the specification of a sequence of activities must also provide ways of expressingconcurrency. We introduce the “||” operator for this purpose. A1 || A2 allows the twoactivities to be executed concurrently and the execution of the sequence continues when anyof these activities are completed. Alternatives between activities can be expressed with the“|” operator:

{{accountant:p2:register_payment;accountant:p3:issue_check}|accountant:p4:delay_payment} accountant:p5:produce_report.

The “&” operator expresses the need for synchronized activities, e.g. {A1 & A2} states thatboth A1 and A2 can be executed concurrently but they both have to be completed before thesequence proceeds. We also permit conditional expressions of the form:

{on (condition) do sequence}

Finally an operator “#” is needed to indicate conflicting activities which must not be executedconcurrently e.g. accountant:p2:update_records # accountant:p3:backup_records.5.3.

Event based semantics

Policies are triggered by events monitored within the distributed system and we use anotation called GEM [16] to combine simple events to form composite, more abstract events.

12

The semantics of the concurrency notation can be defined in terms of events for thebeginning and end of an activity execution. Events can also be used to express an orderbetween two sequences of activities. Further, explicit events are declared within a policyspecification in order to trigger the activities. The notation of an activity in a sequence istherefore extended to permit optional events e.g. [event] activity [event] specified by theuser. All events, other than those explicitly declared by the user, will be automaticallygenerated by a translator from the concurrency specification. The concurrency operators canbe translated into compound event declarations. In the following examples, ix is an eventindicating start of activity ax and ixf is an event indicating the end of activity ax.

a1i1f ; i2a2 => i2 = i1f

/* The event i1f marking the end of a1 is assigned to i2 forthe start of a2. If a1 is explicitly triggered by an event e2then i2 >= i1 (i2 must occur after i1) and i2 = i1f & e2*/i1f{i2 a2 i2f & e3 a3 i3f} i4 =>

i2 = i1f, i3 = i1f & e3, i4 = i2f & i3f

/* The event i2 triggering a2 is given by i1f. The eventtriggering a3 is i3 = i1f & e3 (e3 is declared by the user).The event finishing the sequence is i4 = i2f & i3f. */

The sequence a1{a2 & [e3] a3} a4 is translated into i2 = i1f, i3 = e3 & i1f, i4 = i2f & i3f.This semantics based on events is consistent with the other tools used in this framework. Theevents used in the monitoring system are also used to trigger policies and the receipt of amessage during an interaction also generates an event. It is therefore possible to inter-relatethe policy triggering mechanism with the interactions and the specifications of sequences ofactivities. For example an activity a1 can be performed only if another activity a2 hasfinished and an event message is received allowing a1 to continue.

6.Conflicts

In this section, we briefly discuss the conflicts which may occur between the policies and thepossible conflict detection mechanisms. Policies reference managers and managed objectsas sets within domains. Preventing these sets from overlapping is not practical nor desirable.A classification of the conflicts based on the overlapping sets of managers, activities andmanaged objects is presented in [37]. We will discuss here two types of conflicts, namelymodality and application specific conflicts.6.1.

Types of Conflicts

Modality conflicts occur if there is both a positive and negative authorization or obligationpolicy with overlap of subjects, targets and activities (see Fig. 6). Work in this area, restrictedto the authorization policies, can be found in [38]. Our conflict detection mechanismdistinguishes between potential conflicts which are detected by analyzing the overlapsbetween the domain scope expressions and real conflicts needing precedence relationshipsbased on domain nesting or priorities in order to resolve the conflict. There is a need to beable to include objects in multiple domains and to specify multiple policies for a domain so itis not possible to prevent conflicts. The aim of the conflict detection mechanism is then tofind all the real conflicts among the potential ones. There are various criteria for establishingthe precedence between conflicting policies, among them priorities, distance [39], andnesting [38]. We have experimented with domain nesting to establish both an idea of distancebetween the policy and the objects to which it is applied, and of priorities. In Fig. 7 thepositive authorization takes precedence over the negative since it refers to “inner” domainse.g. the system administrator is authorized to change the system files although users generallyare forbidden.

13

A+SubjectsActivitiesTargetsA-Figure 6 Conflict of Authorization

SubjectsTargetsA+ActivitiesA-Figure 7 Domain Nesting

Application specific conflicts cannot be determined by examining overlaps or policymodalities. For example the same manager is not permitted to both enter a payment and signthe check for the payment. We specify these conflicts using meta policies (i.e. policies aboutpolicies) in the form of a logical predicate over the managers, activities and managedobjects sets expressed in the policies. The predicate is a normal form containing membershipoperations on these sets. This type of expression can be written or translated in a logic basedprogramming language such as Prolog which we used to specify the meta policies to detectthe conflicts from [37]. For example, the above conflict can be specified as:

any(P1,P2) belonging (policy_scope_expression)

false <- intersect (P1.managers, P2.managers)

&& belongs(‘enter’, P1.activities)&& belongs(‘sign’, P2.activities)&& belongs(‘check’, P2.targets)&& belongs(‘payment’, P1.targets)

6.2.The scope of Conflict Detection

Conflict checking must ensure that the related parts do not have conflicting obligations andthat there is a corresponding authorization policy permitting the actions specified within anobligation policy. Role definition and implementation cannot be centralized in a large system,so the cost of conflict checking in terms of computation can be very high. A single role iscentralized and so can be checked comparatively easily. This will ensure that all the activitiesassigned to the managers sharing the position can be performed. The explicit specification ofrelationships between roles identifies the distributed roles which must also be checked forinter-role conflicts and so provides some bounds on the problems of scale.

7. Example: Multimedia Purchasing Franchise

We consider the relationships between the customers (users), a software retailer(Presentation_AG) and its subcontractors. The Presentation_AG allows customers topurchase products from subcontractors in a multimedia session. The users can purchase theproducts and pay the retailer for the products purchased. The retailer has a sales managerresponsible for the sale of the subcontractor products to the users and a security managerresponsible for the authentication of users.

14

Users from particularNetwork Access PointsPresentationAgentSecurity ManagerBlack listed UsersFigure 8 Connection to the Presentation agent

This example outlines the relationship between the user role and the security manager role(Fig. 8). This relationship governs their behavior when interacting with one another forestablishing a connection between the users and the Presentation_AG agent. Policies relatingto each role’s obligations and authorizations describe their responsibilities while theinteraction protocol specifies the order of the exchanged messages. The policies are:

p_access_1 A+ users/NAP2/England + users/PA3/England

{ connect_to() } Presentation_AG ;

p_access_2 A- u:BlackList_users { connect_to() } Presentation_AG ;p_access_3 O+ security_manager {

/* permanent address should not be used to deny access */} u:Users

when u.type == corporate ;

p_access_4 A+ security_manager { suspend() } user_connection;p_access_5 O+ on connection_request security_manager

{/* authenticate */} u:users ;

p_access_6 O+ on fraudulent_connection_attempt security_manager {

enter(action) } security_log ;

These policies specify that users accessing the service from England and users with apermanent address in England are authorized to connect. Users on the Black List are notauthorized to connect. These two policies can create a conflict if a user belongs to both thedomains users/NAP/England and BlackList_users. This modality conflicts can bedetected by domain overlap and automatically solved by giving precedence to the denial ofaccess. The policies also specify that the security manager is authorized to suspend aconnection and any fraudulent connection attempt will be logged. The security manager hasto authenticate the user and corporate users should not be denied access when located at theirpermanent address. The interaction protocol is given by the following production rules:

2Network Access Point3Permanent Address

15

User

[connect, ,] -> security manager

connect.request :: request = authentication =>

[send, (client_no, PIN), ] -> security manager

/* if the request regards the authentication the user sends itsclient number and its PIN */

Security Manager

connect => [request, (client_no, PIN) , ] -> user

connect.request.id :: content = client_no, PIN

&& (member(client_no,corporate users)

|| member(From, authorized NAP) || client_no = anonymous)

=> valid = check(client_no, PIN);

if (valid)

[authorization, authorization_Id , ] -> user or [denial , reasons, ] -> user

/* the security manager can still deny access forother reasons */

else {

event(fraudulent_connection_attempt);enter(action, security_log);

}

/* The restrictions on the access are implemented within theinteraction protocol. The guard implements the criteria on which theauthorization to connect is issued.*/

This example also outlines the connection between the policies and the interaction protocols.Policy p_access_5 is implemented by the interaction protocol since it specifies theauthentication of the user. The receipt of a message constitutes an event which can trigger apolicy – the security manager has to authenticate the user on receipt of a connection request.Finally the sequence of activities in the related roles is given by:

user:request_connection ; security_manager:authenticate_user ;[fraudulent_connection_attempt] security_manager:enter(action,log)

This example also outlines the need to include a concurrency specification within the formaldescription of the relationship.

8. Conclusions and Further Work

Tools for specifying policies and maintaining the refinement hierarchy have beenimplemented [17] together with the domain service to support this. We have experimentedwith implementing conflict detection for a set of policies although further work is required onthis. We still have to provide tools to support the proposed notation for specifyinginteractions and concurrency and integrate this within an object oriented role specificationframework

There is increasing interest in role based access control and our concepts of roles andauthorization policy can be used for specifying this. Our framework could also be used fororganizational analysis to explicitly specify and analyze roles within organizations. There isa need for this sort of framework for managing intelligent networks – for example a virtualprivate network would have three overlapping domains corresponding to the network

16

provider, service provider and customer [40, 41] with at least one (and probably more)manager roles relating to each domain.

The key concepts identified in our role framework are a role as a set of policies relating to aparticular manager position and the notation to specify policies. This was extended toinclude role interactions and concurrency as part of the inter-role relationship specification.The framework must cater for a variety of role relationships. In particular, the formalismdefined has to offer the flexibility required for human managers and good support for officeautomation. Tools are also needed to analyze the policies within and between related roles forconflicts and inconsistencies.

One of the problems we have identified arises when a human manager is assigned to multipleroles so the URD representing the manager is included in multiple domains. All the rolepolicies propagate to the manager and it is not possible for the manager to have sessions inwhich some of the roles are enabled and others are disabled. We are investigating a solutionin which the URD is not included in the position domain, but instead a manager agent isincluded in the position domain and a session is set up between the object adapter in themanager’s URD and the agent in the position domain. It would then make it easier for themanager’s object adapter to distinguish between sessions corresponding to particular rolese.g. by mapping a session to a particular window on the manager’s terminal.

Acknowledgments

We acknowledge financial support from the EPSRC RoleMan project (No. GR/K37512). Weare grateful to BT for permission to use the Travel Co scenario as an example of managementpolicies. Many thanks for comments which have improved both the content and the form ofthis report to René Wies, Nicholas Yialelis, Nikolaos Skarmeas, Damian Marriott andMasoud Mansouri-Samani.

References

[1][2][3]

B. J. Biddle and E. J. Thomas, Role Theory: Concepts and Research, New York: RobertE. Krieger Publishing Company, 1979.

B. J. Biddle, Role Theory, Expectations Identities and Behaviour, Academic Press Inc.,1979.

K. Crowston, T. W. Malone, and F. Lin, “Cognitive Science and Organisational Design:A Case Study of Computer Conferencing,” in Computer Supported cooperative Work:A Book of Readings, I. Greif, Ed.: Morgan Kaufmann Publishers Inc., pp. 713-740,1988.

T. W. Malone, K.-Y. Lai, and C. Fry, “Experiments with Oval: a Radically TailorableTool for Cooperative Work,” ACM Transactions on Information Systems, vol. 13, no. 2,pp. 177-205, 1995.

T. W. Malone, “Computer Support for Organisations: Towards an OrganisationalScience,” MIT Sloan School of Management, Working Paper 85-012, Management inthe 1990s, Sept. 1985.

C. A. Ellis and G. J. Nutt, “Office Information Systems and Computer Science,” inComputer Supported Cooperative Work: A book of readings, I. Greif, Ed.: MorganKaufmann Publishers Inc., pp. 199-247, 1988.

B. Pernici, “Objects with Roles,” ACM Conference on Office Information Systems,Cambridge (MA), pp. 205-215, 1990.

[4][5][6][7]

17

[8][9]

B. Singh, “Interconnected Roles (IR): A Coordination Model,” MCC, Technical ReportCT-084-92, July 1992.

C. Martens and F. H. Lochovsky, “OASIS: A Programming Environment forImplementing Distributed Organizational Support Systems,” ACM Conference ofOrganizational Computing, Atlanta (Georgia-U.S.), pp. 29-42, 1991.

[10]N. Skarmeas, “Organisations through Roles and Agents,” International Workshop on

the Design of Cooperative Systems (COOP’95), Antibes-France, 1995.[11]P. de Greef, K. L. Clark, and F. G. McCabe, “Towards a Specification Language for

Cooperation Methods,” 16th German AI-Conference, GWAI’92, Berlin, pp. 313-320,1992.[12]C. Bußler, “Capability based Modelling,” First International Conference on Enterprise

Integration Modelling, pp. 389-398, 1992.

[13]E. C. Lupu, D. A. Marriott, M. S. Sloman, and N. Yialelis, “A Policy Based Role

Framework for Access Control,” First ACM/NIST Role Based Access ControlWorkshop, Gaithersburg, USA, Dec. 1995.

[14]M. S. Sloman, “Policy Driven Management for Distributed Systems,” Journal of

Network and Systems Management, vol. 2, no. 4, pp. 333-360, 1994.[15]K. P. Twidle, “Domain Servicies for Distributed Systems Management,” Imperial

College - Department of Computing, Ph.D. Thesis 1993.

[16]M. Mansouri-Samani and M. S. Sloman, “GEM-A Generalised Event Monitoring

Language for Distributed Systems,” Imperial College - Department of Computing,Research Report 95/8, 1995.[17]D. A. Marriott, M. S. Sloman, and N. Yialelis, “Management Policy Service for

Distributed Systems,” Department of Computing - Imperial College (London),Research Report DoC 95/10, September 1995.[18]R. S. Sandhu, E. J. Coyne, H. L. Feinstein, and C. E. Youman, “Role-Based Access

Control Models,” to be published in IEEE Computer, 1996.[19]R. A. Hirscheim, “Understanding the Office: A Social-Analytic Perspective,” ACM

Transactions on Office Information Systems, vol. 4, no. 4, pp. 331-344, 1986.

[20]T. W. Malone and K. Crowston, “The Interdisciplinary Study of Coordination,” ACM

Computing Surveys, vol. 26, no. 1, pp. 87-119, 1994.

[21]O. A. Oeser and F. Harary, “A Mathematical Model for Structural Role Theory, II,”

Human Relations, no. 17, pp. 3-17, 1964.[22]O. A. Oeser and F. Harary, “Role Structures: A description in Terms of Graph Theory,”

in Role Theory: Concepts and Research, B. J. Biddle, Ed. New York: Robert E. KriegerPublishing Company, pp. 92-102, 1979.

[23]Z. Milosevic, A. Berry, A. Bond, and K. Raymond, “Supporting Business Contracts in

Open Distributed Systems,” Second International Workshop on Services in Distributedand Networked Environments, Whistler, British Columbia-CA, pp. 60-67,1995.

[24]F. Flores, M. Graves, B. Hartfield, and T. Winograd, “Computer systems and the

Design of Organisational Interaction,” ACM Transactions on Office InformationSystems, vol. 6, no. 2, pp. 153-172, 1988.[25]T. Winograd, “A Language/Action Perspective on the Design of Cooperative Work,” in

Computer Supported Cooperative Work: A Book of Readings, I. Greif, Ed.: MorganKaufmann Publishers Inc., pp. 623-653, 1988.

[26]J. R. Searle, Speech Acts: An Essay in the philosophy of Language, Cambridge

University Press, 1969.

[27]J. Pitt, M. Anderton, and J. Cunningham, “Normalized Interaction Between

Autonomous agents: A Case Study in Interorganizational Project Management,”

18

International Workshop on the Design of Cooperative Systems (COOP’95), Antibes-France, pp. 76-95, 1995.

[28]C. Laufer and H. Fuks, “ACCORD Conversation Cliches for Cooperation,”

International Workshop on the Design of Cooperative Systems (COOP’95), Antibes-France, pp. 351-369, 1995.

[29]P. Johannesson, “Representation and Communication - A Speech Act based approach to

Information Systems Design,” Information Systems, vol. 20, no. 4, pp. 291-303, 1995.[30]R. G. Smith, “The Contract Net Protocol: High-level communication and control in a

distributed problem solver,” IEEE Transactions on Computers, vol. 29, no. 12, pp.1104-1113, 1980.[31]F. G. McCabe and K. L. Clark, “April - Agent process interaction language,” in

Intelligent Agents, vol. 890, Lecture Notes in Artificial Intelligence, N. Jennings and M.Wolldridge, Springer-Verlag, 1995.[32]B. Singh and G. L. Rein, “Role Interaction nets (RINs): A Process Description

Formalism,” MCC, Technical Report CT-083-92, July 1992.

[33]K. Schmidt and C. Simone, “Mechanisms of Interaction: An approach to CSCW

Systems Design,” International Workshop on the Design of Cooperative Systems(COOP’95), Antibes-France, pp. 56-75, 1995.[34]N. D. Griffeth and H. Velthuijsen, “Reasoning about goals to resolve conflicts,” Int.

Conf. on Intelligent Cooperative Information Systems, Los Alamitos (Calif.), pp. 197-204, 1993.

[35]H. Velthuijsen, “Distributed Artificial Intelligence for Runtime Feature-Interaction

Resolution,” IEEE Computer, pp. 48-55, August 1993.

[36]G. Berry and G. Gonthier, “The Esterel Synchronous Programming Language: Design,

Semantics, Implementation,” Journal of Science of Computer Programming, vol. 19,no. 2, pp. 87-152, 1992.

[37]J. D. Moffett and M. S. Sloman, “Policy Conflict Analysis in Distributed System

Management,” Ablex Publishing Journal of Organisational Computing, vol. 4, no. 1,pp. 1-22, 1994.

[38]A. Heydon, M. Maimone, J. Tygar, J. Wing, and A. Zaremski, “Miro: Visual

Specification of Security,” IEEE Transactions on Software Engineering, vol. 16, no. 10,pp. 1185-1197, 1990.[39]M. M. Larrondo-Petrie, E. Gudes, H. Song, and E. B. Fernandez, “Security Policies in

Object-Oriented Databases,” IFIP Database Security: Status and Prospects, pp. 257-268, 1990.[40]B. Alpers and H. Plansky, “Concepts and Application of Policy-Based Management,”

in Integrated Network Management IV, A. S. Sethi, Y. Raynaud, and F. Faure-Vincent,Eds. Santa-Barbara (U.S.A.): Chapman & Hall, pp. 57-68, 1995.[41]B. Alpers, H. Plansky, and R. Sauerwein, “Applying Domain and Policy Concepts to

Customer Network Management,” International Switching Symposium, 1995.Emil C. Lupu is currently a research assistant at Imperial College, London, workingtowards the Ph.D. degree. His research interests include role based management frameworksfor network and systems management, role based access control, management policies andcomputer supported collaboration tools for organizational structures. He received his diploma(Ingénieur, M.S.) in computer science from the Ecole Nationale Supérieure d’Informatique etde Mathématiques Appliquées de Grenoble (ENSIMAG), Grenoble, France.

Morris Sloman has a Ph.D. in Computer Science from the University of Essex in theU.K. He is a Reader in the Department of Computing at Imperial College, London. His

19

research interests include architecture and languages for heterogeneous distributed systems,distributed systems management and security. He was technical director of the ESPRITfunded SysMan collaborative project which is providing domain and policy based tools formanaging large inter-organizational distributed systems. He has recently edited a book onNetwork and Distributed Systems Management and is co-editor of the Distributed SystemsEngineering journal which is jointly published by Institution of Electrical Engineers, BritishComputer Society Institue of Physics.

20