A Role-Based Framework for Distributed Systems ... - Semantic Scholar

Imperial College of Science, Technology and Medicine University of London Department of Computing

A Role-Based Framework for Distributed Systems Management

Emil Constantin Lupu

July 1998

A thesis submitted in partial fulfilment of the requirements for the degree of Doctor of Philosophy in the Faculty of Engineering of the University of London and for the Diploma of Imperial College of Science, Technology and Medicine

 1998 Emil Lupu

Abstract Distributed systems management faces new challenges due to an exponential increase in the size of networked environments. New paradigms that devolve management control and responsibility to multiple actors in the system (users or automated agents) have therefore emerged. Management Policies are a normative specification of the obligations and authorisations of management actors towards their target managed objects. They can be dynamically changed over time according to the evolution of the managed system or according to changes in management strategy. However, policies are insufficient for the structuring of devolved control in terms of the roles of managers in the enterprise context. This thesis attempts to address this issue by using the concepts developed in role theory where managers are assigned and removed from organisational roles, which define their rights and duties. We build upon a distributed management framework and policy notation and define roles as sets of policies, which specify the obligations and authorisations of managers appointed to them. The specification of a role is then further extended to permit the specification of constraints on the concurrency and synchronisation between the activities specified in policies. Managers appointed to roles do not work in isolation but interact and collaborate with each other in order to perform their tasks. We define the concept of a relationship between roles to group the policies pertaining to the related roles or to shared resources. Relationships also specify the interaction protocols between roles. A distributed system may contain a large number of roles that specify similar rights and duties with regards to different managed objects. An Object-Oriented extension to role and relationship specification facilitates creating instances from common class descriptions parameterised with different manager and managed-object domains. As well as supporting reuse of role specifications by multiple instantiation, the framework also supports reuse of specification by inheritance to permit incremental extension of the organisational structure. Multiple policies may apply to the same managers and/or managed-objects in order to reflect different management requirements or because objects may be member of different management domains. Policy inconsistencies can arise due to omissions, errors or conflicting requirements of the managers specifying the policies. This thesis describes the techniques and implemented toolsupport for performing static conflict detection and analysis. Some conflicting policies may be specified as exceptions to more general policies, so techniques for supporting precedence between policies have been included in the conflict analysis process

ii

Acknowledgements This work would not have been possible without the constant dedication, guidance, and advice of my supervisor, Morris Sloman, to whom I am deeply grateful. He has provided me with a constant source of inspiration, encouragement and critical analysis. I would like to thank those researchers and colleagues who have contributed to this work, in its present form or in past publications, with their helpful comments and advice; they include: Stephen Crane, Anthony Finkelstein, Takeo Hamada, Ulf Leonhardt, Damian Marriott, Jonathan Moffett, Rene Wies, Nicholas Yialelis and Nadav Zin. I am grateful to the academic staff of our group − Jeff Kramer, Jeff Magee, Susan Eisenbach, Naranker Dulay and Bashar Nuseibeh − who have set out the example and provided an atmosphere of great intellectual stimulation. Many thanks are also due to my fellow students, research assistants and friends − Paul Dias, Hal Fossa, Dimitra Giannakopolou, Massoud Mansouri-Samani, Karen Meidl, Keng Ng, Nat Pryce, Kevin Twidle, Andrea Zisman and the other members of the Distributed Software Engineering Group − who have provided me with a pleasant and comfortable working environment. I owe a great debt to my parents Mihaela and Nicolae Lupu for giving me the opportunity to undertake this work in the first place and constantly supporting me over the years. Last but not least, Paola Lettieri deserves all my gratitude for being a constant source of encouragement, sharing most moments of my non-academic life, and nourishing my hopes and ambitions with her enthusiasm and her joie de vivre.

The work presented in this thesis was partly funded by: •

The UK Engineering and Physical Sciences Research Council (EPSRC) as part of the Rolebased Management for Multiservice Networks − RoleMan − project (no. GR/K 37512).

•

The UK Engineering and Physical Sciences Research Council (EPSRC) as part of the BBC Education’s Continuously Accessible Learning Materials − BECalm − project (no. GR/K 73282).

•

British Telecom as part of the Management of Multimedia Networks project

•

Fujitsu Laboratories Ltd., Kawasaki, Japan as part of the Pro-active Role-based Management for Telecommunication Services project.

iii

Table of Contents

Abstract .............................................................................................................................. ii Acknowledgements........................................................................................................... iii Table of Contents ............................................................................................................. iv List of Figures ................................................................................................................... ix Chapter 1 Introduction..................................................................................................... 1 1.1 Motivation ........................................................................................................................... 1 1.1.1

The problem: Data moving paradigms are not enough! ............................................. 2

1.1.2

New management paradigms (the solutions).............................................................. 3

1.1.3

The problems of the solutions .................................................................................... 4

1.1.4

An approach to structuring devolved control ............................................................. 4

1.2 Requirements for Role-Based Management........................................................................ 5 1.3 Contribution ........................................................................................................................ 5 1.4 Structure .............................................................................................................................. 8

Chapter 2 Management Environment............................................................................. 9 2.1 Introduction ......................................................................................................................... 9 2.2 Domains ............................................................................................................................ 10 2.2.1

Specifying scopes ..................................................................................................... 12

2.2.2

Implementation......................................................................................................... 12

2.3 Management Policies ........................................................................................................ 13 2.3.1

Policy Specification.................................................................................................. 14

2.3.2

Policy Service........................................................................................................... 17

2.3.3

Policy Enforcement .................................................................................................. 19

2.3.4

Policy Conflicts ........................................................................................................ 21

2.4 Monitoring System............................................................................................................ 22

iv

2.5 Access Control System...................................................................................................... 24 2.6 Relevance and Use in the Role Framework ...................................................................... 25 2.7 Chapter Summary.............................................................................................................. 26

Chapter 3 Roles and Relationships: Background Work ............................................ 28 3.1 Introduction ....................................................................................................................... 28 3.2 Role Theory....................................................................................................................... 29 3.3 OIS and CSCW approaches .............................................................................................. 32 3.3.1

Organisational Relationships and Collaboration ...................................................... 32

3.3.2

MCC’s view on Roles and Distributed Systems ...................................................... 35

3.4 Roles and workflows......................................................................................................... 40 3.5 Do Roles Play Roles?........................................................................................................ 41 3.5.1

OMT, OOram and Other Object Modelling Environments...................................... 41

3.5.2

Roles in Object Oriented Databases and other object systems................................. 42

3.5.3

“The world by contracts” (ODP-RM) ...................................................................... 44

3.6 Role-Based Access Control............................................................................................... 46 3.7 Roles for Multi-Agent Systems......................................................................................... 50 3.8 Chapter Summary.............................................................................................................. 53

Chapter 4 Defining Roles................................................................................................ 55 4.1 Roles as sets of policies..................................................................................................... 55 4.1.1

Role Definition ......................................................................................................... 56

4.1.2

Assignment model .................................................................................................... 58

4.1.3

Role life-cycle .......................................................................................................... 59

4.1.4

Summary................................................................................................................... 60

4.2 Concurrency Constraints ................................................................................................... 60 4.2.1

A Simple Example and more general considerations ............................................... 61

4.2.2

Concurrency Constraint Notation............................................................................. 62

4.2.3

Event based semantics.............................................................................................. 64

4.3 Extended Roles.................................................................................................................. 65 4.4 Role Service and Role Specification Tools....................................................................... 66 4.5 An architecture for the User Role Agent........................................................................... 68 4.6 Chapter Summary.............................................................................................................. 71

Chapter 5 Defining Relationships.................................................................................. 73 5.1 Issues for Role Relationships ............................................................................................ 74 5.2 Related Work .................................................................................................................... 76

v

5.2.1

Multi-agent and Speech Act Based Approaches ...................................................... 76

5.2.2

Process Model Approaches ...................................................................................... 78

5.2.3

Regulated Coordination............................................................................................ 78

5.3 Role Interaction Protocol Specification ............................................................................ 79 5.3.1

Configuring message exchanges .............................................................................. 80

5.3.2

Messages and protocol rules..................................................................................... 83

5.4 Defining and implementing relationships ......................................................................... 87 5.4.1

The relationship model ............................................................................................. 87

5.4.2

Determinism and non-determinism in Interaction Protocols.................................... 89

5.4.3

Implementation of the IPAgent ................................................................................ 90

5.5 Chapter Summary and Future Work ................................................................................. 92

Chapter 6 Object-Oriented Extensions ......................................................................... 95 6.1 Policy Templates............................................................................................................... 95 6.2 Role Classes ...................................................................................................................... 98 6.3 Inheritance....................................................................................................................... 100 6.4 Relationship Classes........................................................................................................ 103 6.5 Tool support .................................................................................................................... 105 6.6 Chapter Summary............................................................................................................ 107

Chapter 7 Conflict Analysis ......................................................................................... 108 7.1 Introduction ..................................................................................................................... 108 7.2 Conflicts .......................................................................................................................... 109 7.2.1

Some Examples ...................................................................................................... 109

7.2.2

Conflict classification............................................................................................. 110

7.3 Conflict Detection ........................................................................................................... 111 7.3.1

Policy Precedence Relationships............................................................................ 112

7.3.2

The importance of overlaps in modality conflicts .................................................. 114

7.3.3

Limitations of domain nesting based precedence................................................... 116

7.3.4

A conflict detection tool ......................................................................................... 117

7.4 Meta-Policies................................................................................................................... 121 7.5 Related Work on Conflict Detection............................................................................... 123 7.6 Chapter Summary and Future Work ............................................................................... 125

Chapter 8 Case-Study: Cellular Network Management ........................................... 127 8.1 Introduction ..................................................................................................................... 127 8.2 System Overview ............................................................................................................ 129

vi

8.3 Role and Relationship Classes ........................................................................................ 130 8.4 Domains .......................................................................................................................... 133 8.5 Role Classes .................................................................................................................... 134 8.6 Policy templates .............................................................................................................. 139 8.7 Relationship classes ........................................................................................................ 140 8.8 Creating instances ........................................................................................................... 143 8.8.1

Policies ................................................................................................................... 144

8.8.2

Role Instances......................................................................................................... 145

8.8.3

Relationship Instances ............................................................................................ 148

8.9 Chapter Summary............................................................................................................ 150 8.10

Glossary of abbreviations ........................................................................................... 151

Chapter 9 Discussion..................................................................................................... 153 9.1 Relationship to relevant related work.............................................................................. 153 9.1.1

The Enterprise Viewpoint of the ODP Reference Model....................................... 154

9.1.2

Relationship to Role-Based Access Control (RBAC) ............................................ 157

9.2 A critical evaluation of the framework............................................................................ 160 9.2.1

Policy templates and Type issues ........................................................................... 160

9.2.2

Relationships and Interactions................................................................................ 161

9.2.3

Constraint model .................................................................................................... 161

9.2.4

Conflict analysis ..................................................................................................... 162

9.2.5

Partitioning ............................................................................................................. 163

9.3 A critical evaluation of the implementation.................................................................... 163 9.3.1

Distribution............................................................................................................. 163

9.3.2

Scalability and performance ................................................................................... 164

9.4 Lessons learned ............................................................................................................... 165 9.5 Chapter Summary............................................................................................................ 167

Chapter 10 Conclusions ................................................................................................ 168 10.1

Relevance to Distributed Systems Management......................................................... 168

10.2

Decentralised control .................................................................................................. 169

10.3

Achievements.............................................................................................................. 170

10.4

Future work................................................................................................................. 173

10.5

Closing remarks .......................................................................................................... 174

Bibliography .................................................................................................................. 176

vii

Appendix A Syntax Specification ................................................................................ 188 A.1 Policy Notation – EBNF ................................................................................................. 188 A.2 Interaction Protocols ....................................................................................................... 190

Appendix B Implementation Interfaces ...................................................................... 191 B.1 Domain Interfaces ........................................................................................................... 191 B.2 Policy Interface ............................................................................................................... 192 B.3 Role and Role Class Interfaces........................................................................................ 193 B.4 Relationship and Relationship Class Interfaces .............................................................. 194 B.5 Message Interface and Role Server Interface.................................................................. 196

viii

List of Figures

Figure 2.1

Management activity loop ........................................................................................ 10

Figure 2.2

Managed Objects ...................................................................................................... 10

Figure 2.3

Graphical representations of domain structures ....................................................... 11

Figure 2.4

The domain browser. ................................................................................................ 13

Figure 2.5

Management Policies: Obligation and Authorisation............................................... 14

Figure 2.6

Graphical representation of a policy......................................................................... 16

Figure 2.7

Snapshot of the policy editor .................................................................................... 17

Figure 2.8

View of a Policy Hierarchy ...................................................................................... 18

Figure 2.9

Policy life-cycle model............................................................................................. 18

Figure 2.10 Policy Obstacle Course............................................................................................. 19 Figure 2.11 Registering for Events .............................................................................................. 20 Figure 2.12 Obligation policy interpreter .................................................................................... 20 Figure 2.13 Potential Conflict of Interests................................................................................... 22 Figure 2.14 Components of the GEM monitoring service........................................................... 23 Figure 2.15 Propagation of Access Control Policies ................................................................... 24 Figure 2.16 Access Control Overview......................................................................................... 25 Figure 3.1

Relationship zones.................................................................................................... 30

Figure 3.2

H-P and P-T graph with quantification..................................................................... 31

Figure 3.3

Alternative organisational forms............................................................................... 33

Figure 3.4

Roles according to Singh and Rein .......................................................................... 37

Figure 3.5

Elements of Rein’s Notation ..................................................................................... 39

Figure 3.6

ARP model for actors in the Actor Dependency (AD) model.................................. 41

Figure 3.7

Roles in an OMT association ................................................................................... 41

Figure 3.8

(a) objects with roles (b) class relationships............................................................. 43

Figure 3.9

Contracts and roles ................................................................................................... 44

Figure 3.10 Examples of role hierarchies .................................................................................... 48 Figure 3.11 Private roles and private role hierarchies ................................................................. 48 Figure 3.12 RBAC Models and main features............................................................................. 50 Figure 3.13 Role aggregation and role assignment...................................................................... 51 Figure 4.1

Role with simple assignment.................................................................................... 56

ix

Figure 4.2

URD, MPD and associated Role .............................................................................. 57

Figure 4.3

Assignment with separation of context .................................................................... 58

Figure 4.4

Role life-cycle .......................................................................................................... 59

Figure 4.5

The extended role model .......................................................................................... 66

Figure 4.6

Outline of the Role Implementation ......................................................................... 66

Figure 4.7

Role Service and Role Specification ........................................................................ 67

Figure 4.8

Components of a role in the role editor .................................................................... 68

Figure 4.9

User Role Agent Interfaces ...................................................................................... 69

Figure 4.10 User Role Agent (proposed architecture) ................................................................. 70 Figure 5.1

The haggling protocol............................................................................................... 81

Figure 5.2

Roles and relationships (brief example) ................................................................... 88

Figure 5.3

IPAgent Implementation .......................................................................................... 91

Figure 6.1

Outline of a role class implementation ..................................................................... 99

Figure 6.2

Role class inheritance graph................................................................................... 101

Figure 6.3

Role and relationship inheritance ........................................................................... 105

Figure 6.4

Relationship Class Specification ............................................................................ 106

Figure 6.5

Role objects............................................................................................................. 106

Figure 6.6

Inheritance and Instantiation.................................................................................. 106

Figure 7.1

Overlapping Subjects, Targets and Actions ........................................................... 115

Figure 7.2

Adding a policy ...................................................................................................... 115

Figure 7.3

Precedence between policies .................................................................................. 116

Figure 7.4

Domain structure .................................................................................................... 118

Figure 7.5

Precedence between policies and list of conflicts .................................................. 119

Figure 7.6

Detected conflicts ................................................................................................... 120

Figure 8.1

Organisational Structure and Roles ........................................................................ 129

Figure 8.2

System Overview Diagram..................................................................................... 130

Figure 8.3

Role and Relationship classes ................................................................................ 132

Figure 8.4

Role and relationship classes in the type-repository............................................... 132

Figure 8.5

Regional domain structure...................................................................................... 133

Figure 8.6

Role instances and relationships between them...................................................... 144

Figure 8.7

Branch with position domains ................................................................................ 145

Figure 9.1

Enterprise Viewpoint Communities ....................................................................... 155

Figure 9.2

RBAC and RBM: different approaches.................................................................. 157

Figure 9.3

Multiple uses of inheritance ................................................................................... 158

Figure 9.4

Instance and Class inheritance................................................................................ 159

x

Chapter 1 Introduction

Some years ago organisations trusted the administration of their computers and networks to one highly skilled and highly specialised system administrator nicknamed the GURU. However, from being the doctor, the saviour and object of all prayers, the GURU has become the main bottleneck of modern organisations. The size and complexity of distributed systems has seen exponential growth. This is due to the fact that both processing power and telecommunications have become considerably cheaper. Network and Distributed Systems Management is no longer a private affair of GURUs but a discipline of Computer Science with complex problems, techniques and tools, and the subject of many research and industrial efforts. This thesis attempts to address a modest problem: the structuring of devolved control. This chapter explains the evolution of ideas that led to this problem, the approach adopted and gives an overview of the contents of this thesis.

1.1 Motivation Distributed systems are composed of networked processing units and other devices co-operating in order to provide the information systems support needed by human organisations. An office workstation is in general connected to several file servers, database servers, printers, backup devices, e-mail, World Wide Web facilities and even broadcast services. Wireless networks allow hand-held processing units to connect to location, direction-finding or weather forecasting services. Corporate networks span geographical or territorial boundaries. Management of such distributed environments is concerned with, not only ensuring their availability, but also tuning the services provided in order to achieve the organisational goals. This includes managing the security of the environment when only partial trust relationships can be established, dynamically re-configuring distributed applications in order to suit business needs, and ensuring that customers of such services are billed for their use.

1

Chapter 1

Introduction

1.1.1 The problem: Data moving paradigms are not enough! The Open Systems Interconnection (OSI) Reference Model has identified five functional areas for the management of a system (ISO/IEC 7498-4, 1989). These functional areas, also commonly known by their acronym FCAPS, are: Fault Management, which includes generation, correlation and distribution of alarms, diagnosis of failures and corrective actions Configuration Management, which is concerned with configurations of network and computational resources, software resources and components of distributed applications Accounting Management, which deals with issues such as billing, delivery and logging of accounting events and modelling of accountable resources Performance Management, which covers monitoring, control and administration of performance in a broad sense Security Management, which addresses issues such as authentication, access control, and partial trust relationships. Two management models have emerged to address these issues: the OSI approach and the Internet management approach. Both rely on a paradigm that allows managers to remotely control operations on managed objects. The OSI approach relies on a scenario where a manager receives notifications and performs operations via an agent that can directly access managed objects and receive notifications from them (Langsford, 1994). The communication uses the Common Management Information Protocol (CMIP) and managed objects can be represented in a complex object-oriented specification (GDMO). Internet management relies on the Simple Network Management Protocol (SNMP) and follows a broadly similar approach. A management application located on the management station interacts with an agent located on the managed host using the SNMP protocol (Stallings, 1994). The information relating to resources is stored in a Management Information Base (MIB) and accessed only by the local SNMP agent. The management application can then emit get or set requests to the local agent, which reads or modifies the variables in the MIB. Furthermore, the local agent can send events to the manager application via trap messages. The simplicity of SNMP has rendered the protocol very popular in the Internet community. However, both SNMP and OSI management are essentially data moving paradigms between a centralised manager station and agents on the managed resources (Goldszmidt, 1995). They both rely on a GURU to sit behind the central manager station, make decisions and initiate management actions in response to events. Therefore, commercially available tools, which rely on protocols such as SNMP and CMIP, have focused on improving the quality of the user interface and the functionality of the management application running on the central manager station. Examples of such tools are HP Openview and more recently the Unicenter TNG framework from Computer Associates.

2

Chapter 1

Introduction

1.1.2 New management paradigms (the solutions) In order to move away from centralised management paradigms three different approaches are currently being explored by researchers in the management community: management by delegation, intelligent agents and management policies. However, the boundaries between them are not always well-defined and solutions range in a spectrum according to the control capabilities invested in the management agents. Management by delegation (Yemini, 1991) proposes to increase the computational power of the agents on the managed host. This is achieved by implementing elastic processes to which parts of the control exerted by the management applications can be delegated. An elastic process is a process to which a program can be sent. It then compiles and dynamically links the program which is executed in a separate thread and remotely controlled by the delegator. Furthermore, the capabilities of elastic agents can be varied over time by delegating new programs or unloading old programs from the agents. This can be used for example to increase the capabilities of an SNMP agent to implement filtering on the MIB values. A run-time system for elastic processes was implemented at Columbia University, New York (Goldszmidt, 1995). Other researchers have used scripting languages or rule-based languages for the same purpose. Intelligent Agents are at the other end of the spectrum from the elastic servers. In addition to computation they also distribute part of the decision making process. The term ‘intelligent agent’ is often used inappropriately and solutions in this category range from the use of expert systems (Goodman, 1995) to rule-based elastic processes. Generally intelligent agents distinguish themselves from elastic servers by the use of an inference engine e.g. (Pell, 1995). Management Policies are distinguished from the previous approaches by separating the control of management actions from their implementation. In other words, policies specify which management actions have to be performed and when − but not what the actions consist of. Policy specifications can range from declarative rules to script-like languages e.g. (Wies, 1995b). Policies are specified in accordance with business objectives and then refined until they can be implemented by manager agents distributed across the network. Note that agents interpreting policies can be elastic processes expanding their capabilities by loading programs from various sources. Chapter 2 of this thesis presents the management framework defined over the years at Imperial College and will discuss in detail the specification and enforcement of the management policies that will be used in this thesis. The common factor between all of these solutions is the attempt to distribute processing as well as distributing management data. Agents, whether intelligent or simply elastic are distributed across the system and perform their functions concurrently and with some degree of autonomy.

3

Chapter 1

Introduction

1.1.3 The problems of the solutions The devolution of management responsibilities to distributed agents can also be found in organisations with a large computing infrastructure such as telecommunication companies. The size, heterogeneity and complexity of the system require a partitioning of responsibility between the various human managers employed. This can be done according to geographical sub-divisions of the organisation, functional departments of the organisation (e.g. marketing, development and research), functional areas of management (e.g. FCAPS), or type of components to be managed (e.g. network elements, databases). Attempts to distribute management tasks between automated agents, whether elastic processes or intelligent agents, lack a framework that specifies how this distribution must be organised and how it must be controlled. Distributed management with human agents partially addresses these issues by specifying job descriptions, organisational goals and procedures to be followed in reaction to external events. Most of the future management infrastructures will combine human and automated agents and need to make explicit the responsibilities attributed to automated agents (Tyndale-Biscoe, 1997), as well as to structure the devolved control. The overall issues that will need to be addressed in such frameworks are: •

How to specify, and attribute management responsibility, to manager agents whether human or automated.

•

How to control managers’ access to the managed objects.

•

How to address changes in management strategy and organisational structure without interrupting the provision of management services.

•

How to ensure consistency of management tasks in terms of non-conflicting specifications or compliance with organisational and legal requirements e.g. separation of duties.

•

How to represent links between the management activities which need to be performed and the organisational goals and procedures from which they are derived.

1.1.4 An approach to structuring devolved control This thesis relies on work previously done at Imperial College on management policies (Sloman, 1994b). Policies are a declarative specification of the management actions to be performed in response to events and notifications emitted by the managed system. Within this framework, we attempt to provide a means of structuring management responsibility in a similar manner to human organisations. We will therefore rely on organisational principles and in particular on role theory.

4

Chapter 1

Introduction

The essence of role theory is that managers are appointed to roles within an organisation, which define their rights and duties. For example, directors, help-desk staff, developers and test engineers are all associated with job descriptions specifying their responsibilities in the organisation. Organisational goals, policies and procedures further determine their rights and duties within the departments, projects, etc., of which they are members. Individuals can then be dynamically assigned and removed from roles according to changes in organisational structure. Furthermore, new tasks can be included or removed from the role specifications thus varying the distribution of responsibilities. Throughout this thesis, we will assume that agents or managers may be human or automated, providing freedom of choice for human managers and determinism for automated components.

1.2 Requirements for Role-Based Management Numerous issues will need to be addressed when attempting to structure management responsibility using roles. In particular, the following issues and concerns have to be investigated: •

The definition of a role model for specifying roles in terms of the rights and duties of the managers assigned to them.

•

The engineering of an assignment model, determining how roles are to be assigned to human managers or automated entities.

•

The specification of relationships between managers, which interact with each other and have responsibilities towards each other.

•

The analysis of the consistency of a role-based specification in terms of policy conflicts and compliance with organisational and legal requirements.

•

The specialisation and incremental specification of roles and relationships for large organisations, which may have a vast repertoire of positions and may span across geographical boundaries.

•

The enforcement of a role-based specification (implementation).

1.3 Contribution This thesis defines a role-based management framework which caters for the specification of roles, relationships between roles, constraints on management policies and constraints on the organisational patterns needed for managing sub-divisions of an organisation. The argument of the thesis is novel, in that no systems or frameworks provide adequate support for structuring responsibility in the context of distributed systems management. Furthermore, very few

5

Chapter 1

Introduction

frameworks make use of the concepts identified in role theory for supporting the specification and distribution of activities in large organisations. Among these, the Enterprise Viewpoint of the Open Distributed Processing Reference Model (ODP-RM, 1997) has been the subject of increasing attention. However, the ODP-RM Enterprise Viewpoint is still in its early stages of development and the role-based model described in this thesis could form an adequate basis for supporting Enterprise Viewpoint specifications. Although related work on role-based frameworks is scarce, the concept of role has been used in an ad-hoc manner in multiple studies. This thesis provides a comprehensive survey of the related literature, detailing the various uses and understandings of the concept of role, and of relevant studies outlining required features of a role-based model. The survey covers several areas of computer science including Computer Supported Collaborative Work (CSCW), Office Information Systems (OIS), Role-Based Access Control (RBAC) and Object-Oriented Modelling frameworks. Among the conclusions drawn from the analysis of theses related studies are: •

the need to support structured interactions between roles in order to ensure collaboration between the managers assigned to them, and,

•

a dichotomy of role models distinguishing between studies which consider a role as in its common language understanding (e.g., “the role of an actor in a play”) and studies which consider organisational roles in the context of an enterprise.

This thesis defines a role and relationship framework in which a role is specified as a collection of policies defining the rights and duties of the manager assigned to it. Relationships group policies defining the responsibilities of the related roles towards each other and specify protocols for the institutionalised interactions between them. These protocols constrain the interactions between managers to pre-defined exchanges of messages, thus removing ambiguities and supporting collaboration between human and/or automated managers. The approach adopted for specifying interaction protocols is novel in that it is based on production-rules which can be dynamically changed, and messages, which convey information regarding the history of the interaction. This approach allows a greater flexibility for protocol specification. Roles or relationships may group policies which specify incompatible duties, or activities that cannot be performed concurrently. The role and relationship framework presented in this thesis caters for the specification of concurrency constraints and rules which define conflicting responsibilities (called Meta-Policies). Organisations may have a large number of roles which specify similar rights and duties but are taken on by different managers and apply to different managed objects. A role object model defines role and relationship classes which can be instantiated in different contexts e.g., departments, or branches of the organisation. In order to define classes, this thesis introduces the

6

Chapter 1

Introduction

concept of policy templates which can be instantiated with different manager and managed objects domains. Furthermore, role and relationship classes may mutually reference each other in order to constrain the instantiation and establish organisational patterns. This facilitates the specification of a class configuration for the management of a department or branch and the instantiation of the pattern in all the departments or branches of the organisation. Whenever multiple policies apply to the same objects, conflicts may arise in the policy set. In this thesis we introduce a distinction between modality conflicts which can be detected by syntactic analysis of policies and application specific conflicts which require specifying the constraints that result in conflict (e.g., separation of duty). We further identify the need for establishing precedence relations between policies to automatically resolve some of the modality conflicts and cater for a potentially unlimited number of exceptions to a policy. In particular, this thesis conducts an in-depth analysis of the precedence relation giving priority to the most specific policy with respect to more general ones. Since there are cases in which this precedence relation does not successfully apply, we present an analysis tool which detects modality conflicts between policies with or without “specificity” precedence. Each one of the individual issues such as interaction protocol specification and conflict detection are supported by a careful analysis and comparison with related work. Although a large number of examples are used throughout the thesis to outline individual features of the role-based framework, a proof-of-concept of its adequacy for structuring management responsibility is given in the form of a case-study for the operation, administration and maintenance of cellular networks. Amongst the related work, the ODP-RM Enterprise Viewpoint and Role-Based Access Control have been the subject of increasing attention in recent years. We present a critical comparison between the framework defined in this thesis and those efforts. This enables us to draw lessons regarding the optimisation of role-based frameworks and to define future directions of study towards the provisioning of enterprise specifications. Although the major contribution of this thesis lies in the definition and specification of the framework, we also present tools which have been implemented for the specification, analysis, persistency and distribution of roles, relationships, classes, etc. Furthermore, we also propose an architecture for the agent which represents managers in a role and implements policies. A component of this agent dedicated to the enforcement of the interaction protocols has been implemented and is also described here.

7

Chapter 1

Introduction

1.4 Structure Chapter 2 in this thesis will provide an overview of the work previously done at Imperial College towards a policy-based framework for systems management. In particular we will outline: the use of a domain structure for grouping manager and managed objects, the notation and enforcement of management policies, the monitoring subsystem and the implementation of access control. Chapter 3 will be devoted to a survey of relevant work relating to role and relationship specification. We will outline the basic concepts of role theory and examine work from various subject areas of computer science. Chapters 4 and 5 will outline our model of roles and relationships while object oriented extensions to this model will be defined in Chapter 6. Chapter 7 is entirely devoted to the analysis of conflicts between management policies that compose roles and relationships. Chapter 8 will present a case-study application of the framework to the operations and management of cellular networks. Chapters 9 and 10 will give a critical analysis of the work and provide the conclusions to this thesis. The appendices contain an EBNF description of the syntax used for specifying policies and interaction protocols and the implementation interfaces for domains, policies, roles, etc.

8

Chapter 2 Management Environment

2.1 Introduction The work described in the following chapters relies heavily on concepts, tools and techniques developed at Imperial College during past years. Therefore, the management roles that will be described in this thesis must fit into a more general ‘legacy’ framework for distributed systems management, adhere to its concepts and use the tools and techniques developed so far. This chapter aims to describe the concepts on which this thesis relies. It is by no means extensive or complete in its description, restricting its scope to those concepts that are necessary for the understanding of what follows. Many people have contributed to the work described here and an extensive literature (including six Ph.D. theses) is available. The work described in the next sections forms a management system in its own right covering monitoring, policy specification, access control and execution of management activities. The central components of this framework are the domain service (Section 2.2), policy service (Section 2.3), monitoring sub-system (Section 2.4) and access control framework (Section 2.5). Management is concerned with monitoring and controlling the activity of a system in order to maintain and improve its functioning. In order to perform this activity, the state of the various system components must be monitored and events containing up-to-date information must be disseminated to the managers. Managers interpret the received events and make decisions regarding what behaviour is desired from the system based on the requirements, goals and policies of the organisation (Figure 2.1). They perform control operations on the system in order to obtain the desired behaviour or delegate those operations to automated managers (Sloman, 1994c &1995).

9

Chapter 2

Management Environment

Interpret & make decisions

Monitor

Perform control operations

Figure 2.1

Management activity loop

Managed resources can be devices, files, network resources etc. Several representations of managed objects have been employed, e.g., MIB tables for SNMP based management (Stallings, 1994) and GDMO objects for OSI management (Jeffree, 1994). More recently CORBA (OMG, 1996) and its various implementations provide the means for distribution transparency of objects within the system and a uniform Interface Definition Language (IDL). Several efforts have been made to translate the definitions of managed objects from/to IDL specifications. Therefore, we will assume the existence of an underlying environment, in which management activities can be initiated by remote object invocations. A managed object is an object that has a management interface in addition to its ‘functional’ interfaces (Figure 2.2); human and automated managers invoke operations defined in the object’s management interface.

Management Interface

Managed Object

Figure 2.2

Functional Interfaces

Managed Objects

For implementation purposes, in the remainder of the thesis, managed objects are assumed to be CORBA objects i.e. objects having a management interface defined in CORBA IDL. This assumption is not too restrictive since: (1) CORBA objects can be implemented as a front-end for non-CORBA objects and (2) although based on remote object invocation the role model does not rely on CORBA specifics.

2.2 Domains Distributed systems are characterised by one aspect above all: their potential size. A modern distributed system contains a potentially unlimited number of objects across multiple hosts, sites or countries. Domains (Twidle, 1993) provide a flexible means of partitioning the objects in a large system according to geographical boundaries, object type, management functionality, responsibility and authority or for the convenience of human managers (Sloman, 1994a&b).

10

Chapter 2


A domain is an object, which maintains a list of references to objects that have been grouped together for the purposes of management. If a domain holds a reference to an object, the object is said to be a direct member of that domain. Furthermore, if the object is itself a domain it is said to be a sub-domain of its parent domain. An object is a member of a domain A if it is a direct member of A or if it is a member of at least one of A’s sub-domains − it is then an indirect member of A. An object may be a direct member of multiple domains. In this case, its parent domains are said to overlap. From a user’s point of view, domains are very similar to directories in file systems. A domain holds local names for each of its direct members. These names must be unique within a domain but two different domains may use the same name to refer to different objects. An object that is a direct member of multiple domains may have a different local name in each of those domains. A top-level (or root) domain is used as an absolute reference point for the domain hierarchy. A path name for an object is defined to be an ordered concatenation of names of ancestor domains up to the root, plus the local name of the object itself (Becker, 1993). Figure 2.3 gives two graphical representations of domain structures. The DoC Network objects can be represented in a hierarchy (actually a directed acyclic graph) where devices are grouped either according to the sub-net to which they belong or according to their type. The DNS servers in the DNS-14Net are grouped in a domain that is included in both the SubNet-14 domain and the DNS-Servers domain. Objects in the SubNet-14 are DNS servers and the dse-mail object. DoC Network DoC Network

SubNet-14 dse-mail

SubNet-14

DNS-Servers

DNS-14Net

dse-mail

DNS-14Net

DNS-Servers

Figure 2.3

Graphical representations of domain structures

A User Representation Domain (URD) is a user’s persistent representation within the system. When a user logs in, an adapter object (cf. login shell) is created within the URD to act as the interface process between the person and the computer system. Other agents representing the human could also be created in the URD.

11

Chapter 2


2.2.1 Specifying scopes Domains are a useful tool for grouping objects. However, given a domain structure it is necessary to be able to select a set of objects without creating a new domain that groups references to all the objects in the set. A Domain Scope Expression (DSE) defines a set of objects in terms of domain membership and set operations. The following syntax has been defined for DSEs (Marriott, 1997): DSE :== ANY *[n] domain @ [n] domain { object } DSE + DSE DSE – DSE DSE ^ DSE ( DSE )

| | | | | | |

•

ANY − refers to any object, i.e., it defines a set containing all objects

•

{ object } − returns a set containing all the objects on which it is applied

•

* [n] domain − returns all direct and indirect members of the domain up to the nth level. This includes domain objects. If not specified n defaults to infinity.

•

@ [n] domain − returns the set of all direct and indirect members of that domain excluding all domain objects. If n is specified the domain structure is traversed n levels down.

•

+, -, ^ − refer respectively to set union, difference and intersection.

For example, @/DoC Network/DNS-Servers – @/DoC Network/DNS-Servers/DNS-14Net evaluates to all members of the DNS-Servers domain except those in the 14 Net (Figure 2.3).

2.2.2 Implementation Domain objects are maintained persistently in domain servers but only one of the servers will maintain the root domain. A domain service is therefore provided by a collection of domain servers distributed around the system. The Domain Browser is a tool for navigation of the domain structure (Fossa, 1997). In Figure 2.4 the current domain /Example/Org1/Policies contains two policy objects, has one subdomain (SharedPolicies) and is a member of two parent domains (AllPolicies and Org1). The domain browser is used as the primary tool for selecting objects in order to edit or to analyse them.

12

Chapter 2


Parent Domains

Current Domain

Figure 2.4

Sub-domains

The domain browser.

2.3 Management Policies Distributed systems may contain a large numbers of objects and cross organisational boundaries. New components and services are added to, or removed from, the system dynamically thus changing the requirements of the management system over time. Separating policies from the managers which interpret them permits modifying policies to change the behaviour and strategy of the management system without recoding the managers. The management system can thus adapt to changing requirements by disabling policies or replacing old policies with new ones without shutting the system down. We are concerned with two types of policies: authorisation policies which specify what activities a subject is permitted or forbidden to perform on a set of target objects and obligation policies which specify what activities a subject must or must not do to a set of target objects (Sloman, 1994b). Policies within a system are specified for domains of objects. By default a policy propagates and applies to all direct and indirect members of a domain although this propagation can optionally be disabled. This helps to cater for large-scale systems in that it is not necessary to define separate policies for individual objects in the system, but rather for groups of objects. Policies establish a relationship between the subjects that perform the operations and the target objects on which the operations are performed (Figure 2.5). The subjects interpret obligation policies and authorisation policies are enforced by access control components on the target host. (Note that ‘subjects’ can refer to human managers, automated managers or any entity initiating operations within the system.) Managers that are subjects for a set of policies may in turn, be managed by other managers according to another set of policies and thus become target managed objects.

13

Chapter 2

Management Environment Obligation Policies

Interpret Interpret

Authorisation Policies Information Control

Manager Manager (Subject) (Subject)

Figure 2.5

Managed Object (Target)

Management Policies: Obligation and Authorisation

2.3.1 Policy Specification Policies are initially specified at organisational level in terms of organisational requirements and objectives (cf. goals). These policies are generally abstract, specified in English and suitable for interpretation only by human managers. However, these policies may be progressively refined into sets of more concrete policies. Leaf-level policies in this hierarchy specify actions, which are defined as operations on the target objects or procedures programmed inside the manager agents. For example, an abstract policy may specify that the temperature of a boiler must be between 50 and 100. This goal specification must be refined in two obligation policies that switch the boiler heater on or off when temperature goes below 50 or above 100 respectively. Furthermore, an authorisation policy is needed in order to permit the manager to switch the boiler heater on or off. Authorisation policies specify which actions subjects are permitted or prohibited to invoke on target managed objects e.g.: •

Students are allowed to access the courses database (Positive)

•

Students are not allowed to access system files (Negative authorisation − prohibition)

•

The operator is allowed to close the reactor’s valve when 50 < reactor.temperature < 100.

•

Nurses are not allowed to administer medication to patients when they are not on duty (i.e. nurse.state != on_duty)

Obligation policies specify which activities a subject must (or must not) perform. Subjects will be trusted to comply with the policies. A distinction can be made between activity-based obligations and state-based obligations. For example: •

The director must protect the assets of the company (positive obligation – activity based)

•

Academic staff must not disclose examination results to students (negative obligation – activity based)

•

On boiler.temp < 52 controller must switch on boiler heater when heater.gas_flow > 10 (positive obligation – triggered – state based)

14

Chapter 2


Constraints can be used in a policy specification to restrict the applicability of the policy (e.g., to particular managers or to a particular time interval). Sloman distinguishes between temporal constraints (e.g., the policy applies between 09.00 and 17.00), parameter value constraints (e.g., passwords must be longer than 6 characters) and preconditions (e.g., policy applicable to hosts with a load < 60%) (Sloman, 1994b). Negative obligation policies are not equivalent to negative authorisations. The main difference lies in the fact that obligation policies are interpreted by subjects while authorisation policies are interpreted by access control components on the target host. Thus, negative obligation policies act as subject based filters specifying actions that managers ‘must refrain’ from performing. For example, in the policy given above, which specifies that academic staff must not disclose examination results, the target objects (i.e., the students) cannot be trusted to implement the negative authorisation policy. In the management framework used in this thesis, all operations that are not explicitly authorised are forbidden. This is equivalent to there being a default negative authorisation policy. Although some database management systems implement negative authorisation policies they remain difficult to implement in an open system. Furthermore, the implementation of a negative authorisation would require verifying non-membership in groups (Yialelis, 1996b). For this reason, the current access control framework takes into account only positive authorisation. However, this does not preclude the use of negative authorisations at the specification level. Refinement is then used in order to translate a set containing both positive and negative authorisation policies into a set of positive authorisation policies implemented with a default negative policy. The general format of a policy (Marriott, 1994 & 1996a) is given below with optional attributes within brackets (the braces and semicolon are the main syntactic separators). Some attributes of a policy such as trigger, subject, action, target or constraint may be comments (e.g., /* this is a comment */), in which case the policy is considered high-level and not susceptible to direct

interpretation by automated components.

identifier mode [trigger] subject ‘{’ action ‘}’ target [constraint] [exception] [parent] [child] [xref] ‘;’

The mode of the policy distinguishes between positive obligations − O+, negative obligations − O-, positive authorisations − A+, and negative authorisations − A-. The subject and target of a policy determine the set of subjects (managers) and the set of target objects to which the policy applies. Both are specified using a domain scope expression (see Section 2.2.1). An advantage of specifying policy scope in terms of domains is that objects can be added and removed from domains to which policies apply without having to change the policies. The action clause

15

Chapter 2


specifies what must be performed for obligations and what is permitted for authorisations. It consists of method invocations or a comment and may list different methods for different object types e.g. “cdworm”:eject(), “tape”:rewind(). Multiple actions can also be specified separated by semicolons. In positive obligation policies, actions must be executed sequentially. The constraint limits the applicability of a policy, (e.g., to a particular time period), or making it valid after a particular date. Constraints are specified by a predicate in terms of attribute values for objects, membership of objects in a particular domain, time or system attribute values. Trigger refers to a time-based event (e.g., at 14:00) or an event defined within the monitoring service (see Section 2.4). Triggers may only be specified for positive obligation policies. An exception mechanism is provided for positive obligations to permit the specification of alternative actions to cater for failures, which may arise in any distributed system. Parent and child are references to policies within the refinement hierarchy while Xref denotes a set of references to related policies e.g. to refer to the authorisation policy granting permission for an obligation policy’s activities. This is necessary since obligation and authorisation policies may be specified independently by different administrators or by the same administrator at different times. Figure 2.6 illustrates the graphical representation of a policy that will be adopted throughout this thesis.

Subject

actions

Target

constraint

Figure 2.6

Graphical representation of a policy

We can now give some examples of policies using the notation: A+ @/personnel/nurses { administer(analgesics) } x:@/patients/lung-diseases when (x.temperature > 37) && (x.temperature < 38.5) Nurses are authorised to administer analgesics to patients when their body temperature is between 37 and 38.5. Note the use of the constraint to limit the scope of applicability of the policy. A- @/personnel/nurses { validate } @/patient/discharges Nurses are not allowed to validate patient discharges. O+ on drugs_administered @/personnel/nurses { update } /drugs_db; This positive obligation policy is triggered by an event signalling that drugs have been administered and obliges the nurse to update the drugs database.

16

Chapter 2


O- n:@/personnel/nurses { administer(_) } @/patients when n.state != on_duty This negative obligation policy specifies that nurses which are not on duty should not administer any medication even though they may be authorised to do so. The full syntax of the policy notation is given in Appendix A.

2.3.2 Policy Service Policies are implemented as persistent objects and maintained by servers, which are distributed around the system. The advantage of implementing policies as objects is that access control and management of policy objects can be specified by other policies. The model is in this sense selfmanaged.

Figure 2.7

Snapshot of the policy editor

Operations on a policy server allow creation and deletion of policy objects and retrieval of the list of policies maintained by the server. Administrators create and edit policies using an editor implemented in Tcl/Tk (Ousterhout, 1994) and its various incremental extensions (McLennan, 1993). Figure 2.7 shows a snapshot of the policy editor. The right part of the figure indicates relationships to other policies in the refinement hierarchy, while the left part allows editing the policy attributes (mode, trigger, etc.) and changing the policy status. A separate window is used by an administrator to browse a whole policy hierarchy (Figure 2.8). The policy editor also integrates the policy parser, which checks the syntax of a policy.

17

Chapter 2


Figure 2.8

View of a Policy Hierarchy

When created, a policy is initially in the dormant state and remains in this state as long as it is being edited. When a policy is considered finalised, it can be distributed to all subject managers (for obligation policies) and access control components (for authorisation policies). The policy is then in a disabled state. Once distributed the policy can be enabled (Figure 2.9). Note that the distribution of a policy to the components that must ensure its enforcement is separated from the enabling/disabling of the policy. This facilitates: •

Distributing a policy to managers and access control components before it must be enforced. Managers can therefore implement the loading and possibly parsing of a policy in a separate thread of execution. The policy is then stored in the manager ready to be executed.

•

Enabling/Disabling policies in the managers in one atomic operation. Disabled policies can be re-enabled without requiring redistribution.

•

Implementing a hierarchy of policies. For example disabling an abstract policy results in disabling all its children. Create

Edit

Dormant Distribute

Deleted Retract

Disabled Enable

Disable

Enabled

Figure 2.9

Policy life-cycle model

18

Chapter 2


2.3.3 Policy Enforcement Managers that are subjects of positive obligation policies, initiate actions when notified of the occurrence of the event (trigger) specified in a policy. The invocation performs what can be compared to an obstacle course (Figure 2.10) in that it must not be inhibited by a negative obligation policy, nor prohibited by authorisation policies before reaching the target object (Moffett, 1993; Abrams 1995).

Positive Obligation Policies

Invocation

Manager Agent

Target

Negative Obligation Policies

Figure 2.10

Authorisation Polcies

Policy Obstacle Course

In this section, we will concentrate on the enforcement of obligation policies and in particular positive obligations. Enforcement of authorisation policies is briefly described in Section 2.5. Policies are enabled by managers using the policy editor and through the policy service. For a policy which is triggered by an external event (e.g., on /system/administration/intruder_alert) the manager uses the domain service to obtain the object identifier associated with the monitoring component which detects the event and registers with the monitor for being notified of subsequent event occurrences (Figure 2.11). When a notification is received, the manager evaluates the constraint of the policy. If the constraint evaluates to true the actions specified in the policy are performed.

19

Chapter 2


Domain Service Policy Editor (1) Enable

Policy Service

(2 )

(3) Monitor component ena ble (p o id )

(4) Oid Manager Agent

(5) Register (event, agent_oid) Monitoring Service

Figure 2.11

(6) Notify (event)

Registering for Events

A manager agent can be seen as a composite component with several interfaces (Marriott, 1996b). In particular it implements: (1) a top level interface for loading, enabling, disabling and removing policies, (2) an interface for interaction with the monitoring system which allows the monitoring service to notify the manager of event occurrences and (3) an interface for invoking operations on the target objects (Figure 2.12). Loading Policies

Enabling, disabling, removing policies

Policies Policy-level, internal interface Application specific, predefined management functions

Events

Policy Interpreter

Figure 2.12

Invocations on target objects

Obligation policy interpreter

Actions specified in a policy may correspond to operations belonging to the interface of the target objects. However, there are cases in which it is preferable to build into the agents higher-level procedures that can be specified as management actions within policies. These procedures are then available to the obligation policy interpreter through an internal interface (Figure 2.12). This has two main advantages: (1) managers can be implemented for objects which do not have an extensive management interface and (2) customised task-specific agents can be provided for fault diagnosis, configuration, etc.

20

Chapter 2


2.3.4 Policy Conflicts Whenever several policies apply to the same object there is a potential for some form of conflict between them. Preliminary work on conflict classification is reported in (Moffett, 1994) where different types of conflict are distinguished according to the overlaps between the subject, action and target scopes:

Positive-Negative Conflict of Modalities This conflict occurs when both positive and negative policies of the same kind (i.e., obligation policies or authorisation policies) and are specified with regard to the same subjects, actions and targets. For example: ‘The accounts supervisor is permitted to sign payment cheques’ and ‘The accounts supervisor is forbidden to sign payment cheques’. This type of conflict requires a triple overlap between target objects, subjects and actions.

Conflict between Obligation and Authorisation Policies This conflict occurs when a positive obligation policy and a negative authorisation policy are specified with regard to the same subjects, targets and actions (triple overlap). When this type of conflict occurs, the manager is obliged to perform an action that is forbidden by the negative authorisation policy. A particular case of this conflict occurs when an obligation is specified but there is no authorisation for performing this action. The conflict still occurs because we assume a default negative policy, i.e. everything that is not explicitly allowed is forbidden.

Conflict of Priority for Resources This conflict is a conflict of actions, which may occur whenever concurrent access to limited and non-renewable resources is attempted. For example, as part of a budget expenditure the operation use(300) may be specified in a positive obligation policy. Yet, the budget being limited (e.g., 400) this action may conflict with other expenditure. This conflict is characterised by an overlap in the actions and in the target scope of the policies.

Conflict of duties This conflict occurs when two positive authorisation policies are overlapping in their target objects and subjects, thus allowing a manager to perform operations which are defined by the application as conflicting. For example, a policy authorising the accounts manager to sign payment cheques and another policy authorising him to authorise payments may conflict with an organisational policy which prevents the same person to authorise payments and sign cheques. The latter organisational policy is considered in (Moffett, 1994) as a Policy About Management Action Policies (PAMAP).

21

Chapter 2


Conflict of interests A conflict of interests arises when two authority policies have a common subject and perform tasks on two different sets of targets. For example, a merchant bank acting as adviser to two different client organisations, advising one on a take-over bid and the other on investment decisions, which may be influenced by the knowledge of the take-over bid (Figure 2.13 from (Moffett, 1994)).

Takeover Advice

Client A

Merchant Bank

Client B

Takeover Advice

Figure 2.13

Potential Conflict of Interests

Multiple Managers A conflict can potentially arise when several managers are managing the same target objects. For example, a conflict arises if the operation ‘maintain’ on a computer entails isolating it from the network and a ‘configure’ operation requires its availability on the network. This type of conflict occurs if there is an overlap between the target scopes of the policies.

Self-Management This conflict occurs when a manager is not allowed to perform management operations on itself. For example, managers may not be authorised to approve their own expenses. The work presented in (Moffett, 1994) is essentially preliminary work. In this thesis, we will consider ways of detecting and resolving conflicts in more detail, as well as possible specifications of PAMAPs, to which we refer as Meta-Policies.

2.4 Monitoring System Monitoring, and in particular events which trigger obligation policies, are provided by the Generalised Event Monitoring system (GEM) developed and implemented at Imperial College (Mansouri-Samani, 1997). The overall architecture of GEM is based on three types of components: event generators which read status vectors or poll elements of the system, event

22

Chapter 2


monitors which aggregate primitive events received from the generators according to specified rules and event disseminators which notify managers and other system components of event occurrences (Figure 2.14). GEM permits the specification of complex events in terms of primitive ones. Thus, event correlation can be specified and changed at run-time. Furthermore, the monitoring service can be configured at run-time by creating new event monitors and disseminators, specifying new event classes, or removing existing ones. Database Status Vectors

Event Event Event Generator Generator Generator

Primitive Events

Event Event Event Monitor Monitor Monitor

Combined Events

Event Event Event Monitor Monitor Disseminator

Display

Poll Managers Event specifications

Figure 2.14

Subscribe

Components of the GEM monitoring service

The GEM rule specification language, which caters for the definition of complex events, has the following operators: •

e1 & e2 occurs when both e1 and e2 occur irrespective of their order

•

e + time-period occurs a specified period of time after the occurrence of event e

•

{e1 ; e2} ! e3 occurs when e1 occurs followed by e2 with no interleaving e3

•

e1 | e2 occurs when e1 or e2 occurs

•

e1 ; e2 occurs when e1 occurs before e2

Time dependent constraints can also be expressed in the language. Examples of valid GEM rules are: /* Three occurrences of an invalid login outside of office hours will generate a security violation event */ Rule R1 {x: invalid_login [3] when (@x > [17:00]) or (@x < [08:00]) Ð notify sec_violation($x, x.login) } /* Occurrence of two alarms of type Talarm and Palarm within seconds of each other will generate an event for shutting down the reactor */ Rule R2 { (x:Talarm && y:Palarm) when (abs(@x - @y) < 2*sec) Ð notify shut_reactor } Note that in rule R1 the originator of the event denoted by $x and the login attribute of the incoming event are passed as parameter to the new event reported. This allows propagating, to the policy level, parameters which can be used in the actions of the policy e.g.

23

Chapter 2


/* on the occurrence of a security violation disable the login entry in the remote login daemon */ O+ on sec_violation(origin, e:login) secmanager { disable(e) } rlogind

2.5 Access Control System A security architecture has been developed (Yialelis, 1996a) to enforce authorisation policies and facilitate the development of secure distributed applications on existing operating systems that do not provide distributed security. A high degree of authentication and access control transparency is achieved by employing security agents on a per-host basis. These agents are trusted to act on behalf of the application objects on their hosts. Specifically, an Authentication Agent (AA) executes authentication protocols on behalf of application objects on the host. In addition, an Access Control Agent (ACA) holds copies of authorisation policies applying to objects on its host and determines whether a policy exists to permit a subject to access a target on its host. The Access Control List paradigm is combined with pseudo-capabilities, used as hints to improve the time-efficiency of the access control decision mechanism. When a subject (which may act on behalf of a user) intends to invoke operations on a remote target, a secure channel is established between these two objects. The channel is identified by a unique channel identifier and is associated with cryptographic information (session key and cryptosystem used for secure communication), as well as access control information. The ACA on the subject host sends, to the ACA on the target host, the domain membership certificates and the pseudo-capabilities (list of policies applying to the manager invoking the operation) which are used as hints to search the space of policies applying to the target object (Figure 2.15). Subject

Policy

Target

Operations

Subject Host

Propagate Policies

Subject Access Control Agent

Target Host Target Access Control agent

Pseudo Capabilities (Hints) Determine Pseudo Capabilities List

Figure 2.15

Domain Membership Certificates

Determine Enabled Policies List

Propagation of Access Control Policies

The target Access Control Agent selects the policies permitting the subject of the established channel to access its target. The list of these policies is referred to as Enabled Policy List (EPL)

24

Chapter 2


and is given to the Reference Monitor (RM) located in the address space of the target (Figure 2.16). Host

Subject

Invoke Operation

Grant Reference Monitor

Reject

Target

EPL Access Control Agent

Policy Service

Figure 2.16

Authentication Agent

Dom ain Service

Authentication Service

Access Control Overview

A RM makes access control decisions for target objects in its address space using the EPL that applies to a particular subject-target pair (distinguished by channel identifier). Note that the determination of the EPL has to be done once for the lifetime of a secure channel and is based upon the identity and domain membership of the subject. This is authenticated by the target Authentication Agent using a trusted Authentication Service based on symmetric cryptography. A detailed description of the authentication mechanism is given in (Yialelis, 1995). When a new secure channel has been established, the session key for that channel is given to the cryptographic facilities in the address spaces of the subject and target objects. So, further communication between these two objects does not involve the authentication agents. A prototype of this architecture (detailed in (Yialelis, 1996b)) has been implemented in Orbix (Iona, 1993).

2.6 Relevance and Use in the Role Framework The concepts presented in this chapter have been used extensively for the development of the role model. Some of them constitute the foundation for new concepts while others have guided the architectural choices made. The implementation of the domain and policy service, and of the various browsing and editing tools was used and integrated with new tools for role and relationship specification as well as policy conflict analysis. Roles, relationships and their respective classes have been implemented as objects included in the domain structure. Therefore, domains have been used throughout this thesis as a means of grouping objects, but also as a means of referring to objects (i.e., by using the path of an object in the domain structure). The domain browser was used in the implementation as the primary tool

25

Chapter 2


for selection objects to be edited and/or analysed. It communicates with the tools described in the following chapters through a drag&drop interface. The policy notation will be used throughout the thesis since the role definition relies on policy specification. Furthermore, policies are also necessary to specify the user-to-role assignment while maintaining the separation of context for a manager’s activities in the roles he is assigned to. Role and relationship classes rely on the specification of policy templates which have been introduced as a means of reusing policy specifications. The policy life-cycle impacts on a role’s life-cycle and the policy enforcement will be used in the architecture of the User Role Agent. In particular, it is important to bear in mind the differences between the enforcement of positive obligation policies, negative obligation policies and authorisation policies since they will often impact on the design choices. From an implementation point-of-view the policy service, maintaining persistent policy objects, was reused but had to be considerably updated for the purpose of this thesis. The policy editor was completely re-implemented to improve performance. The distinction between policy conflicts based on domain overlap was found to be nondiscriminating. We introduce a simpler classification and outline new requirements for conflict detection and analysis. GEM’s ability to specify complex events has some bearing on the role model and in particular on the policy templates. Furthermore, we introduce concurrency constraints as a high-level means of specifying required synchronisation and sequencing of policy activities. The semantics and enforcement of the concurrency constraint expressions is based on a translation to complex events defined in terms of the primitive events signalling the beginning and ending of an activity’s execution. Inevitably, since this thesis is the first study extensively using the policy notation, improvements and amendments to the notation have arisen. However, discussing these would also require presenting a wider perspective on policy specification notations and uses which would considerably enlarge the argument of this thesis. Therefore, aspects relating directly to the policy notation will not be discussed.

2.7 Chapter Summary In this chapter, we have given an overview of the management framework for which roles will be defined. This framework relies on the ability to define management policies that are specified externally to the management components. Policies can then be dynamically loaded and replaced within management agents, thus changing the strategy of management at run-time with minimal

26

Chapter 2


disruption of service. Policies apply to sets of objects selected within a domain hierarchy. Domains offer a convenient means of grouping objects for management purposes and membership within a domain may be changed at run-time. So a set of policies can be applied to new objects, or an object can be removed from the scope of a set of policies, at run-time. Positive obligation policies specify actions to be performed by management agents. They can be triggered by events, which may be composite events defined in the monitoring service. Authorisation policies regulate the access of managers to target objects and are interpreted by access control components on the target host. A large amount of related work on management policies can be found in (DSOM, 1994; Magee 1996; Koch 1996; Wies, 1995a&b) and other publications. We have not reported this work here in an effort to simplify presentation and concentrate on the issues directly relevant for this thesis i.e. the role model.

27

Chapter 3 Roles and Relationships: Background Work

3.1 Introduction Although the need for the distribution of control has been expressed time and again in the management community, few concrete attempts have been made to structure and organise the division of responsibility. We therefore need to look for related work in other subject areas concerned with similar problems. The Computer Supported Collaborative Work (CSCW), Office Information Systems (OIS), Security, and Distributed Artificial Intelligence (DAI) communities will provide insight regarding the issues and possible approaches towards structuring decentralised tasks and coordinating activities. Furthermore, they also outline the requirements for supporting relationships between the managers to which activities have been assigned. The concept of role is used throughout these related areas in an ad-hoc manner. Thus, we should be able to determine distinct features that can be modelled using roles and examine their usefulness to the distributed management problem. Complete work on roles is very rare. By ‘complete’ we mean work that elicits: •

A distinction between various types of roles.

•

A role model, i.e. how roles are specified and what relationships can be established between various roles or types of role.

•

An administrative model specifying where the authority for creating and assigning roles resides.

•

An assignment model, which determines how roles are assigned to human or automated agents.

28

Chapter 3 •

Roles and Relationships: Background Work

Task representation, i.e., what is the relationship between the roles, the processes in which they are involved, and the activities which managers assigned to roles perform?

•

Consistency requirements, i.e., are there any inconsistencies in a role specification and can the specification be constrained in any way?

•

An implementation, which determines how to enact a role-based specification.

Some of the work presented in this chapter was done in the past few years, concurrently but independently of the work described in this thesis. This is the case with most studies on RoleBased Access Control and on the Enterprise Viewpoint of the Open Distributed Processing Reference Model (ODP-RM). This chapter does not include related work on singular features such as interactions, conflict detection and resolution, etc. Instead, relevant studies are presented in those chapters in which the design and modelling of these aspects is introduced. Section 3.2 provides some background on the concept of role as defined in role theory. Section 3.3 is devoted to relevant work from the OIS and CSCW communities. In addition to modelling roles, this section will also detail studies of relationships between actors or managers in an organisation. While Section 3.4 briefly presents some ideas relating to the use of roles in workflows, Section 3.5 provides a new perspective on roles. These ideas are drawn from Object Oriented Modelling and the work on the Enterprise Viewpoint of the ODP-RM. Section 3.6 presents the current issues and efforts in Role-Based Access Control (RBAC). A particular study of roles from the Distribute Artificial Intelligence (DAI) community is presented in Section 3.7.

3.2 Role Theory Role theory evolved as a sociological science and particular emphasis was placed on it during the 1960’s and 70’s. Although the origins of the word ‘role’ can be traced back several centuries, its first appearance with a meaning close to today’s was in the theatre where actors play ‘roles’. In the same way as actors ‘play a part’, individuals in a society are expected to fulfil certain roles (e.g., father, director, doctor) which predefine their rights and duties within that society. This normative aspect of expectations, (or ‘prescriptions’ as they are sometimes called), allowed the development of a science that concerned itself with their formalisation, analysis for conflicts or deviance and implications on human psychology. This became known as role theory. We are only interested here in the normative aspects of role theory and will therefore omit much of the work relating to purely sociological and psychological aspects. Biddle (1979a) defines a role as “a set of standards, descriptions, norms or concepts held (by anyone) for the behaviours

29

Chapter 3


of a person or a position”. This definition is further refined and simplified in (Biddle, 1979b) to define a role as “a collection of rights and duties” relating to a position. A position is defined as “a designated location in the structure of a social system”. There is much confusion, even in the role theory community, about the distinctions between the concepts of status, position and role. Although a status is more generally accepted to coincide with the common language understanding of ‘social status’, a position represents a static entity or location in an organisational structure, while a role defines the dynamic or behavioural part associated with the position. The concepts of role and position are considered inseparable even by sociologists. Therefore we will not distinguish them. Roles are not defined in isolation but in a “social net of role relationships” (Elliott, 1976). Yet, relationships have many subjective aspects and it is necessary to identify the normative parts that can be modelled or formalised. Elliott (1976) distinguishes several ‘zones’ or levels at which relationships can be modelled (Figure 3.1). Our work relates essentially to the legal and institutional zone where the obligations, rights and protocols for required inter-communication are defined. For example, when a physician refers a patient to a specialist it must be done according to a pre-defined protocol which leaves no ambiguity as to whether the specialist will consult the patient or not. Interactions in the inter-subjective zone are essentially informal communications between the members of an organisation. As they do not have the mandatory aspect of a protocol, it is not required to support these interactions in the information system. Furthermore, human managers are unlikely to accept any normalisation of their informal communication.

P1

P2 institutional zone legal zone cultural zone subjective zone

inter-subjective zone

Figure 3.1

Relationship zones

A graphical representation of the relations between the concepts of people, roles and tasks is given in (Oeser, 1964 & 1979). The organisational system is composed of a set of people H (e.g.,

30

Chapter 3


{h1, h2, h3, h4, h5}), a set of positions to which the people are assigned P (e.g., {p1, p2, p3, p4, p5}) and a set of tasks which must be performed by the people assigned to the various positions. The set of tasks T supports ordering in terms of temporal precedence and composition, which makes it very similar to a workflow. Several graphs can be drawn according to: •

societal relations between people, H-graph e.g. h1 likes or is a good friend of h2.

•

relationships between positions, P-graph e.g. power relation.

•

task interdependency, T-graph.

Note that each of these graphs can be represented in a two dimensional space i.e. a plane. Relations of assignment can then be represented as graphs connecting these planes and indicating respectively: assignment of people to positions – H-P graph, and assignment of tasks to positions – P-T graph. The advantage of a graphical representation is that patterns of organisational problems can be recognised on the graph. For example, the assignment of a person to positions which have incompatible duties, the isolation of a person in the H-graph or the overstaffing and understaffing of the organisation. A quantitative perspective can also be added to the assignment relationships. For example, the proportion of time that a person spends working in separate positions or the proportion of time, which must be devoted to a particular task, can be specified (Figure 3.2). Certain properties can then be checked against this graph e.g., the sum of all the edges in the P-T graph relating to a position must be less than or equal to 1. Furthermore, by representing the H-P and P-T relationships as matrices of weights, we can determine the values of the composite relationship H-T by calculating the product of the H-P and P-T matrices. The result obtained determines the amount of time people will have to devote to each task.

t1

0.5 h1

1.0

p1

0.5 t2 0.5

0.4

p2

0.6

p3

h2

0.5 0.1 0.8

0.1

Figure 3.2

t3

t4

t5

H-P and P-T graph with quantification

In this thesis, we will adhere to the basic concepts of role theory and in particular to the definition of role in terms of rights and duties. The graphical representation of the assignment relationships

31

Chapter 3


and their possible quantification represent a starting point for user interface and analysis tools. Most of the other concepts of role theory, including the notion of conflict are based on the sociological aspects of organisational societies which have no direct relevance to the work presented in this thesis.

3.3 OIS and CSCW approaches The purpose of an automated Office Information System (OIS) is to perform the functions of an ordinary office by means of computer systems (Ellis, 1988). The activities undertaken by the OIS community range from assistance to the office-user in document preparation, to formalisation of the concurrent office activities e.g., by Petri-Nets. We are particularly interested in attempts to integrate office tasks and make use of an organisational model inside the system in order to support office activities. Much of the work presented in this section was carried out under the joint umbrella of OIS and Computer Supported Collaborative Work (CSCW). Two research directions have emerged: (1) designing a distributed processing environment that supports office activities and (2) analysing organisational requirements which need to be supported by a computer system. The latter is oriented towards identifying the type of relationships between objects/actors in the organisations to be supported by the computer system.

3.3.1 Organisational Relationships and Collaboration A large amount of work originates from the MIT Sloan School of Management regarding “coordination theory” (Malone, 1994). Among the interesting achievements of this work is an indepth study of organisational relationships and their characteristics. Malone (1985) and Crowston (1988) define organisational activities in terms of tasks and processors, i.e. entities which perform those tasks. Four different organisational patterns, which serve as the building blocks of an organisation, have been identified. They are distinguished according to the sharing of processors among various tasks and the centralisation of the decision-making process (Figure 3.3). In particular, the grouping of processors determines whether it is a functional hierarchy or a productoriented hierarchy, while the decentralisation of the decision-making process distinguishes a market style organisation (i.e. where products are bought or outsourced) from a control hierarchy. These organisational forms or patterns allow the authors to identify several types of dependencies between the various entities that need to be managed by appropriate co-ordination techniques (Malone, 1993 &1994). Among the identified dependencies and required co-ordinations are:

32

Chapter 3


product hierarchy

functional hierarchy

decentralised market

buyers

centralised market with brokers

managers

processor types

Figure 3.3 Alternative organisational forms Managing Shared Resources Whenever multiple activities share some limited resource (e.g., money, man-power) there is an interdependency between those activities. Organisational theory has emphasised a hierarchical approach to managing resource allocation in which managers at each level decide how the resources they control will be allocated. A particular sub-class of these dependencies is the task allocation problem where the resources are the actors involved in accomplishing the tasks. Here also, a hierarchy has been the usual means of achieving coordination, although the use of a market like structure where employees bid for the tasks to be performed have sometimes been suggested. Coordination for this type of dependencies is ensured by interaction protocols in which resources are requested and granted. The model also implies that managers at one level of the hierarchy can delegate or assign rights and duties to managers beneath them.

Producer/Consumer Relationships Producer/consumer relationships occur not only in market-like structures but also in hierarchically controlled structures. For example, an assembly line is a particular kind of producer/consumer relationship where the output of one production process serves as input to the next stage. Managing dependencies in producer/consumer relationships generally involves some form of protocol and notification from producer to consumer.

33

Chapter 3


Goal decomposition Goal decomposition inter-dependencies can be created both in a top-down decomposition and in a bottom-up goal identification process. Managing the dependencies created in this way may require centralised control or group consensus interaction protocols.

Concurrency constraints Concurrency constraints dependencies between the different tasks are managed in a hierarchical fashion since market-like structures already impose some degree of simultaneity. Coordination of activities and inter-task dependencies is achieved through interaction protocols and considerable emphasis is placed on the permitted message exchanges. Several research prototypes have been built (Information Lens, Object Lens and Oval) which can be used for supporting interactions between human users. Of these products, Oval (Malone, 1995) has a more general view of the modelled systems while Information Lens, the first product of the series, is more an intelligent mail sorting facility. Oval is a system designed to be ‘tailorable’ in the sense of allowing the users to build different applications on top of it. It defines four kinds of entities, which serve as building blocks for any application: •

Objects are collections of fields with associated values and operations that can be performed on them. Objects have types organised into an inheritance hierarchy.

•

Links represent relationships between objects, e.g., relationships between messages and their replies or between people.

•

Views summarise collections of objects and allow users to edit individual objects. Users can select fields to be shown in a view and links, which allow creation of a network display of object relationships.

•

Agents are rule-based processes that perform active tasks. They can be triggered by events such as the arrival of new mail, or the appearance of an object in a folder. When an agent is triggered, it applies a set of rules to a collection of objects. Rules contain descriptions of the objects to which they apply and actions to be performed on those objects.

Users can build applications by defining new object types, modifying the objects’ fields, selecting and specifying parameters for views, creating new agents and specifying rules for them or defining links between objects. This infrastructure is essentially used to structure communication between managers and is compared to systems such as gIBIS (Conklin, 1988) and the Coordinator (Winograd, 1986).

Discussion Malone’s research at the MIT Sloan School of Management does not include the notion of ‘role’. Yet, after a study of the relationships occurring in organisations it stresses the need for structured

34

Chapter 3


interaction to ensure coordination between the various entities performing tasks. Coordination can be achieved by adequate interaction protocols, which need to be supported by a tailorable infrastructure. Furthermore, interaction protocols can be specified and automated using a rulebased specification language. We address these issues in Chapter 5.

3.3.2 MCC’s view on Roles and Distributed Systems The initial project, Raddle, investigated at the Microelectronics and Computer Technology Corporation (MCC), concentrated on exploiting the concept of N-party interaction and synchronisation for building distributed systems. This was later used in an organisational setting for modelling roles by Singh (1992a&b) and Rein (1992a&b).

An early model for Distributed Systems Raddle defines an N-party interaction as the synchronous state-change of N processes. This concept encapsulates both the primitive interaction between processes and their synchronisation (CSP, Petri-Net style). The basic unit of encapsulation is the team, which is composed of several roles (Evangelist, 1988; Forman, 1986a&b). Roles can be of two kinds marked or unmarked. Marked roles are processes which begin execution when a team is instantiated while unmarked roles are taken by external processes. Thus, unmarked roles define a team’s interface to the outside world. Roles are composed of variables and rules, which specify how roles interact and alter variables. Interactions between any number of processes may occur within the team. However, all roles must synchronise before an interaction takes place. Teams can be composed in order to define a system, and since the team is also the basic unit of encapsulation, inheritance relationships can be defined between them. Inheritance is achieved by inheriting all the roles of a team. When several roles have the same name, a new role is created by constructing the union of variables and rules of all the roles with that name. An example often given in the Raddle literature is the one of a bounded buffer. Its specification can be written as shown in Example 1 (LISP syntax for usual primitives, e.g. car, cdr). Producer and consumer roles are unmarked and have to be taken on by other processes in the system. This is achieved by a call of the form team-address.role-name(parameters). ‘Buffer’ is a marked role and its rules are interpreted by an automated process, which is started when the team is instantiated. Interactions are represented as labelled ‘boxes’ (square brackets) in order to emphasise the semantic similarity to Petri-Nets. Teams can be composed in order to construct a Raddle system from available team objects. For example, a team integrating buffer users can be defined as shown in Example 2.

35

Chapter 3


Example 1

Bounded buffer

team Bounded_buffer new(size); bound := size; current := 0; bqueue := nil; end new role producer(pstuff) . . . iproducer[ ] . . . . . . . return; end producer

marked role buffer role consumer(cstuff) var bqueue, bound, current; . . . . . iproducer[ . current := current + 1; . bqueue := append1(bqueue, . pstuff)] . . . iconsumer[ iconsumer[ current := current –1; cstuff := car(bqueue)] bqueue := cdr(bqueue) ] . . return; end buffer end consumer

end Bounded_buffer Example 2

Buffer Users

team Buffer_users constants buffer1, buffer2; new buffer1 := Bounded_buffer.new(10); buffer1 := Bounded_buffer.new(10); endnew marked role R1 var stuff1; . . buffer1.producer(stuff1); . buffer2.consumer(stuff1); . end R1

marked role R2 var stuff2; . . buffer2.producer(stuff2); . buffer1.consumer(stuff2); . end R2

end Buffer_users Raddle was successfully used for modelling several case-studies and a visual environment for design and investigation, VERDI, was implemented. Yet, Raddle is essentially a language for general-purpose design of multi-process systems. Although the names of ‘team’ and ‘role’ were chosen from real-life observation, it is only in the work of B. Singh and G. Rein that the concept of N-party interaction was used for organisational modelling and office automation.

36

Chapter 3


Interconnected Roles The Interconnected Roles (IR) framework (Singh, 1992a&b) builds upon the concepts of role and N-party interaction developed in the Raddle project. Yet its aim is to create a mechanism that permits co-ordinated action of interdependent tasks and facilitates organisational restructuring and process re-engineering. While Raddle offered a few concepts and outlines a notation, the IR framework has a formal specification and operational semantics. Its process description notation – Role Interaction Nets (RINs) (Singh, 1992b; Rein, 1992a&b; Rein 1993) – provides the means to graphically specify N-party role interaction and its semantics is based on Petri-Nets. The IR model considers an organisation as a network of distributed roles. A role is defined as “an organisational unit that can accomplish something on its own”. Consequently, roles can be assigned to individuals and automated processes but also to other roles and organisational units. The behaviour of a role is defined by: (1) its content and (2) its interactions with other roles (Figure 3.4). The content of a role includes objects, tools, materials, operations and other roles. Roles operate asynchronously with respect to each other and synchronise through interactions. They have role occupants that may also act in other roles. However, a role occupant must act independently in each one of his roles, i.e., the role defines the context in which its occupant acts.

Role occupants

interaction role

Objects, tools operations, ... role

role

role

Figure 3.4

Roles according to Singh and Rein

Two particular types of roles are distinguished: (1) the surrogate role which represents human managers within the system and contains all the roles to which a manager is assigned and (2) the observer role which can monitor ongoing activities and change the specification of organisational roles. Each organisational role is associated with an observer role and therefore belongs to the visibility set of that role. Observer roles define the administrative model of the IR framework.

37

Chapter 3


Designing an organisation in the IR framework starts with the creation of surrogate roles for individuals. The observer role of the surrogate role-set is then assigned to one of the surrogate roles. This assignment of the observer role allows a manager to create and assign organisational roles. The organisational chart can then be designed as a set of interconnected roles. Individuals are assigned to their organisational roles by including the organisational roles in their surrogate role. Projects, teams etc., can then be designed in terms of interconnected roles and assigned to the organisational roles previously created. The obtained role network can then be analysed to answer questions such as “Who is responsible for task x?” Teams are specified as processes in a graphical process language notation, the Role Interaction Net formalism (RINs) (Singh, 1992b; Rein, 1993). A process is a set collection of organisational roles that communicate and participate in interactions to accomplish their goal. Roles can engage in solitary or joint actions. Solitary actions, also called one-party interactions, take the general form of: if ( condition ) then do { statements }. A statement refers to the execution of tool objects contained within the role. Joint actions compose the specifications of the interacting actors by taking the conjunction of the conditions and concurrently executing the statements, e.g.: If ( condition(A) and condition(B) and condition (C)…) then do { statements(A) concurrent with statements(B) concurrent with statements(C) concurrent with … } The graphical notation has a two dimensional representation projecting concurrent elements on the X axis and temporal precedence on the Y axis. A single action is represented by a square box and multiple boxes joined by a horizontal line represent a multi-party interaction (Figure 3.5). Synchronisation of concurrent single actions can also be specified through synchronisation bars. Furthermore, macros can be used in order to encapsulate process specifications. Interactions are also characterised by three attributes: •

mode – indicating whether the interaction is manual or automated

•

type – indicating whether the interaction is optional or obligatory

•

form – indicating whether the interaction is a macro or if it is a leaf description

The graph is divided into columns each representing a role in the process description. Columns can be further divided into sub-columns to represent concurrency within a role. Sequential operations follow one another on the temporal precedence axis (e.g., c and d in Figure 3.5) while

38

Chapter 3


the representation of concurrent operations is done by overlapping their representation (e.g., a and b in Figure 3.5). Choice operators can be used, however any given interaction can belong to at most one choice. Handing documents or objects in one interaction from one party to the others is specified through “supply” and “acquire” annotations along the horizontal interaction bars. The similarity of the RINs specification to Petri-Nets is striking. The fact that their semantics is also based on Petri-Nets comes therefore as no surprise. concurrency

role A

role B

role C

a b

c

d

e

f

multi-party interaction

temporal precedence ordering

action

synchronisation bar

macro

manual action

choice

Figure 3.5

Elements of Rein’s Notation

Discussion The work at MCC provides one of the few ‘complete’ role models. Assignment of users to roles is done through surrogate roles, which represent the users. Roles can be assigned to other roles (including surrogate roles) by being included in the contents of those roles. Users act in the various roles separately, each role representing a context for the execution of activities. Relationships between roles are defined by interactions that implement both communication and synchronisation, and are specified by a graphical process description language (the RINs formalism) based on rules. Although rich, this model imposes an operational semantics and interaction style for all objects that initiate actions in the system. In the context of distributed systems management, this would require to define ‘roles’ for all system components that interact

39

Chapter 3


with roles e.g., event disseminators. Furthermore, while the IR framework relies exclusively on synchronised interactions, most of the activities performed by the managers of a distributed system are in response to asynchronous events. Other less sophisticated approaches which formalise office activities in terms of interacting processes or rule-based tasks can be found in (Martens, 1991; Chrysanthis, 1990).

3.4 Roles and workflows Task dependency models and workflows, use roles as placeholders for human and automated processes performing the tasks. Most commercial workflow management systems define the following entities (Georgakopoulos, 1994): •

Workflows – a partial or total ordering of tasks,

•

Tasks – a partial or total ordering of operations or descriptions for human actions,

•

Manipulated objects,

•

Roles – a placeholder for the agents required to perform the tasks,

•

Agents – humans or automated systems that fill roles, perform tasks and interact during execution.

The main advantage of using roles as placeholders for agents (or managers) is that assignment of users to roles and of tasks to roles can be done separately. Agents can then be dynamically assigned to or removed from, roles at run-time. Relationships between roles are not expressed in terms of collaboration since workflows focus exclusively on the specification of inter-task dependencies. Bußler (1992) suggests to define roles as a set of capabilities that the role offers for the accomplishment of tasks and a set of requirements which the active objects must fulfil in order to play that role. A “role resolution” process selects the set of active objects having the necessary capabilities to fulfil the roles. This process also takes into account predicates specifying additional constraints. A slightly different position is taken in (Yu, 1993 & 1995) where dependencies between actors are expressed. Dependencies can be task dependencies (as in workflows) but also resource dependencies, goal or soft-goal dependencies. Actors are differentiated into roles, positions and agents. Agents play roles and occupy positions that cover several roles (Figure 3.6). Although Yu (1995) claims that “A more careful examination of a work organisation typically reveals that intentional dependencies are threaded through agents, roles and positions” no further use seems to be made of these concepts.

40

Chapter 3


Manager (Position) covers

occupies

Figure 3.6

Task Assignment (Role)

plays

John (Agent)

ARP model for actors in the Actor Dependency (AD) model

3.5 Do Roles Play Roles? Role theory emphasises an organisational perspective where roles (associated with positions) are a normative specification of managers’ behaviour in the organisational context. In this section we will introduce a slightly different way of considering roles based on the common understanding of role as in “plays a role in …” or “plays this role”. Here, roles are considered more as a subset of the functionalities of an object which are used in a particular context. Consequently, any object can have one or several roles. Furthermore, roles can be used as the interface of an object participating in a relationship, a name of a participant in an association or as a partial replacement for static classes in Object-Oriented systems supporting multiple inheritance.

3.5.1 OMT, OOram and Other Object Modelling Environments The concept of role in various Object Oriented Modelling Environments (Rumbaugh, 1991; OORam 1996; UML 1997) is used to specify the behaviour of an object within an association or collaboration. In OMT (Rumbaugh, 1991) a role is a name (label) which uniquely characterises a participant within an association. Role names are therefore used in order to traverse the associations from one object to a set of associated objects e.g., employee, employer in Figure 3.7.

Person

employee

Figure 3.7

Company employer

Roles in an OMT association

OORam takes a more dynamic view, using roles to describe patterns of interacting objects. A role is characterised by its attributes and the messages/invocations it may receive from or send to, other roles. UML, the new ‘standard’, has incorporated both views: the use of static role names in an association and the use of collaboration diagrams to specify dynamic behaviour. Several

41

Chapter 3


attempts at modelling organisations using Object Oriented modelling techniques exist. For example in (Silva, 1997), OORam is used to model both information system and business processes. Two types of roles are then in use: the OORam roles for the modelling of objects and the business roles. OORam object roles are manually assigned to business roles, in a second step. Some of the characteristics of the roles as used by OO modelling have been kept in other specifications such as the ODP Reference Model. These characteristics are: •

Roles are defined and exist only in associations or collaborations.

•

A role defines an aspect of an object within a given collaboration or interaction

•

Any object can fulfil a role.

In the ODP reference model (ODP-RM, 1995) a role (in terms of object modelling) is defined as a subset of specific functionalities which can be extracted from an object. When an object is viewed in terms of a role, only a subset of its actions is of interest. Each object may have several roles at a given time and may take different roles at different times. These roles may be associated with interfaces. Note that this concept of role is to some extent different from the roles defined later on in the Enterprise Viewpoint of the ODP Reference Model (see Section 3.5.3 below).

3.5.2 Roles in Object Oriented Databases and other object systems Objects are created as instances from classes, which are statically defined. However, some of the objects are long lived and must change their behaviour over their lifetime. In order to overcome this problem two strategies can be adopted: (1) use classes that are partitioned in roles and can be dynamically modified (Pernici, 1990) and (2) allow objects to ‘play’ different roles, and thus assume different behaviours, at different moments of their life (Wong 1997). Roles can be used in order to partition classes that evolve over time. For example a car may have a “production” role which models the different steps involved in its construction, a “transportation” role which models the relation between car and driver, a “registration” role, etc. Pernici defines classes as a named set of roles (Pernici, 1990). Each role is composed of a named tuple containing: •

A set of properties which are implemented by an instance level attribute. A property is defined by a pair (name, domain), e.g., (plates, string) for a car.

•

A set of states which describe an abstract role-state for an object in a given role, e.g., {switched-off, switched-on, going} for a car in its transportation role.

•

A set of messages which the object can receive or send in that role. Messages are prefixed by an operator indicating whether the message is sent or received.

•

A set of rules which define which messages can be sent, or received in each role state and which state transition must occur. Rules take the general format: state, message Ð state.

42

Chapter 3


The state of an object instance of a class is therefore defined at each moment in time by its state in all the roles it is playing. Each class has a base role, which defines primitives for adding, removing, suspending or resuming execution of a role. Integrity constraints can also be specified by predicates and are checked at transition states. Inheritance between classes is permitted. If new roles are defined in a sub-class then all roles are inherited from the super-class. If a role is redefined in a sub-class, then redefinition of the role can only add new messages and new rules to the definition in the super-class. No provision for analysis of the consistency of a role is presented or what happens if the new rules violate the integrity constraints of the super-class. The work presented in (Wong, 1997) considers long-lived object instances in an Object-Oriented Database Management System. Object instances assume different roles throughout their lifetime, and roles can be played by objects or by other roles. A hierarchy represented by the played_by relationship can therefore be built as an internal representation of an object. The object itself is the root of the hierarchy and roles comprise the other nodes (Figure 3.8a). Classes can be specified for objects or roles. An object class encapsulates the persistent properties of the object, while role classes define the transient properties. Role classes can be optionally restricted in terms of the type (class) of the object that can play role instances created from that class. Therefore, the overall object model includes object classes and role classes linked by two types of relationship: the is_a or sub-classing relationship and the played_by relationship. Figure 3.8b outlines part of the class diagram for a university department (Wong, 1997).

(a)

played_by Graduate Student

is_a

Club Member

Student

TA

(b)

Employee

Person

John

RA

Club Chairman

Teaching Staff

is_a

Graduate

Object

Object Class

Role

Role Class

TA

RA

Faculty

played_by

is_a

Figure 3.8

Research Staff

played_by

(a) objects with roles (b) class relationships

43

Chapter 3


The novel approach in both OO modelling notations and OO databases is that roles are identified with a subset of the functionalities or interfaces of objects. They can be either used to: •

Partition the behaviour defined by classes.

•

Define an alternative to classes when using multiple inheritance.

•

Define the subset of functionalities which belong to a particular association.

In particular, this last approach can be found in the Open Distributed Processing (ODP) Reference Model in both the computational viewpoint (under the concept of binding) and the enterprise viewpoint (under the concept of contract).

3.5.3 “The world by contracts” (ODP-RM) Subsequent to work on business contract modelling in computer systems, Milosevic uses the binding concept of the ODP Reference Model in order to integrate the technology and business contract issues in a model of contracts directly supported by the underlying information system (Milosevic, 1995 & 1996). A binding is defined, in the ODP-RM Computational Viewpoint, as an association between a set of objects that allows objects to interact. A binding type defines the roles of each object in the binding relationship. Roles map onto interface types that must be satisfied by the objects fulfilling that role. The binding type further specifies the interactions between roles and the obligations and requirements of the participants. A business contract can then be modelled as a binding between the contractual parties and other legal roles such as Notary, Contract Monitor (which enables monitoring of the activities of the parties) or Contract Enforcer (Figure 3.9). Each one of the contractual roles can then be associated with objects in the system. Obj Obj

Obj Notary Role Contract Enforcer Role

Contract Monitor Role Interactions Negotiate Validate Monitor Enforce

Party B role

Party A role

Obj

Obj

Figure 3.9

Contracts and roles

44

Chapter 3


The Enterprise Viewpoint of the ODP-RM aims at specifying the organisational requirements, goals and structure (ODP-RM, 1995). It represents the business activities, the role of the system in the business and the roles of the human actors and objects within the system. This definition of concepts implies that the Enterprise Viewpoint should cover in its specification all objects, system, resources and human actors which have some bearing on the business. Moreover, as emphasised in (Tyndale-Biscoe, 1997) the enterprise viewpoint aims to make explicit the policies, roles, and interactions between enterprise objects and to uncover some of the responsibilities implicitly attributed to the automated components of a system. Enterprise objects are any objects that can be regarded as atomic at the enterprise viewpoint level. In an enterprise specification, an open distributed processing system and the environment in which it operates are represented as a community. A community is defined as a configuration of objects formed to meet an objective, which is expressed as a contract specifying how the objectives of the community must be met. The community is defined in terms of the following elements (ODP-RM, 1997): •

The enterprise objects comprising the community,

•

The roles fulfilled by each of those objects,

•

The policies governing the interactions between enterprise objects fulfilling roles,

•

The policies governing the creation, usage and deletion of resources,

•

The policies governing the configuration of enterprise objects and assignment of roles to enterprise objects,

•

The policies relating to the environment contract governing the system.

A contract is a specification of the agreed behaviour necessary to meet the objectives of the community. It is specified in terms of: roles which define particular sets of behaviour associated with individual objects in the community, relationships which identify the interactions taking place between the objects fulfilling the roles and the resources associated with the actions and interactions identified by roles. It also specifies objectives of the community and the policies that apply to the objects and their activities. Policies can be obligations, permissions or prohibitions. Since roles relate to any enterprise objects, whether active actors or resources, two types of roles can be distinguished: actor roles which involve enterprise objects performing activities and artefact roles which are fulfilled by an enterprise object representing resources and are subject to the actions associated with the actor roles. The concept of contract in the enterprise viewpoint can then be mapped onto the notion of binding in the computational viewpoint. An example of enterprise viewpoint specification relating to the configuration of a leased line is given in (ODPRM, 1997). However, aside from a structuring which reflects the concepts all specifications are made in natural language. In particular, no specific notation is used for policy specification.

45

Chapter 3


Interesting aspects The association of roles with objects in general, highlights novel uses and definitions of the concept of role: 1. Roles are a subset of an object’s functionality. Therefore, roles can be defined for any objects (not just agents or managers) and generally map onto an interface of the object. 2. Roles can be used as classes or types of objects between which object instances migrate. 3. Roles are defined within some form of “binding” between several participants. The binding may be a simple association between classes, an interaction or a contract. This contractual view implies that roles, and tasks associated with roles, are specified as part of the contract. Consequently, an “organisation” is seen as a collection of communities (in the ODP-RM sense), in which participants are bound by contracts between communities. Furthermore, each community is an enterprise object and may play a role in a different community, also bound by a contract. We have informally called this view “the world by contracts” since any relationship between objects is considered as a “contractual relationship”.

3.6 Role-Based Access Control The essence of Role-Based Access Control is that permissions are assigned to roles rather than individual users. Users acquire those permissions by virtue of being assigned to the roles. This simple idea greatly simplifies the management of security while maintaining flexibility. It has therefore found its way in commercial products such as: •

SESAME from ICL

•

Microsoft Transaction Server

•

TME 10 Security Management framework from Tivoli (Tivoli, 1997)

•

Oracle 7 and Trusted Oracle 7 (Notargiacomo, 1995)

•

Jaguar Component Transaction Server from Sybase

•

Security administration Manager (SAM) from Schumann AG (Awischus, 1997).

Most of these products define roles as a simple indirection between users and permissions and use roles in an ad-hoc manner. Modern systems require however more sophisticated role-based access control models in order to cope with their increase in size, distribution transparency, variations of trust relationships (e.g. downloaded applications) and devolved security management. Research into RBAC models has therefore grown considerably in last few years (Jonscher, 1994; RBAC 1995; Maly 1996; Sandhu 1996; RBAC 1997; Tari 1997). Even if restricted to access control, role definition and enforcement has to address different design issues. Discussions at the first ACM workshop on RBAC (RBAC, 1995) attempted to identify and

46

Chapter 3


prioritise features of RBAC models only to be submerged by the diversity presented at the second workshop (RBAC, 1997). In fact, the most in-depth study of role-based access control (Sandhu, 1996) presents not one RBAC model but four. In the remainder of this section, relevant work on RBAC will be grouped according to the design issues addressed. Permissions are assigned to roles and users acquire those permissions by virtue of being assigned to the roles. This is the essence of RBAC to which the majority of current work subscribes. In a presentation at the first RBAC workshop (paper not included in the proceedings) Chris Sundt from ICL emphasised that assignment of users to roles, and of permissions to roles, is generally made by different persons at different times. Roles group the permissions necessary to achieve a particular task or fulfil the demands of a job function. The implementation of the least privilege principle can therefore be achieved by use of roles. Role-based access control is neither mandatory nor discretionary but offers an alternative access control mechanism. Furthermore, in (Osborne, 1997) it is shown that implementing role graphs (or role hierarchies) in a Mandatory Access Control environment is of little interest. The assignment of permissions to roles is subject to further discussion. One of the problems that has troubled the security community for many years is the problem of separation of duty, which occurs when tasks that are complementary towards the achievement of a goal must be performed by different managers (Clark, 1987). Several solutions have been proposed in RBAC, ranging from the explicit declaration of mutually exclusive roles (Kuhn, 1997) to the specification of constraints on permissions and users that can be associated with roles (Chen, 1995). The assignment of users to roles is also controversial. Sandhu (1996) permits users to combine several roles into a “session” while other approaches constrain users assigned to multiple roles to act separately in each role. In (Wong, 1997) where roles are considered in an OODBMS object model, the assignment of users to roles is further constrained by type compatibility between the attributes of role objects and those of user (subject) objects. Roles should share access rights in order to simplify access control specification. This can be achieved either: by allowing roles to be assigned to other roles, by allowing roles to inherit access rights from other roles or by composing roles into other roles. This last approach is adopted in (Tari, 1997) where global roles, visible at the intranet level, are composed of local roles determining access to objects within an intranet server. Also, Giuri (1995), considers roles as a named protection domain (Baldwin, 1990), and defines a simple arithmetic for composing them. The most general approach, adopted in (Sandhu, 1996; Nyanchama 1994; Tari, 1997) is to define role hierarchies (also called role graphs). In this approach, roles inherit permissions from other roles. This inheritance relationship, aimed at reuse of access rights, is in general identified with

47

Chapter 3


the organisational hierarchy, i.e., a senior role inherits the access rights of a junior role – see Figure 3.10 (Sandhu, 1996). Specialist physician

Primary-care physician

Project Supervisor

Programmer

Test Engineer

Physician

Health-care provider

Figure 3.10

Project Member

Examples of role hierarchies

Using hierarchies, all access rights of junior roles are inherited by senior roles. However, this is not always desirable. For example, the managing director should not inherit the access rights of a system administrator. Also, roles can have particular access rights, e.g., to private files which should not be inherited. In order to solve this problem, new roles must be created which are not inherited, e.g., Task T1’ in Figure 3.11. This leads to the creation of private role hierarchies. For example, the roles surrounded by a square box in Figure 3.11 (Sandhu, 1996) constitute a private hierarchy for sub-project 3 which contains access rights not inherited by the project supervisor S. Members of the project are then assigned to these private roles.

Project Supervisor S

Sub-project Supervisor S3’

T3’

Sub-project Supervisor S3

T4’

T3

Sub-Project P3’

T4

Task T1’

Task T1

Task T2

Sub-Project P3 inheritance to private roles private hierarchy

Figure 3.11

Project P

Private roles and private role hierarchies

As we have previously mentioned, the specification of constraints is necessary in order to control assignment of users and permissions to roles. Constraints can be used in order to indicate which roles can be grouped within a session (Sandhu, 1996) or which junior roles can be inherited in a

48

Chapter 3


hierarchy. A logic based approach for specifying constraints is taken in (Bertino, 1997) where static and dynamic constraints can be specified and used to generate the role assignment graph and plan workflow execution. However, the specification of constraints for roles is a research area still in its infancy. Chen (1995) describes elements of a notation based on logic and set operators, which bear some similarity to the Meta-Policies which will be introduced later on in this thesis. If roles are used to define access control, then how is access to roles controlled? This issue is also controversial. Essentially three approaches can be outlined: •

a separate hierarchy of administrative roles is used (Sandhu, 1996)

•

roles are implemented as objects and thus can be target objects with access control implemented in terms of permissions of other roles

•

roles are objects which are owned by users (Wong, 1997)

Several other issues have also been raised in the literature. For example Thomas (1997) expresses the need to distinguish between permission activation and permission assignment. In his model, relating to medical care, teams of roles are built and activation/deactivation of a team is an atomic operation. The need for multiple hierarchies for roles, e.g. by job function or by organisational unit, is shown in (Awischus, 1997). Also, the latter shows the utility of a “copy” function for roles and for a “master model” similar to a class from which control of all instances of the class can be exerted. Aside from the experience report given in (Awischus, 1997) very few publications exist on a methodology to identify and specify roles. Among these Fernandez (1997) shows how roles can be identified from use-case scenario specifications. Although RBAC has been essentially investigated by researchers from a security and database security background, recent studies apply the role-based concepts to other application domains such as telecommunications (Hamada, 1997). Before leaving the area of RBAC let us recall the family of models proposed in (Sandhu, 1996) and their characteristics. These models represent the levels at which RBAC can be considered and also to a large extent, the current status of research (Figure 3.12). Four different models are outlined (RBAC0-RBAC3). RBAC0 is the minimal level at which only user assignment (UA) and permission assignment (PA) relations are considered. RBAC1 includes RBAC0 but adds the capability of defining role hierarchies in which permissions are inherited. RBAC2 includes RBAC0 but adds the capability of specifying constraints. RBAC3 is the model grouping all the features of RBAC0-2.

49

Chapter 3


RBAC3 RBAC3 RBAC1

RBAC2 RBAC1

Role Hierarchy (RH)

RBAC0

User Assignment (UA) Users (U)

Roles (R) User

Permissions P Permission assignment (PA)

Roles

RBAC2 constraints Sessions (S)

Figure 3.12

RBAC Models and main features

Recapitulation Role-Based Access Control is only concerned with authorisations not duties, whereas management policies specify both. RBAC frameworks have explored new concepts such as sessions, role hierarchies and constraints. Sessions are needed in order to allow managers assigned to several roles to group access rights from a subset of their roles in a context of execution. Role hierarchies are used in order to inherit access rights between roles and constraints may be used to implement separation of duty. Furthermore, RBAC frameworks also have to cater for an administrative model, i.e., defining access control for role creation, deletion and modification. The work presented in this thesis has a very strong relationship to RBAC concerns and has been presented at the two RBAC workshops (Lupu, 1995 & 1997a). We will examine later the relationship to RBAC of the role model presented in this thesis (Section 9.1.2).

3.7 Roles for Multi-Agent Systems The work described in (Skarmeas, 1993, 1994 & 1995) is one of the few complete role models. The framework describes aspects of role modelling, role assignment, relationships between roles and role implementation. The environment for which roles are targeted is the April multi-agent platform (McCabe, 1995), in which agents written as April programs perform tasks and exchange

50

Chapter 3


messages. Roles are used in this context to structure the tasks for which agents (human or automated) are responsible. Roles can be either: •

Elementary roles which consist of collections of complex tasks

•

Roles which are a collection of elementary roles

•

Aggregate Roles, which are a collection of roles and coincide with social positions inside the organisation.

The assignment of aggregate roles to a human manager is achieved by associating a role identifier with the aggregate role. The role identifier represents a surrogate role, i.e., an agent representing the human within the system (Figure 3.13). Roles can be added, deleted, read and moved. Tasks can be executed, by sending a message to a role. Hierarchical relationships between roles are specified as part of the roles. Hierarchical and non-hierarchical specifications can be specified by contracts, which define the tasks to be performed by the contractual parties. Contracts can also be hierarchically composed, e.g., a contract between aggregate roles can be composed of sub-contracts between sub-roles of the contractual parties.

Role Identifier

Stock Manager Aggregate Role

Information retrieval

Stock Info

Stock Manipulation

Sale Info

Figure 3.13

Update

Roles

Order

Elementary Roles

Role aggregation and role assignment

Skarmeas also defines several types of role in order to support various requirements of the organisational structure. In particular: •

Virtual Roles are used in order to model the delegation of a role from a senior role in the organisational hierarchy to a junior one. Implicitly the senior role assumes the task of monitoring the activities of the junior role.

•

Group Roles are used to model committees. An aggregate role can therefore contain group roles corresponding to positions in various committees, e.g. chairman, secretary, etc. Note however that each task in a committee is attributed to one of its roles and there are no ‘collective tasks’.

51

Chapter 3 •


Gateway roles are roles containing tasks which relate to the filtering of information e.g. reports travelling up the organisational hierarchy.

•

Liaison roles are roles that distribute information necessary to the collaboration of two groups.

•

Collective Roles are roles (usually aggregate roles) which must be instantiated according to the environment, e.g., lecturers teach different courses and different classes. The composition tree describing the tasks of a lecturer must therefore be instantiated according to these parameters. No details are given on how this instantiation can be performed.

As the organisational structure or responsibilities of roles change, it is possible to send an ‘Execute’ message to a role for tasks that are no longer part of its duties. In (Skarmeas, 1995) this is called the Role Consistency Problem. The solution adopted is to maintain a Skill Server that encapsulates the knowledge regarding the capabilities of the various roles. The skill server must then be informed of any changes in a role’s structure or specification. The implementation of roles is based on the April platform. The code concerning roles, contracts and organisational processes is maintained in an Organisational Database. Roles are modelled as separate processes written in the April language which communicate with each other by messages. An agent shell communicates with the user through an interface and accesses the organisational database and role database (where the structure of the role and tasks is described). Execution of a particular task in a role is achieved by sending an ‘Execute’ message to that role. While this framework is complete in that it attempts to deal with most of the aspects of role definition, assignment and relationships, it remains very highly tailored to multi-agent platforms such as April. Tasks and procedures are written directly in a programming language and messages used to control and trigger execution. Although some examples are given in (Skarmeas, 1995) there seems to be no common notation which caters for all the types of role enumerated above. No constraints can be specified for the tasks that roles perform. Furthermore, all objects (including roles) are implemented directly in a programming language and their definition cannot be changed dynamically. The role process needs to be re-coded and re-started in order to implement organisational changes or changes in responsibility. The work of Skarmeas introduces some novel aspects in terms of role modelling. In particular, the Skill server is used as a trader for finding roles that have specific capabilities. Further, the notion of a group role introduces the problem of shared responsibility. In an organisation, committees are sometimes responsible for elaborating policies or implementing decisions. Responsibility is therefore shared amongst the members of that committee. The solution proposed by Skarmeas, and also adopted in (Gaines, 1991), is to consider the structure of the committee (e.g., chairman, secretary, member) and specify the duties of the participants in terms of group-roles. When

52

Chapter 3


generalised this solution leads to the concept of ‘community’. However, the ODP-RM approach is different since it considers that roles exist only as part of a community. Finally, the concept of collective roles expresses a need for role classes or role templates from which roles can be created according to the context in which they are placed. Note that this is different from the RBAC role hierarchies where inheritance provides the means of re-using access rights. No security or access control issues are investigated in Skarmeas’ roles.

3.8 Chapter Summary Roles provide a useful abstraction for grouping responsibilities of managers in terms of their duties and rights. Furthermore, roles cannot be considered in isolation but in a network of relationships that specify how managers assigned to roles collaborate and interact with each other. There are essentially two distinct notions of ‘role’ based on the organisational meaning and common understanding of the word respectively. Organisational roles specify the rights and duties of the managers in the organisational context. Therefore, roles are ‘first-class’ objects in the system. The common understanding of the expression “playing a role” has led to two different models which define a role as: (1) a subset of an object’s functionality and (2) as a named participant in associations, bindings or communities. Managers can be assigned or removed from roles dynamically. Furthermore, the specification of a role may change over time. A role model should define the following features: •

Obligations specifying the duties of managers and the tasks that they must perform.

•

Authorisations specifying the rights which managers acquire by virtue of being assigned to roles. Furthermore, permissions should reflect the duties of managers in those roles in order to implement the least privilege principle (i.e., that a manager is granted only those privileges necessary to perform its duties).

•

Relationships between roles which can support different organisational patterns and types of collaboration. Most of the techniques employed for achieving this purpose specify interaction protocols within relationships.

•

Concurrency control and in particular synchronisation of activities.

•

Assignment of users to roles through surrogate roles of agents representing human managers within the system.

•

Role aggregation.

•

Specification and use of skills or competencies that managers assigned to roles provide.

•

Representation of communities and multi-party relationships. Roles define the participants in the community and the interface (or services) which they must provide.

53

Chapter 3


•

Internal consistency of the role specification, i.e., absence of conflicts.

•

External consistency of roles in terms of: separation of duty between roles, mutually exclusive roles, constraints on the assignment of roles to users and of role participation to the relationships

•

Modelling of shared responsibilities.

•

Implementation, run-time deployment and handling of user sessions which combine roles or ensure separation of context between the roles.

The work described in the following chapters supports most of these features in the distributed systems management framework described in Chapter 2.

54

Chapter 4 Defining Roles

Previous chapters have outlined both the management environment in which roles must be defined and the current work related to role specification. This chapter takes the first steps towards a role model. We define what we intend by a role in the context of distributed systems management and answer basic questions regarding the role model such as: “what is a shared role?”, “how do roles relate to groups?”, “how are managers assigned or removed from roles?”. This will bring about other issues regarding role consistency and life-cycle. Finally, this chapter describes the implementation of a service ensuring the persistence of role objects and the implementation of a user interface allowing role specification. In this chapter, we also introduce the notions of relationships between roles, concurrency constraints and Meta-Policies. However, relationships are studied in-depth only in the following chapter and Meta-Policies are defined while dealing with the problem of conflicts between policies (Chapter 7).

4.1 Roles as sets of policies In Role Theory a role is defined as “a collection of rights and duties” (Biddle, 1979a&b). This corresponds, in our policy-based framework, to a set of obligation and authorisation policies that relate to the same subjects. Managers can then be assigned to, or removed from a role by being made members of, or being removed from, the common subject domain of these policies. However, this embryonic definition is vague in that it does not specify what a role is, nor in which context it is defined. The ambiguity is further betrayed by the common language use of “role”. A role may be intended as the part played by an actor in a relationship with a specific goal. This is the position taken in object-oriented modelling and also in the Enterprise Viewpoint of the ODP Reference Model. In this approach, a client role is defined with respect to a server role in a client/server association. However, neither client nor server can be defined outside the relationship and neither has an organisational role. Furthermore, in the client/server association,

55

Chapter 4

Defining Roles

roles are defined with respect to each other and the association specifies only their duties and rights with respect to each other. Also, roles may be specified at several levels in an organisation. For example, there can be multiple sections within an organisation each defining a section manager role. The rights and duties of section managers may differ from one section to another, even if the individuals “are all section managers”. Furthermore, despite the specific requirements of each section, section manager roles may have a strong similarity in their rights and duties. In order to account for the similarity between roles we also introduce, in Chapter 6, the concept of a role class. Thus, we consider that in an organisation with multiple sections there is a different section manager role in each section. Note that defining roles with a relatively fine granularity does not prevent us from allowing several managers to be assigned to a role. However, this requires a different semantics for the positive obligation policies that are part of a role’s specification.

4.1.1 Role Definition We initially define a role as a collection of policies relating to the same subject domain called a Manager Position Domain (MPD). A manager can be assigned to a role by including the user representation domain (URD) defined in Section 2.2 in the MPD. The policies of the role then apply to all direct and indirect members of the MPD and therefore propagate to the objects contained in the URD (Figure 4.1). Target Managed Objects

ROLE

Manager Position Domain User Representation Domain (URD)

\

User Role Agent

Role Obligation and Authorisation Policies Target Managers

Figure 4.1

Role with simple assignment

However, other policies, which are not part of a role may be specified with regard to the URD or MPD. For example, policies regarding the rights of the user, e.g., access to private files may have

56

Chapter 4

Defining Roles

the URD as subject and policies applying to groups of managers may have the MPD of roles as subjects (Figure 4.2). The User Role Agent represented in Figure 4.1 is essentially an obligation policy interpreter. In addition, it may also prompt the human manager to execute those activities which are specified as abstract tasks. As outlined in Section 2.3, the policy notation is used to express both abstract and implementable policies. Abstract policies may be refined in an iterative manner or specify actions that can be performed only by human managers. Role Object

Manager Position Domain User Representation Domain User Private Policies

domain inclusion

Role Policies Manager Position Domain

Manager Position Domain

Group Policies

reference

Figure 4.2

URD, MPD and associated Role

Several managers may be assigned to a role by including their URD in the Manager Position Domain. In an organisation, this would correspond to a position (e.g., director of finance) which is shared between several managers. If the role contains only authorisation policies then all managers would have the access rights conferred by these policies. Hence, the confusion between roles and groups in RBAC. The current semantics of obligation policies (Marriott, 1997) states that, upon receipt of an event, all managers in the subject scope have to perform the activities. Consider now the case of a nurse in a ward of a hospital. The following policy ensures that analgesics are administered to patients whose temperature exceeds 38° C. O+ on(patient(temperature>38, patient_name)) MPD { administer(analgesics)} /patients/patient_name If the nurse role is shared by two individuals and the semantics of obligation is preserved then analgesics might be administered twice. Therefore, in order to be able to assign several managers to the same role, it is necessary to assume that some coordination exists between user role agents in order to perform the actions only once. This coordination may take various forms from timebased exclusion (e.g., shifts for the nurses), to negotiation-based agreement.

57

Chapter 4

Defining Roles

Note that the subject of the policy given above is symbolically MPD, denoting the manger position domain of the role.

4.1.2 Assignment model There is a fundamental problem with the way of assigning managers to roles described so far. If the same manager is assigned to several roles, then according to Figure 4.1, the policies of all the roles will apply to the same objects, i.e., those which are members of the URD. This would allow the manager to perform actions in one role with the access rights provided by an authorisation policy in another role. In order to enforce a separation of concerns between roles, we adopt a different assignment model of managers to roles (Figure 4.3). In this model, a user is assigned to a role by specifying an authorisation policy, which grants objects in the URD the right to connect to, or to create, a User Role Agent (URA) in the MPD of each of the roles to which the user is assigned. The policies of the roles apply then to the URA and do not propagate to the objects in the URD. The adapter object represented in the URD can be thought of as similar to an XWindows server maintaining different windows for each of the roles in which the user is acting. Switching between windows represents an implicit context switch between the roles (Figure 4.3). Note that the separation between adapter object and user role agent is only logical. Therefore, the role agents may be implemented as threads of the adapter object to improve performance. In this case, the authorisation policy is still needed to be able to connect to the URA. Target Managed Objects

ROLE A Manager Position Domain for Role A User Role Agent User Representation Domain (URD)

Authorisation Policy

Role Obligation and Authorisation Policies

Manager Position Domain for Role B

Adapter Object

Connection

User Role Agent

ROLE B

Figure 4.3

Assignment with separation of context

58

Chapter 4

Defining Roles

4.1.3 Role life-cycle We have described (in Figure 2.9 and Section 2.3.2) the life-cycle of a policy which follows a Dormant ↔ Disabled ↔ Enabled pattern. For roles, we adopt the simpler Disabled ↔ Enabled life-cycle. This is because the state of a role depends on whether a manager has been assigned to it or not. Figure 4.4 shows the two states of a role with annotations regarding the required state of the policies.

Create

All the policies of the role are in the dormant state

Edit

Disabled

Enable

Deleted

Disable

All the policies of the role will be deleted

Enabled

Policies may be in either dormant, disabled or enabled state

Figure 4.4

Role life-cycle

If no manager has been assigned to a role then the role’s policies must be ‘dormant’ since they cannot apply to any objects. On the contrary, if a manager has been assigned to the role, i.e., if the MPD and the authorisation policy have been specified, policies can be in the ‘disabled’ state. The role is transparent to the policy enforcement mechanism since policies grouped within a role apply to objects in the MPD in the same manner as other policies specified for domains of managers. The algorithm for policy propagation to domains with dynamic membership is described in (Yialelis, 1996). As a result of the life-cycle adopted for roles, the following requirements regarding state and operations on the role and its policies may be specified (we adopt a semi-formal notation with object.state evaluating to the state, role.policies evaluating to the set of policies of the role, etc.): - If the role state is ‘disabled’ then: ∀ p ∈ Role.policies • p.state = ‘dormant’ - If the role state is ‘enabled’ then: Role.MPD ≠ ∅ /* the MPD of the role is specified */ /* there is a policy authorising a manager to access the objects in the MPD */ ∃ p:policy, x:URD • p.mode = ‘A+’ ∧ (x ⊂ p.subject) ∧ (Role.MPD ⊂ p.target)

59

Chapter 4

Defining Roles

- Perform enable operation on a role: Pre-conditions: Role.state = ‘disabled’ /* the role is in disabled state */ /* the MPD has been specified and the appropriate authorisation policy exists */ Role.MPD ≠ ∅ ∃ p:policy, x:URD • p.mode = ‘A+’ ∧ (x ⊂ p.subject) ∧ (Role.MPD ⊂ p.target) Post-conditions: /* all the policies are distributed to the agents */ ∀ p ∈ Role.policies • p.state = ‘disabled’ ∨ ‘enabled’ ∃ p ∈ Role.policies • p.state = ‘enabled’ (optional) - Perform disable operation on a role: Pre-conditions: Role.state = ‘enabled’ Post-conditions: ∀ p ∈ Role.policies • p.state = ‘dormant’ - Perform set_MPD operation on a role: Pre-conditions: Role.state = ‘disabled’ Post-conditions:∀ p ∈ Role.policies • p.subject = ‘@’ Role.mpd

4.1.4 Summary In this section, we have outlined: the basic definition of a role in terms of management policies, the assignment model and the role life-cycle. In particular, we have shown how it is possible to assign a manager to a role while preserving the separation of context between the roles to which the manager may be assigned. However, the role specification as defined suffers from several shortcomings since it cannot be constrained in either its structural or concurrency aspects. In the following we will introduce concurrency constraints in order to be able to restrict the order in which activities are performed. Structural constraints, (i.e., constraints on the policies which can be specified within a role) are directly related to the problem of conflict analysis for management policies and will be studied in more detail in Chapter 7.

4.2 Concurrency Constraints Concurrency constraints apply only to positive obligation policies. These are event-triggered rules, which specify a set of actions to be performed sequentially by the manager in response to event notifications. Although the events provided by the GEM monitoring system (Section 2.4) may be complex (i.e., composed of primitive events), it is difficult to ensure that activities specified in different policies are performed in a given order. Concurrency constraints are therefore required, to specify the ordering and synchronisation of activities. Even if concurrency constraints can be enforced in terms of composite events, the administrator responsible for specifying policies and roles should not have to define and change events manually. Note that

60

Chapter 4

Defining Roles

manually editing events would not only require an administrator to maintain correct event dependencies but also to interact with event monitors that are already active within the system. In this section, we will outline a basic notation for these concurrency constraints and a possible semantics in terms of composite events. The notation has broadly the same capabilities as pathexpressions. There are many well-known notations for specifying concurrency – CCS (Milner, 1989), CSP (Hoare, 1985) and Petri-Nets (Peterson, 1981) are widely used. More recently, a Labelled Transition System, which also allows property checking, has been defined and implemented within the Distributed Software Engineering group at Imperial College (Magee, 1997). However most of these systems have two shortcomings when considered for our purposes. First, most of them assume one communication style, e.g., handshake or n-party synchronised and must specify the others in terms of the communication style supported. Second, and more important, all of the aforementioned notations are aimed at specifying "process models" not simple constraints. We require a simpler notation and implementation. A textual notation of the required operators will be given in the following. However, before that, we give a simple management example outlining a more precise rationale for the constraints.

4.2.1 A Simple Example and more general considerations Consider the role of a base operator managing Base Station Controllers (BSCs) in a cellular network e.g. GSM. Transmission circuits between the BSC and the Mobile Switching Centre (MSC) may fail and the corresponding failure events (‘A_failure’) may be detected at both ends of the communication link. The following policies may be specified within the base operator role: /* When the failure is detected in the MSC the base operator must block the circuit */ policy_1 O+ on A_failure(circuitid) base_operator { block_circuit(circuitid) } /network/MSC /* The base-operator must reset the circuit when the failure is detected in the BSC */ policy_2 O+ on A_failure(circuitid, BSCid) base_operator { reset_circuit(circuitid, BSCid) } /network/BSC/BSCid The two events may reach the manager (agent) in any order. Yet the circuit must be blocked before a reset is performed, in order to avoid switching a call to that circuit while the reset is still in progress. This can be ensured by creating a new event, say ‘general_circuit_failure’, as the combination of the two ‘A_failure’ events. Policy_2 can then be triggered by this new event, which cannot be generated unless both ‘A_failure’ events have occurred. The above solution would require manually defining the new event, disabling and retracting policy_2 from the agent, modifying the policy and then re-distributing and re-enabling it. Instead,

61

Chapter 4

Defining Roles

a simple concurrency constraint can be specified as part of the role requiring the action in policy_1 to precede that of policy_2, e.g., policy_1:block_circuit ; policy_2:reset_circuit. An automated procedure can then ensure compliance of the agent’s actions with the concurrency constraints. In the previous example we specified constraints applying to actions within policies, by policy:action. Whether the constraint should apply to policies or to actions within policies is subject to a trade-off depending on the nature of the policies. The actions specified by a positive obligation policy must be executed sequentially unless specified for different types of objects (see Section 2.3.1). Concurrency constraints are generally imposed by the nature of the actions that are performed on the managed objects, e.g., block_circuit and reset_circuit. However, imposing constraints on every activity within a policy implies that: 1) compliance with the constraint must be checked before each activity is performed and 2) if an activity a2 follows an activity a1 in the same policy, then the start of a2 may be significantly delayed with respect to the end of a1. On the other hand, specifying constraints between whole sequences of actions specified within policies may undermine the concurrency of activities and unnecessarily sequence potentially concurrent activities. In the following, we consider the specification of concurrency constraints for policy activities within roles. This will allow greater flexibility in the concurrency constraint specification. Later, we also permit the specification of concurrency constraints within relationships (Chapter 5). Furthermore, the semantics for the concurrency operators will be given in terms of compound events for the start and end of each activity. This will offer two main advantages for the implementation: (1) code and components from the monitoring service can be reused for enforcing concurrency constraints and (2) events for the start and end of activities are easy to generate either by the role agent directly, before performing an invocation and after returning from the call, or by invocation filters in our Orbix-based implementation. At the time of writing, a full implementation, providing for the enforcement of concurrency constraints is not yet available and work continues both by the author and in the form of a M. Sc. project.

4.2.2 Concurrency Constraint Notation A concurrency constraint expression specifies the mandatory sequencing, synchronisation and permitted parallelism of activities. Furthermore, a concurrency constraint may specify that the execution of two sequences of activities must not overlap. This gives us for the concurrency constraints the following minimal EBNF syntax:

62

Chapter 4

Defining Roles

concurrency_constraint ::= label { expr | conflict_expression } conflict_expression ::= basic_activity ‘#’ basic_activity /* the execution of the two activities must not overlap */ expr ::= expr operator expr | ‘{‘ expr ‘}’ | on (condition) expr | basic_activity basic_activity ::= | policy /* refers to the entire sequence of activities specified within a policy */ | policy:action /* refers to an action specified within a policy (in the current role) */ | role:policy:action /* refers to an action specified within a policy and associated with the role (in the current relationship) */ | role:policy /* refers to the entire sequence of activities specified within a policy associated with a role (in the current relationship) */ operator ::=

‘;’ | ‘&’ | ‘|’ | ‘||’

For the time being we have not provided the ability to compose concurrency constraints, e.g., conc1 ; conc2. This could be supported by using the label of the concurrency constraint since the label is unique within the scope of the constraint, i.e., the role or the relationship. In the following, an activity ‘a’ can denote any of the expressions for a basic_activity detailed in the EBNF. The various operators and the ‘#’ symbol are described in more detail in Table 1 below:

Operator

Description

a1 ; a2 a1 | a2

Activity a2 must follow activity a1. Either a1 or a2 can be performed. The execution of the sequence may proceed when the activity has finished executing. Activity a1 and a2 may be performed concurrently. Execution will continue when either of them has finished executing. Activity a1 and a2 may be performed concurrently. Execution will continue when both have finished executing. The execution of the two activities cannot overlap. For example, if activity a1 has started executing then execution of a2 must be delayed until a1 is finished.

a1 || a2 a1 & a2 a1 # a2

Table 1

Concurrency operator description

This notation permits the specification of expressions, such as: /* The accountant must register the payment before issuing the cheque */ {accountant:p2:register_payment ; accountant:p3:issue_cheque}. /* The accountant can either register the payment and issue the cheque, or delay the payment. Both can be followed by producing a report of the transaction */ {{accountant:p2:register_payment ; accountant:p3:issue_cheque} | accountant:p4:delay_payment} ; accountant:p5:produce_report /* The accountant cannot update records and back_up records at the same time */ accountant:p2:update_records # accountant:p3:backup_records

63

Chapter 4

Defining Roles

4.2.3 Event based semantics A concurrency verifier component in the User Role Agent (Section 4.5) can ensure that an activity, which must be initiated, complies with the role’s concurrency constraints. The concurrency expressions can be translated into complex events composed of the primitive ones, which correspond to the beginning and end of an activity’s execution. These complex events can then be used to delay the execution of activities. The notation used for the definition of complex event rules is identical to the one used in the GEM monitoring system (Mansouri-Samani, 1997). Thus, features provided by GEM can be used to construct event monitors local to the concurrency verifier to enforce the constraints. The translation of the concurrency operators into composite events is shown in Table 2. The convention adopted is that ‘eiax’ and ‘efax’ denote the events of beginning and end of activity ‘ax’. Events for the beginning and end of a basic constraint expression are denoted by ‘eioperator’ and ‘efoperator’ respectively. ‘ax?’ denotes the event specifying that execution of activity ‘ax’ is now required and compliance with the constraints must be verified. The concurrency verifier receives as input the ‘ax?’ events and logs the ‘eiax’ and ‘efax’ events.

Operator

Event Translation

a1 ; a2

eia1 = ei; eia2 = efa1 ef; = efa2

a1 | a2

/* a1 is permitted if a2 has not started between the beginning of the composite expression and the moment when a1’s execution is required */ eia1 = {ei| ; a1?} ! eia2 /* a2 is permitted if a1 has not started between the beginning of the composite expression and the moment when a2’s execution is required */ eia2 = {ei| ; a2?} ! eia1 /* a1 | a2 ends when either a1 or a2 have finished executing */

ef| = {efa1 | efa2} a1 || a2

eia1 = ei|| eia2 = ei|| ef|| = {efa1 | efa2}

a1 & a2

eia1 = ei& eia2 = ei& ef& = {efa1 & efa2}

Table 2

Operator – event translation for concurrency constraints

Although intuitively a1#a2 could be translated as {a1 ; a2} | {a2 ; a1} the event translation is not so straightforward. The concept of ‘a1 conflicts with a2’ implies that the execution of the two activities must not overlap. This means that if a1 has started then the start of a2 must be delayed until a2 finishes or vice-versa. In terms of events this can be re-written as “there has not been an occurrence of eia1 (eia2) without a corresponding occurrence of efa1 (efa2)”. It is however much

64

Chapter 4

Defining Roles

easier to implement the a1#a2 expression in the concurrency verifier which can maintain a table of activities currently being performed.

4.3 Extended Roles In this section we extend the basic definition of a “role as a set of policies” in order to include the concurrency constraints, relationships and Meta-Policies. As mentioned briefly in Section 4.1.4, Meta-Policies are structural constraints on the role specifications, i.e., they are used to control which policies can be grouped within a role. ‘Meta-Policies’ is a simpler name for what Moffett termed “Policies About Management Action Policies” (Section 2.3.4.). They are constraints which define the ‘application-specific’ conflicts between management policies, e.g., separation of duty or multiple management. These conflicts are application specific because they cannot be detected by syntactic analysis of a policy specification. For example, a separation of duty constraint preventing the same managers from authorising a payment and signing the paymentcheque is specific to the actions ‘authorising a payment’ and ‘signing the payment-cheque’. Hence, this constraint must be explicitly specified. Modelling relationships between roles is a more ambitious goal and, the next chapter will be devoted entirely to this issue. As represented in Figure 4.1, the policies of a role may relate to target managed objects or target managers. In particular, it is possible to specify that a role (e.g. managing director) may be authorised to assign tasks to other roles (e.g. project managers). Similarly, it is possible to specify that project managers have a duty to report to the managing director every month. According to the organisational structure, there may be a large number of project managers for a single managing director. Hence it is desirable to factorise the policies relating to the relationship between the managing director and a project manager in a relationship object. The managing director has then several relationships, each with a different project manager. These relationships can be customised to reflect different duties and rights according to the project manager role considered. Policies are however only one aspect of management. Managers also interact and collaborate with each other in order to accomplish their tasks. In a management framework, where responsibility is devolved to multiple managers, there is a need to be able to specify the protocols according to which “formal” interaction between managers must occur. This requirement is also identified by Malone (see Section 3.3.1). Since relationships contain policies that may be constrained in either their concurrency or structural aspects, both concurrency constraints and Meta-Policies can be specified for relationships. The overall role model as represented in Figure 4.5 associates with an MPD: a set of

65

Chapter 4

Defining Roles

policies regarding the target managed objects, a set of constraints (both concurrency constraints and Meta-Policies) and a set of relationships. Relationships contain obligation and authorisation policies regarding the related roles or use of shared resources, constraints on these policies and interaction protocol specifications. For each Relationship Obligation and Authorisation Policies

Manager Position Domain Role A

For Target Managed Objects Obligation and Authorisation Policies

Manager Position Domain Role A

Constraints Specification

Intra-role Constraints (Concurrency constraints and MetaPolicies)

Interaction Protocols Specification

Figure 4.5

The extended role model

4.4 Role Service and Role Specification Tools A role object maintains different tables for different kinds of objects (policies, constraints, and relationships). Only references are stored for policy and relationship objects. Within each table, a reference (for policies and relationships) or an expression (for constraints) is associated with a name, local to the role, and unique within that particular table. Since concurrency constraints and Meta-Policies refer to policies by their local names within a role, it is possible to change a policy reference without updating the constraints. However, this may introduce inconsistencies if the new policy does not have the actions referred to by the constraints. These inconsistencies can be detected automatically by the role editor but updates must be performed by the administrator. A brief outline of the role implementation is given in Figure 4.6, for the full specification of the IDL interface please refer to Appendix B. Domain path relationship object references

Role MPD

name

policy object reference

name

expression

name

expression

relationships policies concurrency constraints meta policies

Figure 4.6

Outline of the Role Implementation

66

Chapter 4

Defining Roles

The role service ensures the persistence of role objects and supports the basic role functions defined in the role interface. These include adding and removing policies, constraints and relationships to the role specification, assigning a manager position domain for the role and enabling/disabling roles. The role service interacts with the policy service, which ensures the persistence and distribution of policy objects, and with the domain service maintaining the domain hierarchy. An administrator uses a set of tools in order to edit roles and policies, and browse the domain structure. The User Role Agent also interacts with the role service in order to: (1) access the role specification and implement the policies grouped within the role (2) perform management operations on role, policy and domain objects. Remote interaction was implemented in Orbix (IONA, 1993), a CORBA compliant distributed programming environment (Figure 4.7). Domain Browser

User Role Agent Administrator

Role Editor Policy Editor

CORBA Invocation Plan

Role Service

Policy Service

Domain Service Monitoring sub-system

Figure 4.7

Role Service and Role Specification

The Role Editor is fully integrated with the other tools (domain browser, conflict detector), and offers object selection through drag and drop interfaces and context dependent menus. The implementation uses the [incr Tcl/Tk] toolkit (McLennan, 1993). Since a large amount of information is contained in a role, the various role components can be visualised in different windows as shown in Figure 4.8. The toolbar in the central window allows selecting the component windows that are displayed at any given time. A different mode of operation (for the more experienced users) avoids display clutter and shows the role components by switching between a number of panes. Policies are represented within a graph structure, which shows the policy references, i.e., children and parents within the refinement hierarchy and cross-references.

67

Chapter 4

Defining Roles

Adding policies or relationships to a role can be done by dragging objects from the domain browser tool. Editing or removing these objects is offered through a context-dependent menu. Although the Tcl/Tk framework allows relatively rapid development of user interfaces, it is based on an interpreted command language thus deteriorating performance. The object-oriented extensions offer an advantage for the programmer but the encapsulation is not strict. A large amount of work also went into porting the policy service to the newer Orbix2.1 and SPARCWorks platform. The role editor and a re-developed policy editor have been subsequently been integrated in a common specification tool called “Red”.

Figure 4.8

Components of a role in the role editor

4.5 An architecture for the User Role Agent The User Role Agent (URA) resides in a role’s Manager Position Domain and has four main interfaces in order to: interact with similar agents in other roles (interaction interface), receive commands and interact with the human manager (role command interface), interact with the underlying system to receive event notifications (system interface) or extend the agent’s capabilities by dynamic loading of procedures (extensibility interface) − Figure 4.9.

68

Chapter 4

Defining Roles Outgoing invocations, messages and events

Role Command Interface

Interaction Interface

Extensibility Interface

Figure 4.9

System Interface

User Role Agent Interfaces

The manager agent assigned to a role interacts with the adapter object included in its User Representation Domain. The URA interfaces directly with the adapter object in order to inform the manager of received event notifications or triggered abstract policies requiring implementation. Moreover, the URA can indicate to the manager actions that are prohibited by the authorisation policies or that he must refrain from performing, as specified by negative obligation policies. The URA also conducts a dialog with the manager regarding conflicts encountered between policies. Some conflicts may be resolved if precedence was given to some policies over others (Section 7.3.1). As we will see in the following chapter, one of the fundamental aspects of interaction protocol specification is the ability to offer human managers the choice between alternative answers to be sent in response to an incoming message. The Role Command Interface may also be used for this purpose. The actions specified within policies may be operations defined in the target object’s interface but may also be procedures that are programmed into agents interpreting the policies. According to the procedures defined within the policy agent, the latter may be considered as “customised” to handle particular tasks, e.g., configuration agents, diagnostic agents. Thus, the capabilities of an agent may be varied dynamically according to management needs. New policies can then be specified in order to take advantage of the improved capabilities. Extending the procedures defined within an agent can be easily envisaged if the agent is programmed in an interpreted language or in a language running on a virtual machine which supports loading and just-in-time compiling (e.g. Java). However, frameworks for extensible agents have also been implemented for statically compiled languages, e.g., “Elastic Agents” (Goldszmidt, 1995). The User Role Agent must therefore allow for the delegation of new capabilities through an “Extensibility Interface”.

69

Chapter 4

Defining Roles

The System Interface allows an agent to interact with the underlying system, receive event notifications from the monitoring system, revocation notifications from the access control system and respond to access control or identification queries. Finally, the interaction interface allows a URA to communicate with the agents assigned to the Manager Position Domain of related roles. In order to implement positive obligation policies a URA must perform invocations on the target objects. These invocations are also subject to the ruling of negative obligation policies, i.e., actions the manager assigned to the role must refrain from doing, and concurrency constraints. Thus, in order to be successful each invocation (or sequence of invocations) initiated by an Obligation Policy interpreter must be filtered by a set of components which take into account the other specifications contained within the role (Figure 4.10).

Interaction Protocol Rules

Receive messages Interaction Protocol Agent

send_message()

Positive Obligation Policies

Reply to messages

Invocation

Obligation Policy Interpreter (Obliman)

Target Objects

Event Notification

Negative Obligation Policies and runtime conflicts

Concurrency verifier

All the role policies

Concurrency constraints

Figure 4.10

GEM Monitoring interface

User Role Agent (proposed architecture)

The obligation policy interpreter interprets positive obligation policies and initiates invocations on target objects in response to event notifications. The first “filter” on these activities ensures the compatibility of this invocation with the other policies of the role. In particular, it enforces negative obligation policies. However, this component may take into account the other policies of the role to detect any conflicts that occur at run-time and consider precedence relationships between policies. Note that the User Role Agent may not be trusted to enforce authorisation

70

Chapter 4

Defining Roles

policies. An invocation that violates authorisation policies specified in the role may however be detected within the agent, thus avoiding unnecessary computation in the access control system. If the invocation proceeds it must further comply with the concurrency constraints. A concurrency verifier may therefore reject or delay an invocation according to the concurrency constraints specified within the role. As an agent may not be trusted to implement authorisation policies, it can further not be trusted to implement those Meta-Policies which are dependent on parameters that change dynamically e.g. domain membership. This must be ensured by external trusted components within the underlying support system. A sub-component of the User Role Agent handles the interactions with the related roles. This component − the Interaction Protocol Agent − is further described in Chapter 5.

4.6 Chapter Summary In this chapter we have outlined a basic role definition in terms of management policies. This first step was followed by an extension to the role specification to cater for concurrency constraints. We have further determined the need for relationships between roles and have briefly shown that compatibility between policies in terms of application-specific conflicts may also require the additional specification of Meta-Policies. Concurrency constraints may apply to actions within policies or to the entire sequence of actions specified within a policy. These activities may be constrained in terms of order (i.e., sequencing) or in terms of synchronisation (e.g., activities A and B may be executed in parallel but both must be terminated before the next activity is started). We have outlined a notation for the concurrency constraint and given a translation of the operators in terms of composed events, which can be enforced by the monitoring system. Assigning a manager to a role may be done by domain inclusion if the manager is assigned to at most one role. A more complex model is required in order to ensure separation of context if managers may be assigned to multiple roles. Assignment is then realised by preventing the policies specified in the role from propagating to the User Representation Domain and specifying an additional authorisation policy which effectively authorises the manager to “act” in the role to which he was assigned. While the policy-life cycle is based on both the enabled/disabled status of a policy and the distribution of the policy to the agents in its subject scope, the life-cycle of a role is based only on the assignment of a manager to that role.

71

Chapter 4

Defining Roles

We have outlined the implementation of a role service, which ensures role object persistence and caters for the basic role operations. Furthermore, we have presented the tools that have been implemented to support role specification for administrators and policy-makers. Finally, we have proposed an architecture for the User Role Agent, which is responsible for the implementation of policies, compliance with the concurrency constraints and handling of role interactions. However, this chapter has left several questions unanswered and has introduced several concepts yet to be explored. We have introduced the concept of a relationship between roles and the notion of interaction protocols. This subject brings about other issues relating to on-going research in the CSCW and OIS communities. We will leave a more detailed discussion of inter-role relationships until the next chapter. Also, it would be very useful to be able to define a role template which can then be parameterised with specific target domains. It would then be possible to define the role policy set as a class from which particular instances can be created. For example, a role class could be defined for a region manager and this could be used to create North, South, East and West region manager roles. Each of the four roles instances has its own manager position and specific target domains, but specifies the same policy activities and constraints for each role. An advantage of an object-oriented approach to specifying roles and policies classes is that inheritance can be used to define new role classes in terms of the existing ones. These objectoriented features can also be extended to relationships. For example, many companies have standard templates for their contractual agreements with subcontractors. The template specifies standard terms and conditions for obligations of the company and contractor without knowing which of the company agents will implement them and to which subcontractors they apply. These issues will be explored further in Chapter 6.

72

Chapter 5 Defining Relationships

Roles and their relationships were first introduced by sociologists and psychologists for analysing organisations. However, most of the work deals with “power-based” sociological relationships (Biddle, 1979b). We are more concerned with what Hirschheim (1986) calls the “analytical taxonomy”: the perspective of an environment in which managers perform a variety of formal and structured actions. Even if this narrows the perspective on the type of relationships which need to be supported by the role framework, it still does not impose clear boundaries on the spectrum that we are trying to cover. We will therefore impose an additional restriction concentrating only on those relationships that can and must be formalised. Referring back to the initial work in role theory, we will be interested in those relationships situated in the “institutional” and “legal” zones (Figure 3.1) disregarding any aspects which may regard the “subjective”, “inter-subjective” or “cultural” zones (Elliott, 1976). In a nutshell, we will attempt to model those relationships in which the rights and duties of related parties must be specified and in which interactions must conform to a set of predefined protocols. Constrained interactions are needed to support collaboration between managers as outlined in (Malone, 1994). In the previous chapter, we have already hinted at the need for a relationship model by referring to the obligation and authorisation policies, which should be factorised in a relationship, and to the interaction protocols to be defined. In this chapter, we will widen the foundation of our argument by a short study of issues to be addressed by an interaction model. After a brief literature survey on current techniques for modelling interaction and coordination we will outline the specification of the interaction protocols, and the implementation of relationship objects and interaction agents. The interaction agent is a component of the User Role Agent previously defined (Section 4.5).

73

Chapter 5

Defining Relationships

5.1 Issues for Role Relationships A large number of studies on “generic relationships” or relationship classification can be found. To mention only one, the work of Malone’s group (reported in Section 3.3.1) provides a good starting point for the classification, modelling and implementation of relationships in collaborative work. A relationship can involve any number of roles, be hierarchical or peer-to-peer and may involve any number of activities of any nature. Particular attention has been paid to hierarchical or powerrelationships in organisations. However, within the institutional and legal zones, power relationships must also be specified in terms of the rights and duties of senior roles towards junior roles and vice-versa. This is required since the manifestation of these relationships in terms of the rights and duties of related parties is generally not uniform across the organisation and can differ significantly from one organisation to another. Regardless of their nature, a relationship model must permit the specification of: •

a set of related parties

•

a task model – defining actions that can and must be, performed by the related parties

•

a concurrency model – constraining the ordering and synchronisation of tasks

•

an interaction model – which defines the permitted message exchanges between related parties and actions performed in support to, or as a result of, interactions.

Since we have discussed at some length the task model in terms of policies and the concurrency constraints that can be enforced, we will concentrate in the following on the interaction model. Managers assigned to roles interact and exchange messages with each other in order to perform their tasks, share information and agree on their commitments. Interaction protocols are necessary in order to specify permitted exchanges of messages and ensure unambiguous termination of the exchange. However, the specification of protocols raises several issues regarding the interactions considered:

Human vs. Automated interactive entities A communication protocol between automated agents must be deterministic. Although heuristic approaches can be developed, the behaviour of an automated agent then becomes unpredictable. Interactions occurring between human managers are always partly non-deterministic due to human choice. For example, in a negotiation on the price of an item, a human manager might respond to a counter-proposal by a request for further details even if this was not specified in the initial protocol. Most of the work in this area constrains human managers to a pre-defined protocol and/or concentrates on capturing the “illocutionary” value of the messages exchanged.

74

Chapter 5


The protocol we aim to develop should provide a flexible framework for communication between human agents as well as deterministic behaviour for communication between automated managers.

Two-party vs. multi-party interaction The problem of multi-party interactions is an underlying concern when modelling interactions among agents. Although techniques such as the Contract Net (Smith, 1980) have been available for a long time, most of the recent work does not deal with multi-party interactions. We believe that multi-party interactions are essential e.g. for specifying joint decisions or task allocation for roles. De Greef’s notation and the April language (de Greef, 1992; McCabe, 1995) identify the need for sets in the interaction specification language to express the multiple senders or receivers in an interaction and for collecting the multiple messages received by one manager.

The illocutionary value of exchanged messages 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) (Johanneson, 1995) must define the set of all the message types used in an interaction. An illocutionary value (see Section 5.2.1) can then be given to each message type and rules can be built for deriving knowledge of the state of the system and the activities of the managers. We do not aim to provide a knowledge-based system that makes use of illocutionary values, but we make provision for it and recognise its benefits for assisting managers in their tasks.

The content of exchanged messages In early studies of interaction protocols, the value of a message is the value of the illocutionary act it represents. These are entirely predefined in the protocol and a message has the same value regardless of the stage the interaction protocol has reached. Schmidt and Simone (1995) describe the case of a “bug form” which is filled in by various managers involved in the development of a software product. The success of this protocol relies partially on the fact that the constraints placed upon different managers and past interactions between them are explicitly represented within the exchanged message – the bug form. In particular, when a designer receives the bugform he has knowledge of the previous stages of the interaction – tests, specification scheme, etc. This highlights one of the main limitations of the actual protocol specification. In both “The Coordinator” (Winograd, 1988) and the de Greef specification language (de Greef, 1992), a received message triggers the same action regardless of the previous “history” of the exchanged messages. Specifications like “release patch only after receiving two testing reports” are desirable and should be accommodated.

75

Chapter 5


Interaction as a means of specifying synchronisation This approach is largely adopted in (Singh, 1992a&b) where all the different parties involved in multi-party interactions have to synchronise. However, the model developed by Singh and Rein has its own operational semantics in which n-party synchronous interactions are the primary means of interaction between programmed processes. In this management framework, we consider the process model to be distributed between the policy specification and the concurrency constraints imposed on it. It is therefore difficult to use interactions to specify entirely the synchronisation of manager activities, as the interaction components cannot take into account events relating to the execution and completion of a task. Nevertheless, it is necessary to interface between the interaction components and the policy interpreter in order to accommodate specifications such as: “Perform this task when given the order to do so”.

5.2 Related Work 5.2.1 Multi-agent and Speech Act Based Approaches Probably the most popular approach to interaction protocols in the CSCW and OIS communities is based on Speech Act theory (Austin, 1962; Searle, 1969). The main concept underlying this theory is that a semantic value or meaning can be attributed to each message or message type in order to support “meaningful” interaction between agents. This meaning is termed the “illocutionary” value of the message. For example a statement such as “The URL of our document archive is ftp://dse.doc.ic.ac.uk/dse-papers” has an assertive value about the state of a system while a statement such as “I will perform the backup of the system by 9.00 pm” has a commissive value on the activities of a manager. The first system introducing such ideas was “The Coordinator” (Flores 1988; Winograd, 1988). A large amount of work has followed their example; amongst others (Finkelstein, 1989; Woo, 1990; Bond, 1990; Fuks, 1993; Sen, 1994; Laufer, 1995; Johanneson, 1995; Pitt, 1995; Martin, 1996). These papers differ not only in application domain and purpose of the interactions considered but also in underlying semantics and handling of different illocutionary values. However, they do have one thing in common: interactions are considered to occur between “intelligent” agents. Agents are considered intelligent in that they have some form of knowledge base and inference capabilities. Another feature of these works is that emphasis is put on the “intelligence” of the agent rather than on the capabilities of the underlying interaction protocol. Because of the amount of research in the field, a standardisation effort has culminated in the draft specification of the Knowledge Query and Manipulation Language (KQML) (Finin, 1993&1994) which has been adopted with minor changes in most of the current implementations of inter-agent

76

Chapter 5


interaction protocols. Here we refer of course to “intelligent agents” again. The KQML language defines the structure of the messages to be exchanged between agents and the “performatives” which can be exchanged. For simplicity, a “performative” can be considered as a message type with associated parameters and semantics. Performatives can be nested and the contents of the message can be expressed in any particular language. For example, a message asking for the share price of IBM stock can be encoded as (Finin, 1994): (ask-one :content (PRICE IBM ?price) :receiver stock-server :language LPROLOG :ontology NYSE-TICKS) In this example the performative is ask-one, the content is (PRICE IBM ?price) which is a query written in the language LPROLOG. The message is addressed to the agent identified as stockserver. The interacting agents must implement the performatives. Although no constraint is put on

this implementation, a semantics is assumed for a minimal set of performatives. Current research and standardisation efforts are continuing towards achieving a common expression for the semantics of all performatives, e.g., implementing a modal action logic specification. Not all agents are “intelligent” and a large number of research projects concentrate on the design of multi-agent systems, i.e., a collection of programmed processes that interact with each other by exchanging messages. Amongst these projects the de Greef notation (de Greef, 1992), and its implementation in the April language (McCabe, 1995), provides a framework powerful enough to implement interaction algorithms such as the Contract Net (Smith, 1980). Messages in April are implemented as tuples and pattern-matching is used to perform run-time type identification in order to determine which messages are currently acceptable. Support for multi-party interaction is provided by the use of sets of receiver agents and by the ability to collect messages from multiple senders. For example, a simple printer server can be written in (pseudo-)April as: server() { repeat{ [print,file?f] -> /* print file f */ | [listjobs] -> {joblist >> replyto} /* send the job list */ | [suspend, jobtype?j] -> {/* suspend job j */; repeat { [resume] -> /* resume job */ | [cancel] -> /* cancel job */ } until timeout} | [cancel, jobtype?j] -> /* cancel job j */ } until quit };

The print server can print files, list the current jobs, suspend or cancel a job. If a job has been suspended, it must be either cancelled or resumed within a given time before other jobs can be accepted.

77

Chapter 5


5.2.2 Process Model Approaches Communication protocols in computer networks and telecommunication disciplines are often specified using finite state machines, Petri-Nets, labelled transition systems or other process models. This approach is largely unsatisfactory for role interaction agents which may apply to human or automated agents – the main limitations of these notations being: •

All 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.

•

Exchanged messages have no semantic value – they are transitions from one state to another.

Including humans along with automated managers in a management framework introduces tradeoffs between the flexibility and assistance desired by a human manager and the efficiency required of an automated process. This is particularly true for network interaction protocols. Classical protocol specification languages such as ESTEREL (Berry, 1992) assume a deterministic specification and concentrate on interaction efficiency. A protocol specification is compiled and can be used to generate outline code for an application. (It is assumed that the protocol specification remains unchanged during the application’s lifetime.) The various alternative answers to a message are all known when the protocol is specified. In the case of interaction protocols for user role agents, the protocol specification must be flexible enough to allow dynamic changes without complete recompiling, just as policies can be dynamically loaded or retracted from agents. Nevertheless, process-modelling languages are sometimes supported by tools which allow some degree of verification of the protocol, either by simulation or for property-checking. An interaction protocol specification should therefore be translatable to a notation which can then be statically checked for properties such as deadlock or termination before being deployed to the user role agents.

5.2.3 Regulated Coordination A common characteristic of the above related work, is that interactions form an integral part of an agent’s program. Thus, interaction protocols define the behaviour of agents rather than constraining it. If applied to our current role framework, this implies that no distinction is made between the user role agent and the agent or human manager that acts in that role. The work on regulated (or law-governed) coordination (Minsky, 1997a) differs from the studies mentioned so far, in that it caters for constraints or laws which are imposed on an agent’s interactions. The law of an interaction comprises a set of rules specified in Prolog (or subset thereof) which regulate the exchange of messages between members of a distributed group of agents. Rules are

78

Chapter 5


enforced when an agent attempts to send a message to other members of the group, or when a message is received. They are implemented by a controller agent associated with each member of the group. The controller resides between agent and communications medium and rules are enforced before delivering a message to the communications layer (on a send event) and before delivering the message to the user agent (on a receive event). Rules are maintained by a secretary and apply to all the members of the group. They can specify actions to be undertaken which may include buffering and delaying of messages, ensuring that conditions are satisfied, etc. In addition to the rules of the law, which are essentially reactive, Minsky extends the specification with obligations, which specify that certain actions must be carried out at a specified future time. New rules can be added to the law and participants can dynamically join or leave a group. Also, an agent may join several groups at the same time. Consider the case of flow control of invocations from clients to a server in a particular group. The following rule from (Minsky, 1997a) ensures that a message sent to the server s will be forwarded to the server if there are no buffered messages and if a minimum delay is maintained between two consecutive invocations. Otherwise the message is buffered and an obligation to send the message at the earliest time satisfying the condition is set. sent(X,M,S):buffer([])@CS, lastCall(Tlast)@CS, delay(DT)@CS, clock(T)@CS, T > (Tlast + DT) -> (do(lastCall(Tlast)

Rule (1) specifies that a Seller can initiate the interaction by proposing a price. Rule (2) specifies that after receiving a proposal and zero or more counter-offers, the Buyer can reject giving reasons, accept and specify a desired delivery date, or return a counter-offer with a new 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 and order the delivery of the product, or can make a new counter-offer. Rule (4) indicates that the Buyer must issue a

86

Chapter 5


payment cheque if the proposal is accepted by the Seller and rule (6) indicates no action if the counter-offer has been rejected. Similarly, rule (5) indicates that the Seller must order the delivery if the Buyer has agreed to pay the negotiated price and rule (7) indicates no action if the proposal or a counter-offer have been rejected. The advantage of this notation is that new rules can easily be added to change the alternatives defined by the protocol. Also, a rule can be changed without needing to recompile the whole protocol specification. For example, rule (8) could be added for the seller to permit rejection of an offer only after at least two counter-offers (assuming reject is not present in rule (3)): (8) propose.(counter)2.{counter}* ⇒ [reject, reasons] È buyer In order to indicate the dynamic features of this framework, we assume that the Seller offers the possibility to the Buyer to request additional information about the offered item. The Seller needs to indicate an extension to the universe of discourse, which is accomplished by a ‘counter’ message with moreinfo as a parameter in the answer field indicating that the Seller can now respond to a moreinfo message. Rule (9) is derived from rule (3) to achieve this. (9) propose.{counter.counter}*.counter ⇒ [counter, newask, moreinfo] È buyer or [reject, reasons] È buyer or [accept, delivery] È buyer

The rules for the buyer must then be extended to permit generation of a moreinfo request.

5.4 Defining and implementing relationships The specification of interaction protocols was described in some detail in the previous section. However, with the exception of the brief remarks made in the previous chapter, the definition and implementation of relationship objects have not been covered. In particular, questions such as: “How do policies inter-relate with interaction protocol rules?” and “What distinctions can be made between policies included in a relationship and those included in a role?” still remain to be answered.

5.4.1 The relationship model Consider three roles, A, B and C, and two relationships R1 and R2. R1 is a relationship between roles A and B only, while R2 is a relationship between roles A, B and C (Figure 5.2). In addition to its sets of policies and constraints, Role A participates in both relationships R1 and R2. References to the relevant relationship objects will therefore be maintained in Role A. R2 is a relationship between roles A, B and C. It will therefore maintain references to those roles and a

87

Chapter 5


set of policies which belong to the relationship. Each policy in R2 is associated with the role whose Manager Position Domain (MPD) is the subject domain of the policy. Furthermore, policies within a relationship may have the related roles as target objects, e.g., authorisation to assign a task to a role. Therefore, substituting a role (e.g., B) with another role (e.g., D) in relationship R2, is a transactional operation which requires: 1. disabling relationship R2. This will disable and retract all policies defined in the relationship, 2. replacing the role reference in the relationship, 3. modifying the policies having role B as target to have role D as target, 4. removing R2 from the relationships of B. 5. adding R2 to the relationships of D, 6. enabling the relationship. This will distribute policies and load interaction protocol rules. A relationship object therefore follows an enabled↔disabled life-cycle and the relationship must be disabled before participants can be changed. R1 Role A

Role B

R2

Role C

Figure 5.2

Roles and relationships (brief example)

Both policies specified within R2 for role A and policies specified within role A, apply to the same objects, namely the URA included in the MPD of Role A. Whether a policy should be contained in a relationship in which the role participates or in the role itself is a design decision to be made by an administrator or policy-maker. In making this decision, two questions must be considered: “Does the existence of the policy depend on the existence of the relationship?” and “Is the policy dependent on other policies included in the relationship?” For example, an obligation on a service provider to deliver a monthly report to a customer depends on whether producing reports to customers is part of the organisational policies or is to be decided with each customer on a contractual basis. In addition to policies and interaction protocols, a relationship may contain concurrency constraints and Meta-Policies, which may refer to all the policies specified within the relationship.

88

Chapter 5


In R2 the expression Role-A:policy-2:enable() within a concurrency constraint refers to the enable activity specified within policy-2 and associated with Role-A. Grouping policies in relationships rather than roles may then be used to constrain concurrency of activities specified in policies which are to be implemented by managers assigned to different roles. Policies and interaction protocols inter-relate in further ways. On receipt of a message, the triggered interaction protocol rule may specify that an event is to be generated. This event can either be released to the monitoring system, trigger a policy contained in the role or relationship or both. Furthermore, a policy may specify that an interaction be initiated by using a pre-defined procedure in the User Role Agent to send a message. An abstract policy may also be implemented by an interaction protocol. For example, the policy: /* on a connection request the security manager must authenticate the user */ O+ on connection_req(connection_id) security_manager { /* authenticate */} /* user requesting connection */ may be implemented by an interaction protocol between the user and the security manager. Among the rules of the interaction protocol, the following may be specified for the security manager: /* These rules are triggered by the receipt of a message of type “id” sent by a user in response to a request_id message generated by the security manager. The guard is used to validate the id of the user. The variable m implicitly refers to the received message. */ request_id.id :: validate(m.contents.user_id) ⇒ event(accept_connection, m.contents.user_id, m.contents.connection_id) request_id.id :: invalid_user(m.contents.user_id) ⇒ event(fraudulent_usage(m.contents.user_id, m.contents.connection_id) The events accept_connection and fraudulent_usage may then trigger different policies of the security manager indicating the actions which must be taken in each specific case.

5.4.2 Determinism and non-determinism in Interaction Protocols Specification of interaction protocols must cater for both human and automated agents. The distinction between the two is made in terms of choice and determinism required in implementing the interaction protocols. Whether the manager assigned to the role is a human or an expert system capable of “reasoning” is irrelevant. What is relevant for interaction protocol specification, is whether this manager is able to choose between several alternatives or whether all actions must be deterministic, i.e., predefined choice. The ‘or’ operator was introduced in the specification of an interaction protocol rule in order to permit human managers to choose between alternatives. This operator may not be used for fully automated and deterministic agents as the specification is meant to be directly interpreted.

89

Chapter 5


The second restriction regards the enforcement of interaction protocol rules. When a message is received, regular expressions are matched against the type chain present in the incoming message. For all positive matches, the guards specified in the rules are evaluated. If a guard evaluates to true then the actions specified in the rest of the rule are executed. However, nothing can guarantee that regular expression matches and guard evaluations always offer mutually exclusive choices. Hence, multiple rules may be triggered by a message. According to the type of manager assigned to that role several possibilities exist: 1. All rules are executed (Minsky, 1997a). 2. The manager is offered a choice between rules. 3. One rule is executed, e.g., the first (deterministic choice). 4. The protocol specification is regarded as inconsistent. For automated managers one of the deterministic choices must be made (i.e., 1, 3 or 4) while option 2 can be chosen for managers able to make choices. The implementation described in the next sub-section detects multiple matches and can therefore implement either of them. To some extent, several matches may be regarded as an inconsistency since this does not appear in a network style specification diagram. On the other hand, several rules may be used to specify different alternatives or actions which must be performed in “any” case, e.g., any notification message must be acknowledged. Therefore, the choice between the alternatives mentioned above may be determined by the types of protocol specified within the management framework.

5.4.3 Implementation of the IPAgent The IPAgent ensures enforcement of interaction protocol rules for a participant in a relationship. It is a multithreaded process implemented in Java using OrbixWeb to interact with the role service. When sending a message to one or more of the related roles, a sender may not know, or be prevented from knowing, the object reference of the destination role(s). Therefore, the interface of the relationship object has been extended in order to allow a role to send messages through it. The role service which maintains the relationship object is assumed trusted and will check the validity of both sender and destinations, i.e., that the roles are part of the relationship. Note that the message refers to both sender and destination by their local names in the relationship. The role service can determine the User Role Agent (URA) included in the Manager Position Domain of the destination roles and deliver the message to the agent. However, this implementation may be error prone for several reasons, since the agent may be unreachable. Furthermore, the implementation of the URA has not been finalised, as an obligation policy interpreter is not yet available. We have therefore adopted an implementation, which is more expensive in terms of communication but offers more stability. Instead of delivering a message to

90

Chapter 5


the agent, it is delivered to the role object, which maintains a mailbox for all the messages. Since role objects are persistent, the state of the mailbox is preserved when the role service is interrupted. The IPAgent, which will ultimately be a component of the URA, receives the messages from the role. The following diagram briefly summarises the implementation and the invocation path between the various objects.

User Role Agent

ne xt _m es sa ge ()

Role A

ess _m ver deli

Relationship

Role B

() age

ip_rules

mailbox

IPAgent

Send message to B deliver_message(m) verify sender and destinations

Receive message

deliver_message(m)

oneway

next_message()

Load Rules

Figure 5.3

IPAgent Implementation

The IPAgent has a control thread responsible for receiving messages and adding, removing and replacing rules. When a new message is received, the control thread spawns a new thread to deal with that message. The message thread determines the matching rules, handles all interactions with the user, if choices between alternatives must be made, and performs all the actions specified in the rules. The IPAgent maintains a global table of interaction protocol rules supported. All the rules are parsed when loaded into the agent in a separate thread and all invocations specified in the rules are type-checked. The table therefore contains the abstract syntax tree generated from the parser. All invocations specified within rules are made using the CORBA dynamic invocation interface. Since the invocations have been type-checked at the time of parsing, no additional checks are made at invocation time, improving performance. Each object in the table is accessed in mutual exclusion by the control thread and the message threads. Having different threads for each message allows: •

handling other messages while waiting for a response from the user in case of choice

•

performing regular-expression matching and guard evaluation concurrently since these are computationally expensive.

91

Chapter 5


5.5 Chapter Summary and Future Work The management roles of an organisation are related to each other in many ways of which hierarchical structures and peer-to-peer collaborations are only two examples. A relationship may group two or more roles and specify the rights and duties of the related parties within its scope. Furthermore, managers acting in different roles interact with each other in order to achieve their tasks, share information and agree on their commitments. A large number of these interactions have been institutionalised and must take place according to pre-established rules, which limit the managers in terms of the message types they can exchange and leave no ambiguity about the outcome of an interaction. Much of the related work in this area is either limited to interactions between automated agents or geared towards the semantic (or illocutionary) value of the types of message exchanged. The first approach suffers from the following shortcomings: •

The interaction is programmed into the agent. It is therefore impossible to change an interaction protocol without interrupting the functioning of the agent

•

The agent is generally involved in one “interaction instance” at a time. The current state of the interaction therefore corresponds to the execution-state of the agents involved in the interaction process.

•

Agent behaviour is determined by the type of message received. In order to vary its behaviour according to past stages of the interaction the agent must modify its internal state to remember them.

•

The “program” of the interaction is deterministic and thus not applicable to human managers to which a limited freedom of choice must be offered.

We have introduced a notation for the specification of interaction protocols between the managers assigned to roles. This notation aims to regulate the exchange of messages and is therefore complementary to the studies on SpeechActs. An agent may comply with the protocol and applications using the interaction protocol may record commitments or beliefs about the state of the system in a knowledge base. The notation we have presented is rule-based in order to be able to change the protocol at run-time without needing to recompile agents. Initial rules may be derived from a higher-level graphical specification of message exchanges between interacting parties. The exchanged messages are typed; and types belong to a finite Universe of Discourse defined separately for each protocol. A message contains the type chain, i.e., the concatenation of all the types of the messages exchanged during the current interaction instance. The type of a message is therefore the last element of its type chain. Rules are triggered by matching regular expressions against the type chain contained in an incoming message. This triggering mechanism may be further refined by use of guards,

92

Chapter 5


which restrict the applicability of rules according to the contents of the message, sender or other information. Specifying the interaction protocol in this manner offers several advantages: •

The agent is able to handle several invocation instances.

•

Rules can be specified with regard to the history of the interaction, i.e., to previously exchanged message types and to the sequence in which they have been exchanged.

•

Rules can be added dynamically in order to refine a specification.

•

The scope of applicability of a rule may cover several protocol states.

The drawbacks of this specification style are that the context of any interaction instance must be fully retrieved from the contents of the exchanged message. This makes the use of the notation more difficult for ‘programming’ agents. Rules can specify what message or message types must be sent and what actions must be performed on objects of the system. This is consistent with the level of abstraction at which policies are specified. Actions can be grouped in sequences or in alternatives. The manager assigned to a role must then be prompted to choose between the alternatives. This allows us to specify constrained choice for human managers. A particular type of action allows generating events, which can trigger policies specified in the role or in the relationship. Also, interactions may be initiated by the enforcement of a policy, which contains a send-message activity. The actions specified in the interaction protocol rules presented in this chapter have been limited. In particular, no control structures such as if-then-else clauses have been included. This is because interaction protocol rules are used only in order to control the exchange of messages and initiate activities (just as policies are used to control management strategy). A protocol-based specification can be rendered deterministic for use with fully automated agents by preventing the use of the ‘or’ operator in the rules and deciding on a heuristic for the rules, i.e., if several rules are triggered by an incoming message either all of them are executed or only one of them is (e.g., the first). Support for interaction protocols has been implemented in an IPAgent. The agent’s multithreaded implementation ensures that protocol rules are parsed and type-checked independently of their implementation, and rules which require user input (e.g., for making choices) are handled by concurrent threads. Further work remains to be done in this area. In particular, it is desirable to be able to check that certain properties are verified by a protocol specification, e.g., that the protocol terminates (no looping). Support for dynamical extension capabilities (e.g., answer field) require further study. A minimal amount of implementation also remains to be done in order to include the IPAgent in the User Role Agent when an implementation of the obligation policy interpreter is available.

93

Chapter 5


Although much emphasis has been placed on interaction protocol specification there are other advantages in specifying relationships. In particular, since relationships group policies pertaining to different role participants, concurrency constraints and Meta-policies can be specified in a relationship to coordinate the actions of different managers assigned to those roles. Furthermore, relationships can be used as unitary groups of policies: deleting a relationship will remove all policies specified in that relationship and replacing a role in a relationship (and implicitly adding the relationship to the role) will subject the manager assigned to that role to all the duties and rights regarding his part in the relationship.

94

Chapter 6 Object-Oriented Extensions

In previous chapters, we have defined a model for roles and relationships based on the definition and specification of management policies and interaction protocols. However, an organisation may contain large numbers of roles with few differences between them. For example, a hospital may have different nurses, assigned to different wards and caring for different patients. Although the nurses have similar rights and duties in all wards, the target objects of their activities i.e., the patients, are different. Therefore, the policies composing their respective roles will also be different, even if the actions and constraints specified in the policies remain unchanged. In order to reuse parts of the specification of a role, it would be useful to define role classes parameterised by specific target domains from which instances could be created. Nurse-instance roles could then be created for different wards from the same nurse role-class specification. Each instance may be customised for a particular task relating to a specific ward and a specific person may be assigned to each role. This chapter will introduce such object-oriented extensions to the specification of roles and relationships. These extensions are based on the definition of policy templates from which policy objects are instantiated. After defining policy templates, later sections of this chapter will be devoted to the specification of role classes, implementation of inheritance between role classes and specification of relationship classes.

6.1 Policy Templates Management policies are composed of a set of attributes, some of which may vary according to the domain of application, i.e., the objects to which the policy applies. Among the set of attributes of a policy, the actions and constraint are strongly related and cannot be dissociated. They specify which actions must be performed, which actions are permitted and under which circumstances. Therefore, these attributes are dependent on the types of target objects to which they apply (and types of triggering event for obligation policies) but do not depend on the actual object-instances. Hence, policy actions, constraints and exception can be grouped in a policy template

95

Chapter 6

Object-Oriented Extensions

parameterised by different subject and target domains. For example, in a hospital, a policy template such as the one below may be specified (S and T represent variables). /* subjects are authorised to administer analgesics when the temperature of the target is between 37 and 38.5 */ A+ S { administer(analgesics) } x:T when (x.temp > 37) && (x.temp < 38.5) The following policy authorising a nurse to administer analgesics to lung-disease patients may then be created from the template above by assigning values to S and T. A+ @/ward1/nurses { administer(analgesics) } x:@ward1/patients/lung-diseases when (x.temp > 37) && (x.temp < 38.5) Two variations of this policy template/instance definition can be used. For example, the previous template could be written as: A+ @S/nurses { administer(analgesics) } x:@S/patients/lung-diseases when (x.temp > 37) && (x.temp < 38.5) This template can then be instantiated for nurses in ward one by instantiating S to the appropriate value, i.e. “ward1”. This variation has also been explored in (Marriott, 1997). A second variation allows restricting instantiation by type compatibility and specifies in the template the required type of the subjects and targets. The actions specified in a concrete (implementable) policy can be of two kinds: (1) methods defined on target objects and (2) procedures defined in the obligation policy interpreter (for obligation policies). These actions must be defined either in the interface of managed objects or in the internal interface of the obligation policy interpreter. In the latter case, it is assumed that the different agents implementing obligation policies will be dedicated agents, e.g., for configuration management, security management, etc. The interfaces can be implemented as objects registered in the domain structure and available from a dedicated server, e.g., CORBA Interface Repository. While parameterising a policy template with the subject and target domain, type compatibility can be maintained by referring to the types or interface objects of subjects and targets. The previous template would then be written as: A+ type /types/nurses { administer(analgesics) } type /types/lung-diseasepatients when (x.temp > 37) && (x.temp < 38.5) When this policy template is instantiated, subject and target domains must be specified and type compliance can be checked. However, type issues have been ignored in the current semantics of the policy notation (Marriott, 1997). Triggers of positive obligation policies can be of two kinds: (1) internal events based on time (e.g., every 5min) or (2) events detected by the monitoring system. When a positive obligation policy is triggered by an internal event based on time (1), the trigger is specified in the policy

96

Chapter 6


template (since it will be the same for all the policy instances created from that template). In the current policy notation, the second kind of trigger is specified by the path in the domain structure to an event disseminator notifying the occurrences of that event. Although events triggering positive obligation policies created from the same template will be of the same type, the event disseminators themselves will nevertheless be different. For example, nurses on duty in wards 5 and 6 administer analgesics to patients in their respective wards when the patients’ temperature becomes greater than 37°C. But the components monitoring the occurrences of these events may be different in ward 5 and ward 6. Hence, the event disseminator to which the nurse agent subscribes must be different in the two wards. Therefore, triggers can be specified as template parameters of positive obligation policies. However, it would be an improper use of the policy notation to instantiate multiple positive obligation policies from a template where only the event is to be specified. This is because the instantiated policies (e.g., p1, p2, p3) would be equivalent to a single policy triggered by a composite event defined as the logical ‘or’ of the events triggering the instantiated policies e.g. (“p1.trigger | p2.trigger | p3.trigger”). Since type issues have been ignored in the current policy notation (Marriott, 1997), we also ignore them, to some extent, for policy templates. Therefore, in the remainder of this thesis, we specify subjects and targets in policy templates by variables (e.g., S and T in the examples above). Furthermore, we specify events in both policies and policy templates by an abstract description of the event, e.g., temperature_too_high(patient_id, bed_number). A policy template may not inherit from another since the components of a template (trigger, actions, condition, exception) are closely related and cannot be combined under inheritance. Each policy maintains a reference to the template from which it was created, in addition to the references maintained to the policies from which it was refined. As roles have been defined as groups of policies having the same subject domain, role classes will be defined as groups of policy templates. When a policy template belonging to a role class is instantiated, only the target must be specified, since the subject is determined by the MPD of the role instance created. Similarly on instantiation of a relationship class, the subject of a policy is the MPD of the role with which it is associated (Section 6.4). Policy templates may also be specified outside role and relationship classes. Instances created from these templates will apply to groups of managers in the organisation, e.g., departments, teams, etc. Policy templates are implemented as objects and maintained by the policy service. Therefore, role and relationship classes only group references to the policy template objects.

97

Chapter 6


6.2 Role Classes A role class groups specifications of policy templates defining the rights and duties of a generic role in the organisation, e.g., nurse, engineer, marketing manager. The role class does not apply to any particular position in the organisation and therefore does not have a manager position domain (MPD). When a role is created, an MPD will be specified for each created role instance. Therefore, a manager cannot be assigned to a role class, only to a role instance and a role class contains only policy templates, not instances. Policy templates may however have a defined or undefined target. Consider the example of the nurse role class, containing a set of policy templates, which may have some undefined targets. The nurse class may contain the following templates: /* the nurse is authorised to access the drugs database */ pt_1 A+ D { read(), search(), update() } @/software/databases/drugs_db /* nurses must monitor their patients */ pt_2 O+ D { monitor() } P When the role is instantiated, the MPD can be assigned to the variable D of template pt_1, which is then fully specified as the same target is used for all nurse instances. However, pt_2 additionally requires a target domain – representing the specific patients for which the nurse instance is responsible – to be assigned to variable P. Note that instead of specifying the pt_1 policy template, a global policy instance (which is not part of the role) with a subject referencing a domain containing all instances of the nurse role, could have been specified. The disadvantage of this approach is that the system must be constrained to include every nurse role in a given domain, which is very difficult to implement and to check. The implementation of a role class is similar to that of a role. References to policy templates are stored in a table where each reference is associated with a name unique within the role class. In addition to policy templates, a role class can include a set of constraints (both concurrency constraints and meta-policies) and a set of references to relationship classes (Figure 6.1). All constraints refer to policy templates by their local name within the role class. If multiple instances of a particular policy template are required in a role, then the role class must specify a different local name for each policy template reference. This situation can occur only for positive obligation policies created from the same template, in which both trigger and target domain differ. In all other cases, targets of policies created from the same template can be composed into a single domain scope expression, e.g., domain_A + domain_B - domain_C. For positive obligation policies created from the same template, and with the same target domains, events can be aggregated in the monitoring sub-system.

98

Chapter 6

Object-Oriented Extensions name

policy template object reference

name

relationship class object reference

name

expression

name

expression

Role Class MPD (description) policy templates relationship classes concurrency constraints Meta-Policies

Figure 6.1

Outline of a role class implementation

Concurrency constraints only reference activities within a policy, so they can apply to either policy objects or templates. Consider the following policy templates. /* the nurse must administer analgesics when the temperature of the target is > 37 */ pt_3 O+ on x.temperature > 37 D { administer(analgesics) } x:T /* the nurse must update the database when drugs have been administered */ pt_4 O+ on administer_drugs D { update } /software/databases/drugs_db The following constraint ensures that the drugs database is updated after drugs have been administered. c_1 pt_3:administer(analgesics) ; pt_4:update As constraints apply equally to policy templates or instances, they need not be instantiated when a role instance is created from a class. Therefore, not only does the process of instantiating roles from classes become simpler but the size and complexity of role instance objects is also greatly reduced. When specified in a role class, Meta-Policies can express constraints that must be satisfied during the instantiation process, e.g., nurses can monitor at most 10 patients. Finally, a role class may reference relationship classes (defined as described in Section 6.4). A reference to a relationship class specifies that an instance of the role class cannot be created without binding the role instance in a relationship of the specified class. For example, a nurse role may not be created without creating a relationship with a head of ward role. Note that only required relationships must be specified. Additional relationships, for example with the physicians, may be added later. The relationship classes can contain both role instances and role classes. Therefore it is possible to specify that a nurse must relate to a head of ward, which is

99

Chapter 6


different in each ward, but also that the nurse must participate in a relationship with a head of personnel role instance, which is unique within the hospital. An instance of a role class can be created by: •

creating an instance of each policy template included in the relationship,

•

instantiating a relationship for every reference to a relationship class,

•

assigning a manager position domain.

Once created, the role instance can be further specialised, for example by adding policies, relationships or constraints.

6.3 Inheritance As well as re-using role specifications by instantiation from common classes, the role object model allows reuse of specifications by inheritance between classes, permitting incremental specification and extension of the organisational structure. Single inheritance implements a specialisation of role classes. For example, a role class can be specified for a specialised nurse or a paediatric nurse, which inherit from the nurse role class (Figure 6.2). New rights and duties can then be specified for the specialised nurse that do not apply for the nurse. Furthermore, a sub-class must be able to override or cancel policy templates of a super-class, e.g., a specialised nurse may not have a duty to monitor all patients but deal only with specific cases (Figure 6.2 − policy pt_2). Single inheritance between role classes can be implemented by maintaining a reference to the super-class object. All templates, constraints and relationships are inherited from the super-class and we extend the requirements on local names (of policy templates, constraints, etc.) as follows: •

The local name of a policy template, constraint or relationship must be unique within a class hierarchy, i.e., within the class and the super-classes for objects of the same type.

•

If an element is specified in a sub-class with the same local name (label) as in a super-class, it overrides the element defined in the super-class. Note that the naming scope is different for each object type; therefore, a policy template can only override other policy templates.

100

Chapter 6


pt_1 ref. pt_2 ref.

nurse generic-childcare policies

policies

pt_2

pt_2 /* */ Overriding with single inheritance

specialisednurse policies

ref.

paediatric-nurse policies

Overriding policies with multiple inheritance

nurse.pt_2 surgical-nurse

Figure 6.2

generic_childcare.pt_2

Role class inheritance graph

Furthermore, we will extend the definition of concurrency constraints in order to allow a constraint to extend constraints defined in super-classes. For example, consider the role class of a nurse defined as follows: Role Class nurse { Policy templates pt_3 O+ on x.temperature > 37 MPD { administer(analgesics) } x:T pt_4 O+ on administer_drugs MPD { update } /drugs_db Concurrency constraints c_1 pt_3:administer(analgesics) ; pt_4:update } A specialised nurse (e.g., gastroenterology) may have an additional obligation to revise the dietary requirements of patients when there is any change in their temperature. Furthermore, after each update to the drugs database the nurse must check remaining availability. Let us consider that the concurrency constraint must be updated to specify that the current constraint sequence can be performed concurrently with the revision of dietary requirements, although this would not be normally specified. The specialised nurse sub-class can then be specified as follows: Role Class specialised_nurse { inherits from: nurse Policy templates pt_4 O+ on administer_drugs MPD { update ; check_availability } /drugsdb pt_5 O+ on temperature_change MPD { revise_diet } T Concurrency constraints: c_1 pt_5:revise_diet || c_1 }

101

Chapter 6


Policy template pt_4 is overridden in the sub-class. Furthermore, the overridden concurrency constraint c_1 extends the concurrency constraint specified in the super-class. Note that a concurrency constraint can be extended in a sub-class only if it is overridden. The reason for this is that concurrency constraints cannot normally be composed (contrary to process models specifications). Consider for example, two concurrency constraints c1 and c2. Then any constraint expressed as a combination of c1 and c2 (e.g., c1 ; c2), is a stronger constraint then both c1 and c2. Therefore, c1 and c2 assume only a declarative value and the enforcement of c1 ; c2 enforces both c1 and c2. Concurrency constraints are evaluated in the namespace of a sub-class, so policy names will be replaced with local references overriding inherited ones. However, overriding policy templates may introduce inconsistencies if the new policy does not contain the actions referred to by the concurrency constraints. These inconsistencies can be detected by an automated process of the role editor but changes to concurrency constraints must be performed manually. Composing role classes by multiple inheritance may also be a desirable feature. For example, a paediatric-nurse can inherit rights and duties from a nurse role class and a generic-childcare role class (Figure 6.2). However, multiple inheritance introduces problems arising from multiple super-classes having policies with the same name. For example, in Figure 6.2, both nurse and generic-childcare role classes define a policy template with the name pt_2. A standard solution is to unify name-spaces in the sub-class and assign an implicit precedence order to the superclasses (e.g., the textual order in the class inheritance list). It is then possible to override unified policy names with new ones defined in the sub-class, as for single inheritance. However, since inheritance is intended as an is-a relationship (i.e., specialisation) multiple inheritance is implemented by combining specifications of the super-classes rather then having policies with the same name override each other. In this case, the name-spaces of the super-classes are kept disjoint. Referring to an inherited policy template – whether to override it or within a new concurrency constraint – must then be done by prefixing the name of the template with the name of the super-class from which it was inherited, e.g. nurse.pt_2 (Figure 6.2). Inherited concurrency constraints must be evaluated in the context of the class from which they are inherited plus all overridden policy templates. Super-classes also maintain references to the sub-classes that inherit from them and classes maintain references to the objects that have been instantiated from them. This allows defining skills as in (Skarmeas, 1995). Skills may be associated with roles outlining their basic capabilities and a trader service used to locate roles with specific skills. It is thus possible for the trader to browse the inheritance graph and determine the roles that have for example, the skills of a nurse.

102

Chapter 6


Such a service is not currently implemented but may be added at a later stage as a separate service in the framework. A class may not be changed once sub-classes or instances have been created from it. This constraint may however be relaxed in future and changes propagated to sub-classes and instances. This is possible because references to sub-classes and instances are maintained as described above. However, changing a class requires verifying the consistency in all subclasses and instances before the change can be validated. This matter requires further study.

6.4 Relationship Classes A relationship class allows creation of multiple relationship instances between roles of given types. For example, every nurse must relate to a head of ward. Therefore, a relationship class between two related roles of types “nurse” and “head of ward” can be defined and instantiated for every nurse in the hospital. Thus, a relationship class is parameterised with the participants in the relationship instances. A relationship class nevertheless specifies the types of the roles, i.e., the classes from which participant roles must be instantiated. Note, that not all participants in a relationship class must be parameters of that class. For example, all nurses in a hospital relate to a head of personnel, which is a unique role instance in the hospital. The corresponding class for these relationships has a fixed participant, the head of personnel role instance, and a parameterised participant that must be an instance of the nurse role-class. A relationship class contains a set of policy templates pertaining to either role instances or role classes. Furthermore, a relationship may specify constraints and interaction protocols. In summary, a relationship class is composed of: •

a set of participants which can be either role instances or placeholders of a given role class,

•

a set of policy templates where each template is associated with a role class or a role instance,

•

a set of interaction protocols where each protocol is composed of a set of rules and each rule pertains to one of the participants in the relationship,

•

a set of constraints (both concurrency constraints and Meta-Policies) applying to the policy templates specified within the relationship class.

Although a relationship class can have role instance participants, it cannot have policy instances. This is because references to these policies would be included in all instances of the relationship class resulting in redundant specifications. A relationship class is instantiated by specifying its participant roles and creating policy instances for every template in the relationship. Some policy templates in a relationship class specify the rights and duties of participant roles vis-à-vis each other. For example, a head of ward may have

103

Chapter 6


an obligation to revise the duties of the nurse every month. In such cases, both subject and target of the policy template are participants in the relationship. Therefore, they can be specified with the local names of the participants in the relationship and the policy template can be automatically instantiated when an instance of the relationship is created. Also, as mentioned in the previous chapter, a policy may specify that a message be sent to a related role, thus initiating an interaction. Since, in the current implementation of the interaction protocols, messages are sent through the relationship (Section 5.4.3), the policy instance will have a relationship object as target. In the relationship class, the corresponding policy template will therefore have as target the keyword ‘this’, permitting automated creation of the policy instance on instantiation of the relationship. Consider for example a relationship class between a nurse role class, a physician role class and a head of ward role (Example 4 below). The role and role classes are given the local names R1, R2 and R3 respectively. The relationship class contains policy templates obliging the nurse to report every day to head of ward (np1). The physician has the obligation to specify treatments for patients (pp1) and the head of ward is responsible for assigning duties to the nurse, scheduling the activities and checking the availability of drugs (hp1, hp2, hp3). Furthermore, an interaction protocol is provided enabling the doctor to request that a special treatment be performed (ip1). The request has to be sent to the head of ward, which can decide to reject it or to assign a nurse (ip2). The reply must then be sent to both nurse and physician. The nurse must notify both physician and head of ward (ip3) when the treatment has been completed. c_1 constrains the head of ward to assign duties only after: the care treatment has been specified by the physician, a schedule has been elaborated and drugs have been ordered.

Example 4 Nurse-Physician-Head of Ward Relationship R1: nurse (role class)

R2: physician (role class) R3: head of ward (role)

Policies np1: O+ every [1*day] s:mpd { report(s.name) } R3

pp1: O+ every [1*day] mpd { revise_medication() } /* patients */

hp1: O+ every [1*day] mpd { assign_duties(/* duties */)} R1 hp2: O+ every [1*day] mpd { set_schedule(/* activities */} R1 hp3: O+ every [1*day] mpd {check_availability()} /* list of drugs kept in the local ward*/

Interaction protocols e.g. special treatment ip3: *.assign ⇒ [confirm, ...] → R2, R3

ip1: [request, ...] → R3

ip2: request ⇒ [reject,...] → R2 or [assign, ...] → R1, R2

Concurrency constraints c_1: R2:p1:revise_medication ; {R3:p2:set_schedule & R3:p3:check_availability } ; R3:p1:assign_duties

104

Chapter 6


Single inheritance and overloading occur for relationship classes in a similar manner to role classes. For example, the relationship between surgical nurse and surgeon may inherit from the relationship between specialised nurse and doctor and add special interaction protocols for urgent interventions (Figure 6.3). specialised nurse

doctor

relationship 1

surgical nurse

surgeon

relationship 2

Figure 6.3

Role and relationship inheritance

Overloading of a role or role class in a relationship is restricted to one of the sub-classes of the roles in the relationship super-class. For example, relationship2 in Figure 6.3 could have been between a surgeon and a specialised nurse but not between a surgeon and a nurse of any other role class not a sub-class of specialised nurse. In this respect, the role class hierarchy implements a type/sub-type mechanism for relationship classes. Multiple inheritance is not allowed because direct combination of two relationships by inheritance is undefined.

6.5 Tool support Role and relationship class objects are maintained by the role service and tool support for specifying role and relationship classes has been added to the role editor. The attributes of a relationship class specific to each participant, namely the interaction protocols and policy templates, can be visualised and specified in different windows for each role or role class of the relationship. Figure 6.4 shows the interaction protocols and policies associated with the role classes Nurse and Head of Ward in a relationship class. An object browser displaying the various relationships between objects and classes has also been implemented. The user can choose the relationships he wishes to see, from a menu, and the graph is regenerated. For example, consider a ward with two nurses (nurse1 and nurse2) and a head of ward (HoW). One of the nurses (nurse2) is a specialised nurse, which is a sub-class of the nurse role class. A relationship class nurse-HoW is defined and two instances (rel1 and rel2) are

105

Chapter 6


created from it between nurse1 and HoW and nurse2 and HoW respectively. Figure 6.5 shows the relationships between the various class and instance objects. This graph can be simplified to display only inheritance and instantiation relationships, as shown in Figure 6.6.

Relationship Class

Nurse - Head of Ward

Interaction Protocol Rules for the Head of Ward

Interaction Protocol Rules for the Nurse

Policies associated with the Head of Ward

Policies associated with the Nurse

Figure 6.4

Figure 6.5 Role objects

Relationship Class Specification

Figure 6.6 Inheritance and Instantiation

106

Chapter 6


6.6 Chapter Summary Management of large distributed systems requires a large number of roles, which may have multiple relationships between them. Yet many of these roles are organised in patterns that are repeated, with few differences between them, throughout the organisation. For example, in a hospital, the pattern of nurses, head of ward and caring physician(s) is repeated in all its different wards. Providing the means of defining templates and classes for policies, roles and relationships enables reuse of specifications. Furthermore, the specification process itself is greatly simplified since context-dependent details such as domain structure and grouping of managed objects are abstracted at class specification level. The emphasis of the design process is shifted towards the types of roles involved and their inter-relationships. As well as allowing specification reuse through multiple instantiation, the role-based framework allows reuse of specifications by inheritance. A role class can thus be specialised with particular rights and duties requiring greater skill from the managers appointed to them. This enables incremental refinement of the organisational structure for specific management needs. Since relationship classes refer to the types of participants (i.e. role classes) and since role classes refer to the types of the relationships in which they are bound, the integrity and consistency of the organisational pattern can be preserved when instances are created. Constraints (concurrency constraints and Meta-Policies) can be defined at class level and do not need to be instantiated. In addition to further simplifying the specification process, this also improves performance by reducing amount of data that needs to be stored within a role or a relationship instance. To summarise, the advantages of providing object-oriented extensions to the role and relationship specification are: •

reuse of specification through multiple-instantiation and inheritance between classes,

•

simplified specification by abstracting domain specific information such as domain structure and identity of subjects and targets,

•

specification of constraints at the class level offering the advantages of a simpler and more centralised approach to constraint specification, and improved performance by reducing the size and complexity of instance objects,

•

consistency of the instantiation process and preservation of the organisational pattern by using role and relationship classes as types in their mutual references.

These advantages will be further exemplified in applying the concepts of the framework to a case study (Chapter 8). However, the issues regarding the consistency of a role specification in terms of conflicts that may arise between different policies need to be addressed. This will be the subject of the next chapter.

107

Chapter 7 Conflict Analysis

Whenever multiple policies apply to the same objects, conflicts can arise in the set of policies. For example an obligation policy may define an activity which is forbidden by a negative authorisation policy; two authorisation policies may permit and forbid an activity; or two policies permitting a manager to sign checks and approve payments, may conflict with an external principle of separation of duties. Inconsistencies may also arise during the refinement process, between high level goals and implementable policies. The system may have to cater for conflicts such as exceptions to normal authorisation policies. This chapter reviews policy conflicts and inconsistencies, focusing on the problems of conflict detection and resolution. We discuss various techniques and precedence relationships that can be established between policies in order to allow inconsistent policies to co-exist within a system and present a conflict analysis tool, which forms part of the Role-Based Management framework. Roles and relationships are the primary scope for detecting conflicts since they define sets of policies that must be consistent. However, policies defined within a role may also conflict with more general policies specified for a group of roles, e.g., team, project department. Therefore, we will review conflicts between management policies in general.

7.1 Introduction In a large distributed system there will be multiple human managers specifying policies which are stored on distributed policy servers. Policy inconsistencies can arise due to omissions, errors or conflicting requirements of the managers specifying the policies. For example, an obligation policy may define an activity a manager must perform but there is no authorisation policy to permit the manager to perform the activity. Conflicts can also arise between positive and negative policies applying to the same objects. In general, whenever multiple policies apply to an object there is a potential for some form of conflict, but it is essential that multiple policies should apply in order to cover the diversity of management functions and of management domains. There may

108

Chapter 7

Conflict Analysis

be different policies relating to security, monitoring, or configuration, which apply to a set of objects reflecting different management functions that may be performed on the objects. Similarly, the policies specified for a network, sub-network and workstation domains will all propagate to the network objects inside a workstation. Many policies specified for the management of a large system specify exceptions to more general policies. System administrators are typically permitted to reboot computer systems while ordinary users are prohibited from performing such actions. It is not always desirable to eliminate such conflicts by rewriting policies or changing the membership of the domains to which policies apply. As automated managers cannot enforce conflicting policies, a precedence relationship must be established between the policies in order to resolve conflicts. In order to detect all conflicts it is necessary to check all policies in the system. However, roles and relationships can be used to determine, and then progressively extend, the scope of the conflict search. For example, an administrator or policy-maker can check for conflict for the policies of a role, then the search can be expanded to the relationships and related roles, and further to the groups in which the role is a member e.g. section, department, etc. Section 7.2 discusses the types of inconsistency and the policy conflicts that we must detect. Section 7.3 explains our approach to conflict detection, policy precedence relationship and describe the tools we have implemented. Section 7.4 discusses issues related to Meta-Policy specification and Section 7.5 briefly surveys related work in this area and situates the work described in this chapter within that context.

7.2 Conflicts 7.2.1 Some Examples A service provider offers its users access to a travel-booking agent. Access is regulated according to the type of the users (private clients, corporate, etc.) and the area from which users access the service. For example: /* Users accessing from a Network Access Point in Wales are not allowed to access the service */ A- @/users_by_NAP/Wales { browse(); purchase() } /services/Travel_book /* All corporate users are allowed to access the service */ A+ @/corporate_users { browse(); purchase() } /services/Travel_book An obvious conflict occurs when a corporate user accesses services from Wales, in which case access cannot be decided without giving precedence to one of the policies over the other.

109

Chapter 7

Conflict Analysis

Consider now the policies regulating medication of patients in a hospital. An initial abstract policy can be written as: /* Nurses are responsible for administering medication to patients */ h1 O+ /* nurses */ { /* administer medication */ } /* patients */ child h2, h3, … This policy is further refined to a set of policies specifying which drugs must be administered and which additional actions taken. /* Administer analgesics when temperature is too high */ h2 O+ on too_high_temperature(patient) /nurses { administer(analgesics) } u:@/patients when u==patient parent h1, xref authorisation h3 /* Nurses are authorised to administer analgesics */ h3 A+ @/nurses { administer(analgesics) } @/patients parent h1 /* Nurses must log their handling of drugs */ h4 O+ on drugs_administered @/nurses { update() } /drugs_db parent h1 Note that, at this point, there is no authorisation giving nurses access to the database. If the administrator omits to specify such a policy, wrongly assuming it may have been specified in the general access control policies, the unauthorised obligations should be detected. Further, if such an authorisation does exist, policy h4 may conflict with the following policy: /* Every night drug stock-levels must be checked and new drugs ordered */ h5 O+ at 1:00 am /agents/stock_taker { check_stock(); generate_order() } /drugs_db The conflict is due to the fact that no updates can be performed on the database while stock levels are being checked.

7.2.2 Conflict classification Modality conflicts are inconsistencies in policy specification which may arise when two or more policies with modalities of opposite sign refer to the same subjects, actions and targets. This occurs when there is a triple overlap between the sets of subjects, targets and actions as shown in Figure 7.1, and so can be determined by syntactic analysis of polices. There are three types of modality conflict: •

O+/O- the subjects are both required to, and required not to, perform the same actions on the target objects.

•

A+/A- the subjects are both authorised and forbidden to perform the actions on the target objects.

110

Chapter 7 •

Conflict Analysis

O+/A- the subjects are required but forbidden to perform the actions on the target objects (obligation does not imply authorisation in our case).

O-/A+ is not a conflict, but may occur when managers must refrain from performing certain actions as specified by a negative obligation, but the actions can nevertheless be authorised. Authorisation policies protect a target from unauthorised action by the subjects. However, there are cases in which a target object may not wish to be protected, e.g., students wanting to know results of their examination early. A negative obligation policy that acts as a filter on the subject is then needed, to specify that subjects must “refrain from” performing the activity, e.g., examiners must not disclose the results before a certain date. A second type of conflict refers to the consistency between what is contained in the policies (i.e., which subjects, targets and actions are involved) and external criteria such as limited resources or the overall policies of the organisation. An example of this type of conflict arises from the principle of separation of duties (Clark 1987), e.g., the same managers cannot authorise payments and sign payment checks. These conflicts are application-specific and cannot be determined directly from policy specifications – additional information is needed to specify the conditions that result in conflict. These can be specified as a Meta-policy, i.e., a policy about permitted policies. Several types of application-specific conflicts such as conflict of priorities for resources, conflict of duties, conflict of interests, multiple-managers conflict and self-management conflict have been identified (Moffett 1994) and classified according to the overlaps between subject, action and target sets. These will be described further (Section 7.4). Modality conflicts arise from overlapping domains but it is impractical to prevent these overlaps (see 7.3.1) as there is a need for multiple policies to apply to a domain to reflect partitioned responsibility and the diversity of management functions that can be performed on target objects, e.g., different managers may be responsible for maintenance and security relating to a domain of workstations. In the following, we discuss precedence relationships which can help to resolve modality conflicts and then describe an approach to specifying meta-policies to detect applicationspecific conflicts.

7.3 Conflict Detection Conflict detection between management policies can be performed either statically on a set of policies in a policy server, or at run-time. A run-time mechanism acts as a filter preventing activities that must not be performed (O-) or are not permitted (A-) (Moffett 1993). The advantage is that all the constraints of the policies can be evaluated at run-time and so all conflicts can be detected, but some conflicts may really be specification errors and should rather be detected by

111

Chapter 7

Conflict Analysis

static analysis (cf. compile time vs. run-time error detection for programming languages). The disadvantages of static analysis are that policy constraints cannot be evaluated, as they depend on run-time state, and domain membership may change, so only potential rather than actual conflicts can be detected. Both static and run-time conflict detection are needed, but the work described in this thesis concentrates on a static conflict detection tool which assists users specifying policies, roles and relationships.

7.3.1 Policy Precedence Relationships As previously mentioned, modality conflicts result from a triple overlap between the subjects, actions and targets of the policies. In a typical organisation there will be general policies pertaining to all staff as well as specific policies relating to staff in a department or section. Staff may also be members of many different domains. Detecting triple overlaps between policies with modalities of opposite signs would therefore detect many potential conflicts that do not result in actual conflicts. Consider for example the following policies: /* All users are forbidden to reboot workstations */ W1 A- @/users { reboot() } @/workstations /* The system administrators are authorized to reboot the workstations */ W2 A+ @/users/sys_admin { reboot() } @/workstations To resolve this conflict it is necessary either to change policy W1 or to exclude system administrators from the /users domain. Changing a policy is a lengthy operation, which requires retracting it from all the agents editing and redistributing it to all the agents. Furthermore, authorisation to reboot a particular workstation may also be granted to a student engaged in an operating systems project, or testers of new hardware configurations. So re-writing a policy may be neither convenient nor desirable in the general case. Removing system administrators from the users domain is not a desirable alternative either, since this means withdrawing them from all other policies specified in terms of the users domain. We must therefore allow the two policies to co-exist within the system and determine which policies should apply for each manager (or set of managers), and which policies should be ignored (e.g., W1 for system administrators in the case above). Using a policy precedence relationship can substantially reduce the number of conflicts between policies and permit apparently inconsistent specifications. There are several principles, outlined below, for establishing precedence. The choice between them must be guided by which conflicts should be ignored and how easy it is for a human user to understand the decisions and selection of the conflict detection tool using this principle, i.e., how intuitive the principle is.

112

Chapter 7

Conflict Analysis

Negative policies always have priority It is quite common for negative authorisation policies always to override positive ones so that a forbidden action will never be permitted. However, in the example above, this implies that policy W1, being negative, has priority over W2 so that system administrators are denied access to the system files; but then, they cannot perform their function. Precedence based on modality (i.e., negative policies take precedence over positive ones or vice-versa) allows conflicting policies to co-exist but resolves all conflicts in a deterministic but inflexible way. For example, the following policy may be added to the policies W1 and W2 above: /* Junior employees are not allowed to reboot workstations providing persistent services */ W3 A- @/employees/junior_employees { reboot() } @/workstations/persistent_service A user can be at the same time a junior employee and system administrator. Therefore, if positive policies override negatives, then junior system administrators will be allowed to reboot all workstations according to W2. If on the other hand, negative policies take precedence over positive ones, no system administrator can reboot a workstation according to W1. Some flexibility may be introduced by adopting a default policy such as: everything is implicitly forbidden or everything is implicitly authorised, and defining precedence between explicit authorisation, explicit denial, implicit authorisation or implicit denial (Minsky, 1996). A default negative authorisation policy would mean that policy W1 above would not need to be specified, and so would eliminate some conflicts, but does not really solve the problem. The same situation may arise for sub-domains of the sys_admin domain – network administrators are not allowed to reboot workstations but a subset of them must be able to reboot workstations providing naming services such as DNS.

Assigning explicit priorities A user can assign explicit priority values to policies to define a precedence order, but meaningful priorities are notoriously difficult for users to assign and may result in arbitrary priorities which do not really relate to a policy’s importance. Inconsistent priorities could easily arise in a distributed system with several people responsible for specifying policies and assigning priorities.

Distance between a policy and the managed objects The concept of calculating the distance between a rule (policy) and the objects to which it refers, has been introduced in (Larrondo-Petrie, 1990) for authorization policies in an object-oriented database. Priority is given to the policy applying to the closest class in the inheritance hierarchy when evaluating access to an object referenced in a query. Consider a foreign student class to be a sub-class of student, which is a sub-class of person. Then an access policy applying to a foreign

113

Chapter 7

Conflict Analysis

student overrides the general access policy applying to a person. The distance between the policy and the (class of) objects to which it applies indicates the relevance of the policy to those objects. For example, more recent policies are often more relevant then older ones and health-care policies in a hospital often take precedence over confidentiality ones. In general, there is a compromise between the complexity and intuitiveness of the distance to be evaluated. A distance that is intuitive may not correctly value the importance of a policy in all the cases. However, a complex calculated distance may not be intuitive enough for a human user to understand the priorities assigned to a policy during conflict detection. For example, the priority could be based on a function of the policy’s refinement level, last modification date and author.

Domain nesting precedence (“specificity principle”) The principle here is that a more specific policy, (i.e., a policy applying to a sub-domain) refers to fewer objects, so overrides more general policies applying to an ancestor domain. This concept was introduced in Miró (Heydon, 1990) and is a particular case of the previous concept of distance. Considering the “specificity” of a policy with regard to the objects to which it applies, is an intuitive concept in a domain-based system. A sub-domain of objects is created for a specific management purpose – to specify a policy that differs from those applying to objects in a parent domain. The system administrators in policy W2 above are a sub-domain of users, so W2 has precedence over W1 which prohibits users from having access to system files, but other policies applying to all users still apply to system administrators. Similarly a policy specified with regard to a subset of target objects (e.g., workstations maintaining persistent services), should take precedence over policies relating to workstations in general. Precedence based on domain nesting can thus be used to allow conflicting specifications by automatically resolving some conflicts. In section 7.3.2, we describe how domain nesting can be used within conflict detection to reduce the number of potential conflicts. This principle, however, does not apply successfully to all the situations, i.e., there are cases in which it is desirable that a global policy override more specific ones. For this purpose, conflict detection can be performed with precedence relationships optionally disabled. The following two sections examine the importance of overlaps between domains, while applying the domain nesting principle, and indicate cases where inconsistency still remains.

7.3.2 The importance of overlaps in modality conflicts The analysis for conflicts of a set of policies enumerates all subject, action, target tuples to which a different set of policies applies. This makes it easier to determine where a conflict occurs and where precedence resolves a potential conflict.

114

Chapter 7

Conflict Analysis P1 + t1

s1

a1 sc

tc

ac a2

s2

t2

P2 -

Figure 7.1

Overlapping Subjects, Targets and Actions

Consider policies P1 and P2 represented in Figure 7.1 with P1 being positive and P2 being negative. Let us call the overlapping areas sc, ac and tc for common subjects, actions and targets. The triple overlap between the policies P1 and P2 creates three tuples to which different sets of policies apply: •

P1 alone applies to

•

P2 alone applies to

•

P1 and P2 together apply to

Neither P1 nor P2 is more specific, so a conflict is indicated to the user as their modalities are of opposite sign. Now consider a policy P3 (shown in Figure 7.2) defined by the tuple such that s3=sc, a3=ac and tc is a sub-domain of t3 which is a sub-domain of t2. P1 +

t1

s1 a1

P3 + sc

tc

ac a2

s2

t3 t2

P2 -

Figure 7.2

Adding a policy

We now have the following tuples and policies: •

P1 alone applies to

•

P2 alone applies to

•

P1, P2 and P3 together apply to

•

P2 and P3 together apply to

P3 is positive and more specific than P2, so it overrides P2 in the areas where they overlap, i.e., the tuples and . Since P1 and P3 have the same modality, conflicts can be automatically resolved using domain nesting precedence. Note that, when displaying the result of a conflict detection check, it is important to provide a user with information regarding which policies conflict, where precedence overrides conflict and to which tuples these policies apply.

115

Chapter 7

Conflict Analysis

If policies were specified in a logical formalism, the use of domain nesting precedence would require non-monotonic capabilities of the logical framework. Consider, for example, that P1, P2 and P3 above were authorisations. Before policy P3 is added, managers in the sc domain are forbidden to perform the invocations denoted by ac on all targets defined by the set t3-tc. This is because only P2 specifies their access rights on those target objects. When policy P3 is added, the managers are now authorised to perform the invocations on those target objects since P3 is a positive policy and overrides P2.

7.3.3 Limitations of domain nesting based precedence P2 overrides P1 for the areas in which they overlap P1

No Precedence between P1 or P2 can be determined P1

P2

P2 P1

P2 P1

P2

P1

P2 P1

P2 P1

P2 P1

P2

Figure 7.3

Precedence between policies

The domain nesting precedence determines all policies, which apply to a tuple of subjects, actions and targets and gives precedence to policies which apply to a more specific set of subjects, targets, or both. There are cases in which precedence cannot be established because the sets are equal, the subject sets are more specific but the target sets are less specific, or vice versa. The various situations where precedence can or cannot be established between two policies are shown in Figure 7.3. Note that precedence may be based on a policy’s subject or target set, so it is not an

116

Chapter 7

Conflict Analysis

ordering relation because it is not transitive. However, it presents the advantage of catering for both more-specific subjects and more-specific targets. There is no precedence relationship between obligations and authorisations, since an obligation overriding an authorisation would convey an implicit assumption that obligation implies authorisation − this is not true for the management policies considered in this thesis (Sloman 1994b).

7.3.4 A conflict detection tool Implementation issues In order to be able to check the consistency of a role-based specification, a conflict-detection tool for static analysis of a set of policies has been implemented. This tool detects overlaps between policies, identifies the to which a different set of policies applies, and can use domain nesting based precedence. The administrator or policy-maker can either: •

Use the tool with domain nesting precedence enabled, visualise the precedence relationships found, and examine any remaining conflicts that could not be resolved. The precedence relationship between policies is then indicated by arrows between policy icons (Figure 7.5).

•

Use the tool without domain nesting precedence and thus examine all conflicts arising from overlapping policies.

•

Use the tool in “analysis” mode to see which policies apply to a common set of subjects, actions and targets even when no conflict has been detected.

In theory, all policies in the system need to be checked for overlaps but this is impractical. Instead, a user can specify the scope of policies to be checked, for example policies applying to particular roles or policies of a relationship between roles. Policies, or domains of policies, can be dragged from the domain browser into a conflict detection window to establish the set of policies over which conflicts are to be detected. The Meta-policies discussed in section 7.4 can also explicitly define the scope to which they apply.

Example Software process management systems often use objects such as modification requests (MR) or trouble-tickets in order to coordinate the actions of actors in the development process. However, these systems can rarely reflect the complexity of the organisations, which may share developers between teams, or develop modules common to multiple projects. We describe a simplified example relating to the management of modification request objects, in order to highlight how conflicts may arise in a policy-based specification and how they can be detected using the analysis tool.

117

Chapter 7

Conflict Analysis

Modification request objects are created by invoking the create_MR() method on the MR_factory object. The organisation is divided into two project teams, each headed by a project manager (Figure 7.4). A group of engineers developing network modules for multimedia streams (streamingAPI) are shared between the two projects. In project1, this group is a sub-group of a larger group of network developers (NWdevelopers). We use domains to represent the grouping of objects and implement policies as objects also represented in the domain hierarchy (Figure 7.4). Project2 has a manager appointed to the help desk in order to deal with problems encountered by customers. /

MRfactory

policies

p1

p2

p3

p4

Project Manager

organisation

project1

project2

members

Project Manager

members

NWdevelopers

analyst

helpdesk

other project members streamingAPI other network developers analyst1

Figure 7.4

developer1

Domain structure

Policies are used to specify who is permitted (or forbidden) to create modification requests. By default, we assume the environment to be open in the sense that all invocations are authorised unless explicitly forbidden. Access control regarding the creation of modification requests is decided within each project separately, based on the characteristics of the project. Let us consider that both project1 and project2 adopt a default policy where only the project manager is allowed to create MRs. This means that the members subgroup of each project is prohibited from creating MRs by two policies specified below. p1 A- @/organisation/project1/members { create_MR() } /MRfactory p3 A- @/organisation/project2/members { create_MR() } /MRfactory

118

Chapter 7

Conflict Analysis

Furthermore, any modifications to the network connection modules may give rise to changes in project1. Therefore, network developers in project1 are authorised to create modification requests for the entire project. p2 A+ @/organisation/project1/members/NWdevelopers { create_MR() } /MRfactory Policy p2 should conflict with p1 since members of the NWdevelopers group are subjects of both p1 and p2, which have opposite modalities. However, since p2 is more specific than p1 (it relates to a subgroup of project1 members), it will take precedence over p1 according to the domain nesting principle. This will be detected by the conflict detection tool and indicated by an arrow between the two policies (Figure 7.5). The help-desk engineer in project2 receives direct feedback from the users regarding possible errors or misbehaviours in the product. An obligation policy ensures that any error reports are transformed into modification requests that will be investigated by the developers (policy p4). p4 O+ on error_reported @/organisation/project2/members/helpdesk { create_MR() } /MRfactory Figure 7.5 illustrates the main conflict detection window. The administrator chooses the set of policies on which conflict detection is to be performed (here p1-p4) via a drag-and-drop mechanism. After each conflict check, precedence relationships between policies are indicated to the administrator, if precedence has been enabled. Allowing the administrator to detect conflicts without using precedence relationships is necessary, because there are cases in which general policies should not be overridden by more specific ones (such as “remote access to classified information is to be denied to all users regardless of the circumstances”).

Figure 7.5

Precedence between policies and list of conflicts

119

Chapter 7

Conflict Analysis

After checking for conflicts with precedence enabled, two conflicts have been found in policies p1-p4. These conflicts may be displayed in windows (Figure 7.6 below). The first conflict (a) outlines that analyst1 and developer1 are subjects to two conflicting policies amongst which no precedence exists. This corresponds, in the domain structure, to the members of the streamingAPI sub-group, which is shared between the two projects. In project1 this sub-group is authorised to create modification requests, by virtue of being a sub-group of network developers, but is prevented from doing so by the default policy specified in project2 for all project members. The second conflict (b) shows that the help-desk staff in project2 is subject to two policies giving rise to an O+/A- conflict. Policy p4 obliges the manager to create a MR when customers have reported an error. However, he is prevented from doing so by the default policy p3 that forbids MR creation to all members in project2. Nesting of subject domains does not help because our obligation policies do not imply authorisation. The conflict detection tool is integrated with the role editor and domain browser. A system administrator or policy-maker can therefore study the indicated conflicts (Figure 7.6), and then edit policies or query domain membership of subjects and targets. This example has been greatly simplified by considering a single target object, a single action to be invoked on this object, and a limited number of subject domains and policies. In any realistic situation (where there are many levels of nested domains), the likelihood of specifying conflicting policies with overlapping domains is far greater. Furthermore, several administrators may be responsible for specifying policies and modifying the domain structure, thus increasing the risk of inconsistency in the specification.

(a)

(b)

Figure 7.6

Detected conflicts

120

Chapter 7

Conflict Analysis

7.4 Meta-Policies Modality conflicts can be detected purely by syntactic analysis of policies. Application-specific conflicts arise from the semantics of the policy and are specified in terms of constraints on attribute values of permitted policies. For example, in the case of the separation of duties (Clark 1987), where the same set of managers are not allowed to authorise payments and sign the payment cheques, the conflict is particular to the actions specified, i.e., authorise a payment and sign the cheque. It must therefore be specified by an additional constraint, which, when evaluated, detects the conflict. We term these constraints Meta-Policies i.e. policies about management policies, which requires the use of quantifiers over sets of policies. For example, the separation of duties can be stated as “there should not be two policies having overlapping subject domains which give rights to authorise a payment and sign a payment cheque”. This can be written as a logical predicate:

∀P1, P2 ∈ /policies/accounting P1.subjects ∩ P2.subjects ∧ (authorise ∈ P1.actions) ∧ (sign ∈ P2.actions) ∧ (payment ∈ P1.targets) ∧ (cheque ∈ P2.targets) ∧ (P1.mode = P2.mode = A + ) ⇒ P1 conflicts_with P2 Note that this is a constraint applying to a set of policies. It would be possible to formulate this constraint as part of a policy’s constraint, e.g., managers are allowed to authorise payments when there is no other policy authorising them to sign payment cheques. Although there is a conceptual difference between the constraint within a policy (which limits the scope of applicability of the policy) and a Meta-policy, which in general expresses incompatibilities between policies. This solution however is not suitable because constraints within policies must be evaluated at each interpretation of the policy, e.g., for an authorisation policy, at each access control decision. Therefore, the Meta-Policy would be re-evaluated a large number of times while the policies may not have changed within the system. Meta-Policies are included in roles or relationships to specify constraints on policies that can be grouped within them. For example, consider an "accountant" role instance. A Meta-Policy similar to the one given above would prevent any policy violating the separation of duty to be added to the role. Furthermore, if the Meta-Policy was specified for an accountant role class, then it would apply not only to all instances created from that class, but also to all the sub-classes and instances of the sub-classes. But the advantage of including Meta-Policies within a role (role class) is also that it enables the run-time system to determine the set of all structural constraints, i.e., MetaPolicies that must be enforced when the policies are enforced. Thus, the quantifier part of the

121

Chapter 7

Conflict Analysis

Meta-Policy specification (i.e. the scope of unification of the variables P1, P2 above) can be extended to include all policies which apply to a role at that particular moment in time. We have been experimenting with Meta-policies by implementing the predicate specification in Prolog. The set of policies contained in the Conflict Detection window (Figure 7.5) is automatically translated into Prolog assertions and the predicates evaluated. The set of all solutions to a predicate is the set of policies that are in conflict. Several types of applicationspecific conflicts are presented in (Moffett 1994). They identify cases such as conflict for resources, multiple management and self-management that are briefly summarised here.

a) Conflict of resources This occurs when the amount of resources (target objects) available is limited. The policies obliging and authorising managers to use these resources must therefore have a limited number of objects in their target scope. For example, “at most five disk partitions can be used for back-up activities”.

b) Multiple management Multiple managers may manage the same objects, either because the objects are shared between several tasks, or because different management functions are assigned to different roles. This may constitute a conflict when the management operations to be performed on the target object are not independent. For example, an update may require a service to be shut down temporarily while a get_configuration operation may require it to be in service.

c) Self management A manager may not be allowed to retract policies that he is supposed to perform. This can be written as: “there should be no policy authorising a manager to retract policies of which he is the subject”. Although in (Moffett 1994) these conflicts are characterised by overlaps between subject, action and target sets, no assumption can be made in the general case. The separation-ofduty conflict may not have an overlap between target domains. Further, it should not even have an overlap between subject sets if managers in the same accountancy department are not allowed to both authorise payments and sign cheques. Further work remains to be done regarding specification of Meta-Policies. While the use of Prolog is attractive because it offers the flexibility of a general logic programming language, a more restricted notation relating directly to the policy attributes is desirable.

122

Chapter 7

Conflict Analysis

7.5 Related Work on Conflict Detection The concept of domain nesting precedence used is based on that of Miró (Heydon, 1990), which only considers authorisation policy for file system security. Sandhu (1996) presents constraints that are similar to Meta-policies, but the notation used and the enforcement of constraints are not described. In addition to interactions (see Section 5.2.3) Minsky’s laws are also applied to object based systems (Minsky, 1997b). His “law-governed systems” can specify permissions and prohibitions as a set of rules which are similar to positive and negative authorisations. Conflicts are avoided by defining a Meta-level rule, which specifies whether permission or prohibition take precedence and override the other. Meta-level rules can also be used to define a ‘Prohibitionbased regime’ where permission is the default unless explicitly prohibited, or a ‘Permission-based regime’ in which prohibition is the default unless explicitly permitted. As discussed in section 7.3.1, assigning precedence to positive or (more commonly) negative policies may be very limiting and less intuitive than precedence based on specificity. However, it is also necessary to be able to specify flexibly the policy precedence relationship (used by the analysis tools), in terms of a meta-policy; although this is not yet implemented in the current version. We also assume that all actions are prohibited unless explicitly authorised. However there are systems which do implement negative authorisation, particularly for database access control so we consider it should be supported by a general purpose policy specification tool-set. The system described in (Minsky, 1997b) is not distributed although in (Minsky, 1996) a common global set of constraints is implemented by means of filters in every node which check that all interactions are consistent with the global law. We assume both specification and implementation of policies can be distributed. Our policies are not global but are interpreted only by explicitly-specified subjects (for obligations) and targets (for authorisations). Sibley et al. (1992) have also identified the need for a Policy Workbench with automated tools to specify and analyse policies. They have experimented with both first-order logic and an objectoriented approach to representing policy. They found that the latter reduces the size of the policy base and simplifies specification of policy (Sibley 1993). The policies considered are not limited to obligations and authorisations but general rules about the system. Both policies and “realworld” facts are eventually formalised in first-order predicate calculus with the use of modelling techniques such as enhanced entity-relationships diagrams. A theorem prover is then used on the policies and real-world facts to ensure consistency of the specification (Michael, 1993). Inconsistencies can be of two kinds: (1) logical inconsistencies and (2) statements that can be proved by the theorem prover tool, but do not comply with the intended specification. The tool is therefore used as a first step to detect logical inconsistencies in the policies and real-world facts given as axioms. Questions can then be asked by a policy-maker in form of theorems to be proved

123

Chapter 7

Conflict Analysis

by the tool. The authors have also explored a third stage performing “what-if” analysis by querying the theorem prover with regard to incremental changes in the policy base. The complexity of the approach of Sibley, Michael and co-authors is due to the generality of their policies. Our policies are simpler and explicitly identify subjects, actions and target objects. A logic-based approach, in which real-world facts (including object state) must be modelled, is more suited to requirements and specification analysis than distributed systems where objects states are often transient in nature. Nevertheless, their approach would help with respect to our policy constraints, but they do not use precedence relationships between policies to automatically resolve some conflicts. By treating basic conflicts between policies in terms of logical inconsistencies, implementing precedence into the conflict detection process would require either prioritised or retractable goals, or more complex formalisation of the policies catering for logical exceptions. Consider the case of a group of managers being authorised to perform an action by policy Px that is forbidden by a more general policy Py. Implementing precedence would require either: (1) retracting the logical facts corresponding to the prohibition given by Py and replacing those facts by their negation i.e. the authorisation given by Px or (2) formalising policy Py in a different manner – managers (with specified exceptions) are not allowed to perform actions on targets. Policy Px would then need to be explicitly declared as an exception to Py. Prakken (1997) addresses these issues and shows that defeasible or non-monotonic reasoning is required when formalising exceptions to the rules of a logical system. Although a finite number of exceptions can be formalised in first order logic, a law (and also a policy) can have an infinite number of exceptions which cannot be foreseen or taken into account when specifying the policy in the first place. Prakken conducts an extensive review of defeasible logic frameworks suitable for dealing with exceptions and of the various precedence relationships (or collision rules) that can be established between formalised rules specified in the logical system. Amongst other precedence relations, the specificity principle (domain nesting in our case) holds a prime place for choosing between conflicting conclusions. Prakken then extends the argument by modelling both defeasible reasoning, and reasoning with inconsistencies between rules, as comparing the arguments for incompatible conclusions. This comparison is carried out by defeating the applicability of the rules invoked in the argument using precedence relations. The logical framework used is complex, the author himself expressing concerns about the feasibility of its implementation as an automated tool. Our policy specification is much simpler and considers precedence relationships. Specifying activities and objects using first-order logic within a distributed system would encounter additional problems relating to failures and transient nature of some objects within the system. Another approach, used to detect feature interaction in telecommunication systems (Griffeth, 1993), considers policies as goals and uses a hierarchical representation of goals and alternative

124

Chapter 7

Conflict Analysis

ways to achieve those goals. Agents that implement policies negotiate with each other in order to find a plan in the goal hierarchy that achieves the goals of all agents but does not involve conflicting activities. In this work, conflicts are also considered as logical inconsistencies. The originality of the work lies in the use of negotiation to achieve conflict resolution. Planning techniques for conflict management are also used in Distributed Artificial Intelligence (Lander, 1994). In the case of our management policies such techniques could be used only in conjunction with the refinement of policies. For example, an abstract policy may be implemented in different ways by alternative sets of more concrete policies. Koch (1996) uses a policy notation based on ours and establishes a semantic graph model to detect ill-behaved policy sets with unsatisfiable pre-conditions. This can also be used to perform “what-if” analysis on chains of policies prior to execution. Deontic Logic provides the closest approximation of our management policies in the context of a logic system. However, as described in (Jones 1993), Standard Deontic Logic also relies on the axiom of inter-definability which defines a permission as Px =Def. ¬O¬x. No such assumption is made between our authorisation and obligation policies, since not all actions performed by a subject are specified as obligations. Therefore, authorisations do not correspond to the deontic logic permissions. A number of new logical systems with slightly different axioms, are emerging but the struggle against paradoxes that can be proved in such systems seems to continue.

7.6 Chapter Summary and Future Work This chapter has presented the integration of a conflict detection tool in the role-based framework for distributed systems management. We perform off-line, static, analysis of a set of policies to determine two types of conflict: (i) modality conflicts which can be checked by analysing the syntax of the policies and (ii) application-specific conflicts that need to be specified by external constraints (which we express as Meta-policies). Modality conflicts arise from a triple overlap between the subjects, actions and targets of the policies, but it is neither practical nor desirable to prevent these overlaps. We make use of a precedence relationship − based on the “specificity” of the policies with respect to domain nesting − to reduce the number of potential overlaps indicated to a user, and to allow inconsistencies between policies to exist within the system. We consider this to be an effective and intuitive precedence relationship. Roles are an important management concept but also provide a scope to limit the set of policies to be analysed. Our approach is to detect as many conflicts as possible at specification time, rather than leaving them to be detected at run-time. A user can then modify the policies to remove conflicts.

125

Chapter 7

Conflict Analysis

Another aspect of policy analysis relates to determining the policies applying to a particular subject or target. Our policies explicitly identify both subject and target, and the domain service maintains a list of policies applying to a domain so this is comparatively easy to do. Further work remains to be done on the use of dynamic run-time conflict detection within policy interpreters and what to do about conflicts that have been detected. In particular, relating the policy precedence to the set/subset relationship between the subject and/or target domains presents the disadvantage that precedence may change with domain membership at run-time. Further, the set of policies which applies to a tuple also changes at runtime according to the constraints of the policies, e.g., some policies apply only between certain hours. Our Meta-policy specification language also needs further refinement, as translating all policy specifications into Prolog assertions is a rather “heavy-handed” approach.

126

Chapter 8 Case-Study: Cellular Network Management

In previous chapters, we have often used examples from software engineering, medical care or general management in order to illustrate the concepts described. While these examples have the advantage of being intuitive and familiar, they are not directly related to network and distributed systems management. This chapter aims to exemplify the use of policies, roles, relationships and their object-oriented extensions in the context of the operation, administration and maintenance of a cellular GSM network. For this purpose, we shall consider a cellular network operator VirtuaCom and its organisational structure and geographical repartition. This example is based on the available literature on the operations and management of GSM cellular networks, however only a number of functions for the management Base Station Sub-systems (BSS) and subscriber data are discussed. The reference book of Mouly and Pautet (Mouly, 1992) and several documents from Series 12 of the GSM (phase 2) specifications (ETSI, 1-7) have been used in the elaboration of this scenario.

8.1 Introduction Management activities performed in the operation and maintenance of a cellular network are essentially of two kinds: (1) activities which are performed in response to events occurring in the network and (2) planning and configuration activities performed on the initiative of human managers. The second kind, which often occurs in centralised operation centres, is a less suitable candidate for policy-based specification. The operations and management activities of a cellular network operator may be distributed to reflect the geographical distribution of the network itself. There can be multiple roles in each of

127

Chapter 8

Management of a Cellular Network

the geographical regions, and the organisational pattern of roles and relationships constructed for the management of a region may be repeated in other regions. In order to reduce complexity, we have limited our study to the organisational pattern exhibited within a branch, a sub-division of a region. Although, this pattern may be repeated for all branches, the specification described here has not considered the management roles within regional and national operations centres. This is partly because regional and national operations centres have an administrative role, mostly oriented towards planning and configuration of the network and are not directly concerned with maintenance activities. The GSM Specifications (ETSI, 1-7) use TMN concepts and techniques, which are implemented over OSI CMIP protocols, or low-level signalling, rather than object invocations. The events and policies specified in this scenario assume higher-level, more abstract object-interaction interfaces. Thus, actions specified in policies do not always have a direct mapping to standardised management functions (which are generally specified in GDMO), but must be implemented in procedures and adapter objects that can perform the CMIP or SS7 signalling interactions. Similarly, a number of low-level alarms and notifications may be aggregated by the monitoring system into composite events that are communicated to the agents in order to trigger a policy. The events specified in policies may therefore not have a direct correspondence to low-level notifications. In addition to documents from the Series 12 of the GSM specifications (ETSI, 1-7), the overview given in (Lin, 1997) and (Nishikawa, 1992) have also proved useful in the elaboration of this scenario. In Section 8.2 we give an overview of the system to be managed and the organisational structure of the company. Section 8.3 will briefly enumerate the various types of manager (role classes) considered for the management of a branch, the types of relationship between them and the domain structure of the type repository, in which the specifications of role and relationship classes are stored. Since we must provide here a textual description of all the policies, role classes, etc., objects must be denoted by explicit paths in the domain hierarchy. Therefore, we outline the domain structure for the management of a region, and of a branch within it, in Section 8.4. Role classes are then specified in Section 8.5. Policy templates may be specified within a role or relationship class but also independently of them. In the latter case, they are templates for policies that apply to groups of managers within a branch or a region. Policy templates will be described in Section 8.6 before outlining the specifications for relationship classes in Section 8.7. Instances of policy templates, role and relationship classes will then be created, for a particular branch, in Section 8.8. A list of acronyms used here may be found at the end of the chapter.

128

Chapter 8


8.2 System Overview We consider VirtuaCom’s national network to be divided into 4 or 5 regions and each region subdivided into a number of branches. Although this decision is entirely arbitrary, it is nevertheless based on some network-specific parameters. Within a national network, each region may correspond to a different local carrier, which maintains its own Home Location Register (HLR). Each branch of a region corresponds to the area of coverage of a Mobile Switching service Centre (MSC) (800,000 inhabitants according to (Mouly, 1992)). Each region and branch have their own operations centre from which management activities are carried out. These centres are respectively called BOPC and ROPC, Figure 8.1. Help-desk centres deal with customer enquiries, set-up initial registrations of new customers, and update customer records, e.g., change of address, subscription to new services, etc. Several managers are employed in branch, regional and central Operations Centre of VirtuaCom’s network. Figure 8.1 shows the role classes (i.e., types of manager) defined at each geographical level.

- System Manager (SM) - Network Operator (NO)

VirtuaCom

OP Center (OPC)

Local Carrier

Regional OP Center (ROPC)

Branch Offices

Branch OP Center (BOPC)

-Network Element Administrator (NEA) -Branch Network Operator (BNO) -Branch Network Operator Radio (BNoR) -Telephone service engineer (TSE)

Shops

Help Desk Center (HDC)

- Help Desk Staff (HD)

Figure 8.1

- System Manager (RSM) - Network Operator (RNO)

Organisational Structure and Roles

In addition to the MSC and VLR, the Network Elements (NE) managed in VirtuaCom’s network also contain Base Station Controllers (BSC) and Base Transceiver Stations (BTS), for radio communication with Mobile Stations (MS). The various switches and registers can be controlled from an Operations and Maintenance Centre Workstation (OMC); and a special OMC (OMC-R) controls the radio transmission equipment, namely the BSCs and through them the BTSs. The Mobile Switching Centres (MSC), Gateway MSCs (GMSC), Home Location Registers (HLR), Visitor Location Registers (VLR) and Entity Identification Registers (EIR) communicate through SS7 signalling while the various management services are interconnected in an Operations

129

Chapter 8


Network (LAN, WAN, etc.) (Nishikawa, 1992). Figure 8.2 is a schematic representation of the managed equipment and its various interconnections.

Management Servers Help Desk VLR EIR

Operations Network Help Desk

GMSC

OMC SS7 HLR NE Administrator

OMC-Radio

MSC

BSC

BTS

connection

BTS control

BSC

BSC BTS

Figure 8.2

System Overview Diagram

8.3 Role and Relationship Classes Role and Relationship classes define organisational patterns for the operations and management of VirtuaCom’s network. Role classes define the basic types of role while relationship classes can be used to instantiate relationships between role instances. In order to limit complexity we restrict our study to the role classes listed below. A brief informal description is given for each class (e.g., job descriptions), and the abbreviations associated with class names will be used in all diagrams.

Help-Desk (HD) The help-desk staff ensures the interface between customers and VirtuaCom. They are responsible for dealing with both customer complaints regarding the service and customer service (e.g., customer-record creation and update, and service subscription). Customer complaints regarding function, or Quality of Service (QoS) perceived on their mobile station, are forwarded for investigation to a Telephone Service Engineer (TSE).

130

Chapter 8


Telephone Service Engineer (TSE) The role of the Telephone Service Engineer is to investigate faults occurring on the radio interface between a mobile station and base transceiver stations. It is his responsibility to determine whether a failure or performance degradation is due to a problem in the mobile station or likely to be a failure in the cellular network. He may interact for this purpose with the Base Network operator in charge of the radio transmission equipment.

Base Network Operator – base role class (BNO-base) There are two types of base network operator: those managing radio transmission equipment (BSC, BTS) and those managing switches and registers (MSC, VLR). The BNO-base role class defines the common characteristics of the BNO and BNoR role classes that inherit from it.

Base Network Operator (BNO) A base network operator is responsible for managing the MSC and VLR situated in a branch. In addition, he collaborates with the BNoR to manage connections between the MSC and the various BSCs.

Base Network Operator – Radio (BNoR) The BNoR role is responsible for managing the radio circuits (BSC, BTS). He, further, interacts with the Telephone Service Engineer to investigate radio transmission failures.

Network Element Administrator (NEA) The NEA performs all on-site management activities. His interventions may be requested by both BNO and BNoR. Although mostly working on-site, the NEA management functions are specified in the Operations Systems in order to allow a NEA to remotely perform tests and invoke commands on the NEs. Figure 8.3 outlines, in an OMT-style notation, the role classes, the associations between them (which are specified as relationship classes) and the inheritance relations.

131

Chapter 8

Management of a Cellular Network Telephone Service Engineer (TSE)

Help-Desk (HD) HD TSE Network Element Administrator (NEA)

Branch Netowork Operator - base (BNO-base)

TSE BNoR

BNO-base NEA

BNoR NEA

Branch Network Operator (BNO)

BNO NEA

Branch Network Operator - Radio (BNoR) BNO-BNoR

type associations

Figure 8.3 Role and Relationship classes (shaded boxes represent role classes) The relationship classes BNO-NEA and BNoR-NEA override the inherited relationship association (BNO-base)-NEA. Since they may be used to instantiate similar organisational patterns in several regions or branches, role and relationship classes will be stored in a separate domain at the organisational level. As we must refer to these objects in the specification, we consider that the class library domain is structured as represented in Figure 8.4. /tr - type repository

pt - general policy templates

rr - role and relationship classes

rc - role classes

HD BNO-base

NEA TSE

ec - relationship classes

BNO

BNO-R

HD-TSE

TSE-BNoR

BNoR-NEA

Figure 8.4

(BNO-base)-NEA

BNO-NEA

BNO-BNoR

Role and relationship classes in the type-repository (shaded boxes represent leaf-objects)

132

Chapter 8


8.4 Domains When specifying the scenario using the tools described in this thesis, references between objects are hidden behind their graphical representation. The administrator manipulates an object’s icon rather than specifying a path in the domain hierarchy. Since we must provide a textual representation in this document, explicit paths to objects must be specified. Hence, an outline of the envisaged domain structure must be planned before specifying the role classes and their instances. reg1 - root domain for region 1

tn (telecom network)

branches

switches

other branches

br1 - root domain for the branch 1

HLR GMSC

EIR BSS

pd - position domains

policies all pol x objects

roles

rel relationships

OMC-R HD

HD1

HD2

NEA1

NEA

TSE

BNO

NEA2

opn (operations network)


OMC

BNoR

MSC

TSE1

HLR EIR

NEA-BNO

NEA-BNoR HD-TSE

NEA1-BNO

NEA2-BNO

HD1-TSE1

BNO-BNoR

VLR

BSC

TSE1-BNoR

NEA2-BNoR

NEA1-BNoR

BSC1

HD2-TSE1

BSC2

alias

Figure 8.5 Regional domain structure (shaded boxes represent leaf objects) Figure 8.5 shows the partial domain structure within a region with one branch (branch 1) expanded. Sub-domains containing policy objects and position domains have not been fully represented in order to avoid complicating the diagram. The reader may however assume that the ‘policies’ domain contains objects denoted by ‘polx’, where x is the number of the policy. The position domain (pd) contains the manager position domains of roles, in a domain structure identical to that of the ‘roles’ domain. Grouping the position domain in a separate domain

133

Chapter 8


structure to roles allows us to specify group policies, which apply to all managers in a branch. For example, in Figure 8.5 above, the following policy could be specified: /* all managers in branch 1 are authorised to access the GMSC */ A+ @/reg1/branches/branch1/pd { access() } /reg1/tn/switches/GMSC The policy propagates to all the members of the pd (position domains) and thus to all objects assigned to management roles within the branch. Within both a region and branch, the NEs are grouped within a telecom network domain (tn). Within a region, the ‘tn’ domain contains the GMSC, HLR, EIR and a sub-domain of Base Station Sub-systems (BSS) which groups all BSC elements of all branches. Since the BSCs already belong to the domains of the branches, only an alias to the BSC domains present in each branch is introduced. (An alias is conceptually similar to a link in a file-system directory.) The advantage of grouping the various BSCs in a BSS sub-domain is that policies at the regional level can be specified more easily. For example, an authorisation may be given to the regional network operator to shut-down all the BSCs as follows: A+ /reg1/roles/RNO { shut_down() } @/tn/BSS Aliases can also be used to include references in a sub-domain for objects located in a different part of the hierarchy. For example, references to the HLR and EIR can be included in the telecommunication network sub-domain of a branch (Figure 8.5). This simplifies specifying policies within a branch by referring to the HLR and EIR as local objects (e.g., tn/HLR). In the following, we assume that paths are specified with regards to the current domain (i.e., br1 for all roles and policies in branch 1). Thus, tn/HLR will expand to reg1/branches/br1/tn/HLR, which denotes the same object as reg1/tn/HLR.

8.5 Role Classes We represent in the following only those role class attributes necessary for an understanding of the scenario. For example, concurrency-constraints are represented only if they are specified within a role, and local names for policy templates will be specified only if they are used in a concurrency constraint. Comments are written in a C-style, e.g., /* this is a comment */.

The Help-Desk Role Class The Help-Desk staff deals with all customer records and interacts with the Telephone Service Engineer for those customer complaints, which pertain to network or mobile station performance.

134

Chapter 8

HD (Help-Desk Staff) policy-templates:


path: /tr/rr/rc/HD

Customer complaints /* Must input the complaint and run a program which will attempt to correlate the information with complaints received from other customers elsewhere */ pol_a O+ on customer_complaint(complaint) s:mpd { /*input complaint*/ ; s.investigate(complaint) } n/a HLR management pol_b O+ on new_service_subscription(x) mpd { update_record(x.customer, x.service } /* HLR */ Xref: /tr/pt/pt1 /* refers to the policy template for the group authorisation */ Billing and abnormal event handling /* On unpaid bills lock subscriber in HLR. This has a temporary effect */ O+ on unpaid_bills(IMSI) mpd { lockSubscriberInHlr(IMSI) } /* HLR */ Xref: /tr/pt/pt1 /* Black-list stolen equipment */ O+ on reported_stolen(IMEI) mpd { blacklist_equipment(IMEI) } /* EIR */ Xref: /tr/pt/pt2 /* The HLR may lose consistency and not recognise subscribed customers correctly. an unrecognised customer which has been identified as known to the PLMN must have its record updated */ O+ on unrecognisedCustomerInHLR(IMSI) s:mpd { s.checkRecord(IMSI) } n/a

relationship-classes: /tr/rr/ec/HD-TSE The first action of policy pol_a is abstract and must be performed by the human manager assigned to the instances created from this class. The following action is automatically run as a procedure defined in the internal interface of the obligation policy interpreter. The target is therefore not necessary to enforce the policy and the action does not require explicit authorisation. However, the object invocations performed during the execution of the action need to be authorised by explicit policies. Policies similar to pol_b can be specified for updating any of the customer records, e.g., home address, billing address, etc. No obligation policy specified in this role class has a corresponding authorisation specified in it. This is because there can be many HD instance roles within a branch. Specifying a template for an authorisation (e.g., to update the HLR), in the role class implies that a corresponding policy instance is created for each HD role instance. Instead, since the target object is the same for all instances (e.g., the HLR), the specification can be optimised by specifying a group policy that applies to all position domains of HD role instances. However, in doing so, we break the encapsulation of rights and duties within a role. Furthermore, an administrator or policy-maker has to ensure that each instance of the HD role class has a position domain in the appropriate part

135

Chapter 8


of the domain hierarchy, such that the group policy applies to it. In any case, the conflict detection tool can discover if any obligation policies have been specified without the appropriate authorisation. We are using the cross-reference label ‘Xref’ to refer to the policy template from which a group authorisation must be created. The reference to the relationship class HD-TSE specifies that a Help Desk role (instance of the HD role class) cannot be created without defining a relationship with a Telephone Service Engineer, i.e., a relationship instantiated from the HD-TSE relationship class.

The Telephone Service Engineer Role Class TSE (Telephone Service engineer) policy-templates:

path: /tr/rr/rc/TSE

/* On receipt of a complaint from a customer, automatically check the radio presence of his/her mobile station (MS), its service subscription list and the number of successful handovers performed by the MS in the branch VLR */ pol_a O+ on customer_complaint(IMEI) mpd { checkSubscriberRadioConfirmation(IMEI); checkSubscriberSsInfoList(IMEI); checkSubscriberHandoverNumber(IMEI); /* investigate complaint */ } /* VLR */ Xref: /tr/pt/pt4 /* On MS problem confirm record problem (EIR) */ O+ on MS_failure(IMEI) mpd { update_record(IMEI) } /* EIR */ Xref: /tr/pt/pt3 /* on use of grey-listed MS initiate a trace (the use of a grey-listed IMEI is signalled to the maintenance system together with the IMSI of the subscriber which used it) */ O+ on grey_list_use(IMEI, IMSI) mpd { traceForeignSubscriberinVLR(IMEI, IMSI) } /* VLR */ Xref: /tr/pt/pt4

relationship-classes: /tr/rr/ec/HD-TSE; /tr/rr/ec/TSE-BNoR The event customer_complaint triggering policy pol_a may be generated automatically by the Interaction Protocol agent when a message has been received from one of the help-desk staff. References to the relationship classes specify that there should be at least one instance of the respective relationships. It does not however limit their number. For example, a TSE can have multiple relationships with multiple instances of HD.

The Network Element Administrator Role Class The Network Element Administrator performs on-site operations on NEs. Examples of functions invoked are: run diagnostic, test radio-signal power level, test connection, self-test hardware, reset and recovery procedures of the network elements. Furthermore, the NEA must be able to inhibit or reactivate a BTS for operation, and access databases for statistics and performance records. The

136

Chapter 8


NEA role must be defined in the operations system because a manager must be able to invoke remote tests from management servers and OMC-R when on site. However most of the actions performed by the NEA are initiated by a human manager. Therefore, they are not suitable for specification as positive obligation policies.

NEA (Network Element Administrator) policy-templates:

path: /tr/rr/rc/NEA

/* Event aggregation can be used to group several events in the BTS_failure event. In addition, the event can be internally generated as a result of an interaction with the BNoR */ O+ on BTS_failure(BTSid, BSCid) mpd { run_test(BSCid, BTSid); /* investigate cause */ } /* branch OMC-R */ Xref: /tr/pt/pt5

relationship-classes: /tr/rr/ec/(BNO-base)-NEA The BNO-base Role Class The BNO-base role class groups common aspects of the BNO and BNoR role classes. Furthermore, by referring to the (BNO-base)-NEA relationship class, the BNO-base class places a constraint on all its sub-classes. Both BNO and BNoR role classes will inherit the constraint and may override it with a relationship class that is a specialisation of the (BNO-base)-NEA relationship class.

path: /tr/rr/BNO-base BNO-base relationship-classes: rel1 /tr/rr/ec/(BNO-base)-NEA; /* the base setting for the relationship will be overridden in sub-classes */

The Branch Network Operator – Radio (BNoR) Role Class The BNoR role class specialises the BNO-base role class from which it inherits. The BNoR manages the radio transmission equipment, i.e., the Base Station Controllers (BSC) and through them the Base Transceiver Systems (BTS). In particular the BNoR is responsible for actions to be taken: •

when a BTS fails, and therefore a cell cannot be used any longer,

•

when a BTS becomes overloaded,

•

when Quality of Service becomes unacceptably low due to degradation of the transmission circuits or changes in environmental conditions.

BTSs can only be managed through the BSCs. Hence, the event notifying of malfunction or failure of a BTS must give the identifier of the managing BSC in addition to the identifier of the failed BTS. Events relating to the failure or malfunction of a BTS are normally aggregate events due to multiple causes (e.g., communication alarms, environmental alarms, large power

137

Chapter 8


consumption, etc.). Whenever possible, a forced handover of all connected mobile stations (MSs) should precede any cell-barring operation.

BNO (Branch Network Operator) – Radio inherits from: /tr/rr/rc/BNO-base policy-templates:

path: /tr/rr/rc/BNoR

Cell failure

/* On BTS malfunction force connected handovers and barr cell */ O+ on BTS_malfunction(BTSid, BSCid) mpd { forceHO(BTSid); barr_cell(BTSid); } /* managing BSC */ A+ mpd { forceHO(); barr_cell();shut_down() } /* BSC */ Transmission management (power level, configuration, etc.)

/* If there are too many connection requests, the number of initiating calls may be limited by requiring the MS to have a higher RX level before accessing the cell */ O+ on unsuccReqsForServiceAlert(BTSid, BSCid) mpd {increment(BTSid, RXLEV_ACCESS_MIN)} /* BSC */ /* On cell overload, force a hand-over of all connected MS */ O+ on cellOverload(BTSid, BSCid) mpd { forceHO(BTSid) } /* BSC */ /* When a transmission circuit fails, the manager must replace it with the backup one and reconfigure the BTS */ O+ on TRX_failure(TRXid, BTSid, BSCid) mpd { disable(BTSid, TRXid), enable(BTSid, backupTRX), reconfigure_add(BTSid, backupTRX) } /* BSC */ /* On 3 occurrences of the failure event report increase emission power of the BTS */ O+ on 3*radioLinkFailureAlert(BTSid, BSCid) mpd { increaseTX_power() } /* BSC */ Needed Authorisations

A+ mpd { increment_cellHysteresisValue(); increment(); increment_locationUpdatesFreq(); reconfigure_add(); increaseTX_power(); decreaseTX_power(); set_RF_params(); enable(); disable() } /* BSC */

relationship-classes: rel1 /tr/rr/ec/BNoR-NEA; /* overrides the relationship defined in the super-class */ /tr/rr/ec/TSE-BNoR; /* requires a relationship with a telephone service engineer */ /tr/rr/ec/BNO-BNoR /* requires the instantiated role to have a relationship with a BNO */

The Branch Network Operator (BNO) A Branch Network Operator manages a branch’s switches and registers. It specialises the BNObase role class from which it inherits. In particular, the requirement to participate in a relationship with a Network Element Administrator is strengthened. Thus, the BNO role class overrides the reference to the (BNO-base)-NEA relationship class with a reference to the specialised BNONEA relationship class.

138

Chapter 8

BNO (Branch Network Operator) inherits from: /rr/rc/BNO-base policy-templates:


path: /tr/rr/rc/BNO

/* After VLR failure it must be restarted and checked for consistency */ pol_r O+ on VLR_failure s:mpd {s.restart_VLR() ; check_consistency() } /* VLR */ O+ on MSC_failure(x) s:mpd {s.restart_MSC(x) } n/a A+ mpd { check_consistency() } /* VLR */ Circuit failure between the MSC and the BSC

/*When the failure of an A_interface circuit is noted in the MSC, the corresponding circuit must be blocked. When the failure is noted in the BSC the circuit must be reset. */ pol_a O+ on A_failure(circuit x, BSCid) mpd { reset(x); } /* BSC */ pol_b O+ on A_failure(circuit x) mpd {block_circuit(x) } /* MSC */ A+ mpd {block_circuit(); unblock_circuit() } /* MSC */ Security and Subscriber trace

/* The imsiConfidentialityFailure event is reported when an abnormal number of IMSI authentications have taken place on a given radio path. In that case the radio path should be blocked */ O+ on imsiConfidentialityFailure(r) mpd { lockRadioPath(r) } /* MSC */ A+ mpd { lockRadioPath() } /* MSC */

concurrency-constraints: pol_b; pol_a relationship-classes: rel1 /tr/rr/ec/BNO-NEA; /* overrides the relationship defined in the super-class */ /tr/rr/ec/BNO-BNoR The A_failure event specified in policies pol_a and pol_b may be reported from both ends of the communication link, i.e., MSC and BSC. In this case, the circuit must be blocked before being reset, which can be ensured by the concurrency constraint. In policy pol_r, VLR is the target object for the check_consistency operation while the restart_VLR action is a procedure defined on the internal interface of the obligation policy interpreter.

8.6 Policy templates Not all policies in a management system can (or should) be grouped into roles. Many policies are specified with regard to groups of managers or individuals in the organisation, e.g., all NEAs in branch1. In the present scenario, we have concentrated on role specification. Nevertheless, some policies can be specified in terms of groups of roles, rather than included in the roles themselves, in order to optimise the specification. This occurs when several instances created from the same role class (e.g., Help-Desk staff) must access the same target objects (e.g., branch VLR). Instead

139

Chapter 8


of creating an authorisation policy for each role instance, a group policy, having as subject the position domains of all role instances, can be created. This reduces the number of policy (instances) to be specified, but has the following disadvantages: •

It breaks the encapsulation of rights and duties within a role.

•

These policy templates are not part of the roles and therefore cannot be inherited and overridden if the role is specialised.

•

It increases the burden of checking that all actions specified in an obligation policy have the corresponding authorisations. Since policies created from these templates are not part of a role instance, they must be manually included in the scope of the conflict detection search.

•

The administrator or policy-maker has to ensure that the roles’ position domains are within the scope of the specified authorisation policies.

The following policy templates are specified to provide the necessary authorisations for the obligations of the various roles. pt1 A+ /* branch HD */ { add_new_customer(); update_record(); traceHomeSubscriberInHLR(); lockSubscriberInHlr() } /* HLR */ pt2 A+ /* branch HD */ { blacklist_equipment() } /* EIR */ pt3 A+ /* branch TSE */ { update_record() } /* EIR */ pt4 A+ /* branch TSE */ { initiate_trace();checkSubscriberRadioConfirmation(IMSI); checkSubscriberSsInfoList(IMSI); checkSubscriberHandoverNumber(IMSI)} /* VLR */ pt5 A+ /* branch NEA */ { run-test() } /* branch OMC-R */

8.7 Relationship classes The various relationship classes to be defined are those shown in Figure 8.3 and Figure 8.4. In order to reduce the size of the specifications we assume that only one interaction protocol is defined per-relationship and do not specify concurrency constraints. In all interaction protocols, an incoming message will be denoted by convention by ‘m’; and in all policies, ‘this’ denotes the current relationship instance object when the relationship is instantiated. The latter allows us to take into account the current implementation of the interaction protocol agent where messages are sent through the relationship in order to hide the reference of the destination role (see Section 5.4.3).

140

Chapter 8


Relationship class for Help-Desk – Telephone Service Engineer relationships The help-desk staff notifies a Telephone Service Engineer (TSE) of all customer complaints regarding the functioning and quality of service in their mobile station. The TSE must then evaluate the possibility of the failure being in the mobile station or in the cellular network and send a corresponding response. According to the response received the help-desk may notify the customer.

R1:HD Policies

R2:TSE

/* On a customer complaint regarding the MS inform the TSE. This initiates the interaction */ O+ on MS_error(t) R1 { send(R2,MS_error, IMSI) } this A+ R1 { send() } this

Interaction protocols ip2 MS_error.confirm_MS_error ⇒ { /* notify customer faulty MS */ } ip3 *.corrected ⇒ { /* notify customer */ } ip4 MS_error.no-error ⇒ { /* do not notify customer */; log(m) }

ip1 MS_error ⇒ { event(customer_complaint(m.contents)); /* investigate MS_error */ ; { [corrected] È R1 or { [no-error] È R1 ; event(network-fault) } or [confirm_MS_error] È R1 }}

The event customer_complaint(IMSI) specified in interaction protocol rule ip1 will trigger an obligation policy specified within the role.

Relationship class for Telephone Service Engineer – Base Network Operator Radio relationships A TSE reports to a BNoR all errors occurring on the radio interface which might be due to the base transceiver stations.

R1:TSE Policies

R2:BNoR

O+ network_fault() R1 {send(R2, BTS-fault) } this A+ R1 {send()} this

Interaction protocols ip2 *.no-fault ⇒ ⊥ ip3 *.fault ⇒ { log(m) }

ip1 BTS-fault ⇒ {/* investigate */; { [no-fault] È R1 or {[fault] È R1; event(BTS_malfunction(BTSid)) }}

141

Chapter 8


The event BTS_malfunction specified in the interaction protocol rule ip1 triggers an obligation policy, which forces a connected handover and bars the cell.

Relationship class for Telephone Service Engineer – Base Network Operator Radio relationships A base network operator (BNO) interacts with its radio counterpart in order to determine cuases of failure or performance degradation on the transmission circuits between a BSC and the MSC. The interaction may be started by either role but in either case it must be initiated by a human manager.

R1:BNO Interaction protocols

R2:BNoR

ip1 [radio-fault] È R2

ip2 [A_failure] È R1

ip3 A_failure ⇒ { /* investigate failure */ ; {event(A_failure(m.circuitID)); /* test circuit */; { [confirm] È R2; or [no-failure] È R2}} or [radio-fault] È R2 }

ip4 radio-fault ⇒ {/* investigate */ ; { [no-fault] È R1 or [corrected] È R1 or [confirm-fault, circuit_id, BTSid] È R1}}

ip7 *.no-fault ⇒ { FTAMretrieveMSClogs(); /* investigate */} ip8 *.radio_fault.confirm_fault ⇒ ⊥

ip5 A_failure.confirm ⇒ ⊥ ip6 A_failure.no-failure ⇒ { FTAMretrieveBTSlogs(); /* investigate */ }

This protocol specifies that the interaction may be initiated by either BNO (ip1) or BNoR (ip2). The BNO may report a possible radio-fault that must be investigated by the BNoR. Then the BNoR can either confirm the fault, confirm that there was a fault and it has been corrected, or reply that no fault could be found (ip4). The BNoR may report a possible A_failure to the BNO (ip2). After investigation, the BNO may decide to either: test the circuit and report the results or suspect it is a radio failure (ip3). The circuit is then automatically blocked since the A_failure event triggers obligation policies defined in the role.

Relationship class for BNO-base – Network Element Administrator relationships The following protocol defines the interaction between a Network Element Administrator (NEA) and a Base Network Operator. It permits a BNO to assign a task to an NEA and constraints the NEA to respond with pre-defined message types regarding task completion. Moreover, a positive obligation policy obliges the NEA to report to the BNO every day. Since this protocol is not specific to any particular type of BNO, the required type of the role is BNO-base, i.e., the superclass of all BNO role classes. This protocol is inherited by the BNO-NEA and BNoR-NEA relationship classes

142

Chapter 8

R1:BNO-base Policies


R2:NEA np1: O+ every 1*day R2 { report} R1

Interaction protocols ip1 [assign-task] È R2 ip2 *.task-completed ⇒ {log(m)} ip3 *.already-in-progress ⇒ ⊥

ip2 assign-task ⇒ { [task-completed ] È R1 or [cannot-be-completed] È R1 or [already-in-progress] È R1 }

ip4 *.cannot-be-completed ⇒ { /* re-evaluate task */}

Relationship class for Base Network Operator – Network Element Administrator relationships There are no additional specifications for this relationship class. The protocol for task assignment is inherited from the super-class. However, this sub-class is created in order to override the value of R1 to BNO. This requires that all instances of this class are relationships between instances of role-class BNO and role-class NEA.

R1:BNO

R2:NEA

inherits from: /tr/rr/ec/(BNO-base)-NEA

Relationship class for Base Network Operator – Network Element Administrator relationships The rules given in this specification extend the protocol defined in the base class in order to allow an NEA to report a BTS malfunction. Such a report is automatically interpreted by the interaction agent to generate the corresponding event, triggering the obligation policy to bar the BTS.

R1:BNoR

R2:NEA

inherits from: /tr/rr/ec/(BNO-base)-NEA

Interaction protocols ip6 *.BTS_malfunction ⇒ { event(BTS_malfunction, message.BTSid, message.BSCid) }

ip5 assign-task ⇒ { [BTS_malfunction, BTSid, BSCid] È R1}

8.8 Creating instances Once the role classes have been specified, instances can be created for different branches. As represented in Figure 8.5, we will consider that branch 1 has one telephone service engineer, two help-desk staff, two network element administrators and one base network operator of each kind (i.e., BNO and BNoR). This decision is not entirely arbitrary since the specification of classes for

143

Chapter 8


roles and relationships imposes the following constraints (under the assumption that no managers are shared between branches): •

Help-desk staff must be able to interact with a telephone service engineer. Hence, there must be at least one instance of the TSE role class and as many instances of the HD-TSE relationship as there are HD role instances.

•

The Telephone Service Engineer must interact with an instance of the BNoR role class, which in turn must be related to an instance of the BNO class. Hence, instances of BNO and BNoR role classes must be created. A relationship must be instantiated between them and between BNoR instances and TSE instances.

•

A relationship instance must associate each of the BNO and BNoR instances with an NEA.

Figure 8.6 shows the instantiation we have chosen for branch1. In addition to fulfilling the above constraints, the following organisational choices have been made: •

There are two instances of the HD class and one instance of the TSE class. Hence, both instances created from the HD-TSE relationship class must relate to the TSE1 instance.

•

There is only one instance of the BNO and BNoR classes.

•

There are two instances of the NEA class and each of them relates to both BNO and BNoR. (Note that having only the NEA1-BNO and NEA2-BNoR relationships would have satisfied the constraints).

NEA1 HD1 R -BNo NEA1

R

BNO

o 2-BN NEA

1

TSE1

NEA2 NEA 2-BN O

HD2 -TSE

HD1-TSE1

NEA 1-BN O

HD2

BNOBNoR

BNoR

TSE1-BNoR

Figure 8.6

Role instances and relationships between them

8.8.1 Policies We can instantiate the policy instances below from the policy templates, specifying the authorisations relating to groups of roles. The domain paths correspond to the structure shown in Figure 8.5 and the convention adopted is that local paths are expressed relative to the branch domain (i.e., /reg1/branches/br1 has been omitted from all path expressions that do not start at the root ‘/’). Policies apply to managers assigned to roles. Hence their subject must be expressed

144

Chapter 8


in terms of the position domains specified for the roles. As shown in Figure 8.7, the position domain (pd) is an exact reflection of the roles domain. When creating a policy from a template only the subject and target must be specified as shown below (subject and target in bold face): pol1 A+ @pd/HD { add_new_customer(); update_record(); traceHomeSubscriberInHLR(); lockSubscriberInHlr() } tn/HLR pol2 A+ @pd/HD { blacklist_equipment() } tn/EIR pol3 A+ @pd/TSE { update_record() } tn/EIR pol4 A+ @pd/TSE { initiate_trace();checkSubscriberRadioConfirmation(IMSI); checkSubscriberSsInfoList(IMSI); checkSubscriberHandoverNumber(IMSI)} tn/VLR pol5 A+ @pd/NEA { run-test() } opn/OMC-R

br1 - root domain for the branch 1

roles HD

NEA

opn (operations network)

policies all pol x objects

pd - position domains

TSE

BNO

OMC-R


OMC

BNoR HLR

MSC HD1

HD2

NEA1

NEA2

TSE1

EIR HD

HD1

HD2

NEA1

NEA

TSE

NEA2

VLR BNO

BNoR

BSC

TSE1 BSC1

Figure 8.7

BSC2

Branch with position domains

8.8.2 Role Instances Since the process of instantiation is the same for all roles created from the same class, we will only give the specification for one role instance (e.g., HD1) when several must be created (e.g., HD1, HD2). Elements to be specified during the instantiation process are written in bold face. Policies in which only the subject domain must be specified, can be automatically instantiated since the subject is given by the MPD. They are shown in italics. These policies are either: (1) policies specifying activities that are procedures available to the obligation policy interpreter

145

Chapter 8


through its internal interface or (2) policies created from a template where the target domain is specified.

Role instance HD1 created from the Help-Desk (HD) role class HD1 (Help-Desk Staff) mpd: pd/HD/HD1 policies:

path: roles/HD/HD1

class: /tr/rr/rc/HD

Customer complaints O+ on customer_complaint(complaint) s:mpd { /*input complaint*/ ; s.investigate(complaint) } n/a HLR management O+ on new_service_subscription(x) mpd { update_record(x.customer, x.service } tn/HLR Xref: policies/pol1 Billing and abnormal event handling O+ on unpaid_bills(IMSI) mpd { lockSubscriberInHlr(IMSI) } tn/HLR Xref: policies/pol1 O+ on reported_stolen(IMEI) mpd { blacklist_equipment(IMEI) } tn/EIR Xref: policies/pol2

O+ on unrecognisedCustomerInHLR(IMSI) s:mpd { s.checkRecord(IMSI) } n/a

relationships: rel/HD-TSE/HD1-TSE1 Role instance TSE1 created from the Telephone Service Engineer (TSE) role class TSE1 (Telephone Service engineer) mpd: pd/TSE/TSE1 policies:

path: roles/HD/HD1

class: /tr/rr/rc/TSE

O+ on customer_complaint(IMEI) mpd { checkSubscriberRadioConfirmation(IMEI); checkSubscriberSsInfoList(IMEI); checkSubscriberHandoverNumber(IMEI); /* investigate complaint */ } tn/VLR Xref: policies/pol4 O+ on MS_failure(IMEI) mpd { update_record(IMEI) } tn/EIR Xref: policies/pol3 O+ on grey_list_use(IMEI, IMSI) mpd { traceForeignSubscriberinVLR(IMEI, IMSI) } tn/VLR Xref: policies/pol4

relationships: rel/HD-TSE/HD1-TSE1; rel/HD-TSE/HD2-TSE1; rel/TSE1-BNoR

146

Chapter 8


Role instance NEA1 created from the Network Element Administrator role class Only this instance is given here. (The NEA2 role instance is identical with the exception of the relationship references.)

NEA1 mpd: pd/NEA/NEA1 policies:

path: roles/NEA/NEA1

class: /tr/rr/rc/NEA

O+ on BTS_failure(BTSid, BSCid) mpd { run_test(BSCid, BTSid); /* investigate cause */ } opn/OMC-R Xref: policies/pol5

relationships: rel/NEA-BNO/NEA1-BNO; rel/NEA-BNoR/NEA1-BNoR There are no instances of the BNO-base role. Hence, only the BNO and BNoR instances are created. The authorisations which have a BSC object as target must be given for all BSCs since the identity of the BSC is known only at run-time.

Role instance Base Network Operator Radio (BNoR) BNoR mpd: pd/BNoR policies:

path: roles/BNoR

class: /tr/rr/rc/BNoR

Cell failure O+ on BTS_malfunction(BTSid, BSCid) mpd { forceHO(BTSid); barr_cell(BTSid); } tn/BSC/BSCid A+ mpd { forceHO(); barr_cell();shut_down() } @tn/BSC Transmission management (power level, configuration, etc.) O+ on unsuccReqsForServiceAlert(BTSid, BSCid) mpd {increment(BTSid, RXLEV_ACCESS_MIN)} /tn/BSC/BSCid O+ on cellOverload(BTSid, BSCid) mpd { forceHO(BTSid) } tn/BSC/BSCid O+ on TRX_failure(TRXid, BTSid, BSCid) mpd { disable(BTSid, TRXid), enable(BTSid, backupTRX), reconfigure_add(BTSid, backupTRX) } tn/BSC/BSCid O+ on 3*radioLinkFailureAlert(BTSid, BSCid) mpd { increaseTX_power() } tn/BSC/BSCid Needed Authorisations A+ mpd { increment_cellHysteresisValue(); increment(); increment_locationUpdatesFreq(); reconfigure_add(); increaseTX_power(); decreaseTX_power(); set_RF_params(); enable(); disable() } @tn/BSC

relationships: rel/BNO-BNoR; rel/TSE1-BNoR; rel/NEA-BNoR/NEA1-BNoR; rel/NEA-BNoR/NEA2-BNoR

147

Chapter 8


Role instance Base Network Operator (BNO) BNO mpd: pd/BNO policies:

path: roles/BNO

class: /tr/rr/rc/BNO

O+ on VLR_failure s:mpd {s.restart_VLR() ; check_consistency() } tn/VLR

O+ on MSC_failure s:mpd { s.restart_MSC() } n/a A+ mpd { check_consistency() } tn/VLR Circuit failure between the MSC and the BSC pol_a O+ on A_failure(circuit x, BSCid) mpd { reset(); } tn/BSC/BSCid pol_b O+ on A_failure(circuit x) mpd {block_circuit(x) } tn/MSC A+ mpd {block_circuit(); unblock_circuit() } tn/MSC Security and Subscriber trace O+ on imsiConfidentialityFailure(radiopath r) mpd { lockRadioPath(r) } tn/MSC A+ mpd { lockRadioPath() } tn/MSC

concurrency-constraints: /* instantiation not needed */ relationships: rel/BNO-BNoR; rel/NEA-BNO/NEA1-BNO; rel/NEA2-BNO

8.8.3 Relationship Instances Relationships do not require instantiation of the interaction protocols since protocols are specified in terms of the local name of the roles in a relationship, e.g., R1, R2. Furthermore, policies that have either a relationship object, a related role, or a specified target can be implicitly instantiated. Their subject is the MPD of one of the related roles and their target is determined from the references to related roles, or the relationship object itself. In the following, we have represented the instantiated relationships, with automatically instantiated policies written in italics. Interaction protocols have been omitted and, as with role instances, we only specify one instance when in reality multiple instances are needed.

Relationship between HD1 and TSE1 role instances path: rel/HD-TSE/HD1-TSE1 R1:roles/HD/HD1 Policies

class: /tr/rr/ec/HD-TSE R2:roles/TSE/TSE1

O+ on MS_error(t) pd/HD/HD1 { send(R2,MS_error, IMSI) } rel/HD-TSE/HD1/TSE1 A+ pd/HD/HD { send() } rel/HD-TSE/HD1/TSE1

148

Chapter 8


Relationship between HD1 and TSE1 role instances path: /rel/TSE1-BNoR R1:roles/TSE/TSE1 Policies

class: /tr/rr/ec/TSE-BNoR R2:roles/BNoR

O+ network_fault() pd/TSE/TSE1 { send(R2, BTS-fault) } rel/TSE1/BNoR A+ pd/TSE/TSE1 { send() }rel/TSE1/BNoR

Relationship between the Base Network Operator and its Radio counterpart path: /rel/BNO-BNoR R1:roles/BNO

class: /tr/rr/ec/BNO-BNoR R2:roles/BNoR

Relationship between NEA1 and the BNO path: /rel/NEA-BNO/NEA1-BNO R1:roles/BNO Policies

class: /tr/rr/ec/BNO-NEA R2:roles/NEA/NEA1 np1: O+ every 1*day pd/NEA/NEA1 { report} pd/BNO

Relationship between NEA1 and the BNoR path: /rel/NEA-BNO/NEA1-BNoR R1:roles/BNoR Policies

class: /tr/rr/ec/BNoR-NEA R2:roles/NEA/NEA1 np1: O+ every 1*day pd/NEA/NEA1 { report} pd/BNoR

149

Chapter 8


8.9 Chapter Summary This scenario has outlined the use of role and relationship classes for creating and instantiating an organisational pattern for cellular network management at the local (branch) level. It has enabled us to show some of the main features of the role object model and, in particular: •

how role classes can be defined in terms of policy templates,

•

how relationship classes and their associated interaction protocols can be defined,

•

how inheritance can allow reuse of specifications and inherited elements can be overridden,

•

how inclusion of references to relationship classes in role classes constrains the instantiation process and requires creation of given organisational patterns.

However, several lessons have also been learnt from the development of this case-study regarding the adequacy of the role model and policy notation for distributed management. A case difficult to model in our role framework arises when a large number of managers perform the same operations on the same target objects. For example, there may be a large number of helpdesk (HD) staff updating customer service information in the home location register (HLR). The obligation policies in each HD role may be different since actions may be triggered by events originating from different event disseminators. However all help-desk staff will require the same access rights. This can be specified either as several authorisation policies that are part of roles or as a single authorisation policy applying to a group of managers. In the latter case, the specification is said to be “optimised”, but this optimisation has also several disadvantages which have been enumerated in this chapter. The references maintained by role classes to relationship classes and vice-versa, have proved to be very useful as constraints on the instantiation process when role and relationship instances are created for the management of an organisational domain (e.g., branch). These associations effectively shape an organisational pattern which can be instantiated for all similar domains in the organisation e.g., all branches of the cellular network. They act as constraints since they do not completely determine the instantiated structure and leave enough flexibility to tailor the structure to the specifics of each domain. For example, the number of instances of the NEA role class and their relationships to the BNO and BNoR roles was decided when instantiating the structure (Section 8.8). However, this also outlines a potential limitation of the framework. In the current model it is not possible to associate an arbitrary desired cardinality with the references. For example, it is not easy to specify that a BNoR role instance must participate in at least (or at most) 20 relationships with different NEA role instances. This suggests that a cardinality be associated with each reference.

150

Chapter 8


This case-study has also outlined potential shortcomings of the policy notation. Although within policies we have specified target object paths to be resolved at run-time, e.g., O+ on BTS_malfunction(BTSid, BSCid) mpd { forceHO(BTSid); barr-cell(BTSid) } @tn/BSCid this is not currently permitted by the policy notation. The case-study has also outlined the usefulness of: •

using aliases for objects in the domain structure in order to use only “local” paths in the specification.

•

grouping position domains in a similar domain structure but separately from roles to apply a common policy.

Management procedures to be performed in response to failures in the system may require management activities to be performed by different managers which interact and coordinate their actions. Thus, the ability to automatically initiate interactions from policy activities and the ability to trigger policy execution as a result of an interaction is essential. Although the current model offers these possibilities, the framework may need to be enhanced for this purpose. One of the potential problems of any role object model is that relationships may outnumber roles. However, as this scenario has shown, the amount of information necessary to instantiate a relationship is minimal. Nevertheless, the specification being in a textual representation and being “planned” rather than being an evolving process in which policies and classes are developed incrementally, has prevented us from taking advantage of all features of the model. In particular we have not fully used Meta-policies or constraint specification. Also, the GSM specifications refer to standardised low-level application interfaces and not to higher-level management procedures and tools which are implemented in a network-specific way. This has made it difficult to factor out policies from the available material.

8.10 Glossary of abbreviations Role Classes BNO – Branch Network Operator BNoR – Branch Network Operator for Radio transmission equipment only HD – Help-Desk NEA – Network Element Administration for on-site management NO – Network Operator for the entire VirtuaCom network

151

Chapter 8


RNO – Regional Network Operator RSM – Regional Systems Management SM – Systems Manager for the entire VirtuaCom network TSE – Telephone Service engineer GSM BSC – Base Station Controller BSS – Base Station Sub-system BTS – Base Transceiver System EIR – Equipment Identity Register GMSC – Gateway MSC HLR – Home Location Register IMEI − International Mobile Equipment Identity IMSI − International Mobile Subscriber Identity MS – Mobile Station MSC – Mobile Switching Centre NE – Network Element OMC – Operations Management Centre OMC-R – Operations Management Centre for Radio equipment VLR – Visitor Location Register

152

Chapter 9 Discussion

Throughout this thesis, we have adopted a modelling approach by exploring the various issues, introducing new concepts and defining their implementation as requirements were identified. It is nevertheless important, at this point, to locate the model in the context of related research into role-based systems. In particular, a comparison is needed with the two main current efforts, namely the Enterprise Viewpoint of the ODP Reference Model and recent work on Role-Based Access Control. Furthermore, this chapter adopts a critical view of the framework examining its limitations, deficiencies and inadequacies. Lessons to be drawn from the construction of the framework are then explored in a second step. This chapter also addresses other issues relating to the implementation and examines aspects such as performance, scaleability and distribution.

9.1 Relationship to relevant related work With respect to fundamental role theory, our framework preserves the basic definition of a role as a set of rights and duties. Duties are specified as positive obligation policies and rights as (positive or negative) authorisation policies. Furthermore, negative obligation policies specify actions that managers must refrain from doing. Although policies are a constrained form of programming, they do not define an execution model for the agent that interprets them. This approach is fundamentally different from work such as (Pernici, 1990) or (Skarmeas, 1994) where agent execution is entirely determined by the specification. Most of the work on CSCW and OIS aims at providing support for “office” activities. Therefore, it emphasises the need to coordinate activities through interactions, which are used as support for communicating implicit information (Speech Acts) and for ensuring concurrency. On the

153

Chapter 9

Discussion

contrary, policies specify management activities to be performed in response to changes in the system. The work described in (Singh, 1992a&b) is the most complete role-based framework. However, its scope is limited to synchronised multi-party interaction between roles; it does not cater for asynchronous event notifications or alarms originating inside the system. Our model considers essentially asynchronous interaction, both with the system and between managers, and implements synchronisation through concurrency constraints. Also, Singh’s work does not consider authorisation or access rights, and subsequent efforts have been driven towards providing process models for office activities (Rein, 1992b & 1993). With the exception of the work of Singh and Rein, CSCW and OIS have no explicit definition, or representation, of the concept of role. Both the Enterprise Viewpoint of the ODP Reference Model (ODP-RM) and Role-Based Access Control have been the subject of increasing efforts in recent years and offer an explicit representation for the concepts of roles and policies. Therefore, a more detailed comparison with these studies is needed.

9.1.1 The Enterprise Viewpoint of the ODP Reference Model The Enterprise Viewpoint of the ODP Reference Model is still the subject of many refinements. With the exception of a few concepts, most of the characteristics of this viewpoint are not standardised yet and guidelines on how to use the Enterprise Viewpoint to model organisations are scarce. Thus, the perspective and comparisons presented here reflect the author’s interpretation on the use of the foundation concepts. The primary building blocks of organisational structure in the Enterprise Viewpoint are not roles but communities. A role is a participant in a community and its behaviour and objectives are determined by the contract of the community. Therefore, a contract is a specification of desired (or expected) behaviour of the participants necessary to meet the community’s objective. Any enterprise objects (including communities) can play a role. Therefore, communities are essentially used in the Enterprise Viewpoint as a means of partitioning the scope of activities and the goals of the enterprise. Consider, for example, an enterprise sub-divided in marketing, personnel, production and engineering departments (Figure 9.1). Each department fulfils part of the objectives of the enterprise and is subject to the policies of the enterprise. Thus, each department has a role in the Enterprise community. The Engineering department is itself a community which contains the research, testing, implementation and architecture roles. Each role is played by another community, which in turn defines other roles. Ultimately the roles in the “leaf” communities are played by individuals. Several observations can be made about this simple example. First, that a role is not considered as in its Role Theory definition but as in its common understanding, i.e., the role of an actor in a

154

Chapter 9

Discussion

play. Second, that no distinction is made between the “leaf” community which is composed of organisational roles (i.e., roles according to role theory definition), and other composite communities. Finally, communities are a means of encapsulating enterprise objectives with the “abstract” actors that ensure their achievement. The enterprise, including resources, managers and their objectives, can then be hierarchically decomposed in communities.

Marketing

Personnel

Enterprise Production

Engineering

p la

Research

ye

db y

Engineering Implementation

Analyst

by ed y a pl

Prog 2

played by

Figure 9.1

Architecture

Prog 1

Implementation Leader

Testing

Manager

Enterprise Viewpoint Communities

A simple analogy with the concepts described in this thesis would be to consider a community as a domain of enterprise objects together with the enterprise objectives or goals fulfilled by the objects (i.e., abstract policies). Yet, for any given enterprise, there are several possible domain decompositions (see also Section 3.3.1). For example, in addition to functional departments the enterprise could be sub-divided according to the products it manufactures. The enterprise viewpoint would thus need to cater for multiple ways of composing and decomposing organisational objectives. However, this does not seem to have been investigated in detail in the current documents (ODP-RM, 1997). In order to avoid the multiple decomposition problem, let us assume an enterprise composed entirely of “leaf-level” communities. Each community defines a set of roles played by “atomic” enterprise objects. Two questions still arise. In this thesis, we have made a distinction between managers (which implement the policies) and the target managed objects (to which the actions specified in the policies apply). This would translate to the Enterprise Viewpoint in terms of actor roles and artefact roles (Section 3.5.3). However, a manager performing activities specified by policies, can itself be the target of other management activities. The Enterprise Viewpoint does

155

Chapter 9

Discussion

not specify if an actor role can also be an artefact role within the same community. A second question arises from the distinction made in this thesis between roles and relationships. In the Enterprise Viewpoint, the concept of role is subsumed into the concept of community. To some extent, it can be argued that a ‘community’ corresponds closely to the concept of relationship in this thesis. An Enterprise Viewpoint role corresponds then to a participant in the relationship with its associated rights, duties and interaction rules. Relationships specify the policies each participant must enforce and the interaction protocols, which regulate the exchanges of messages. Yet, in the framework described in this thesis a single organisational role can participate in different relationships, which span different domains. Thus, the organisational role plays different roles (in the Enterprise Viewpoint meaning) whereas in the Enterprise Viewpoint, the scope of a role is restricted to the community that defines it. Therefore, a role defined in one community cannot play a role defined by another community and cannot be related to a role outside the community. This leads to a multiplication of the number of communities and of roles associated with a manager. Therefore, replacing a manager in the organisation requires a large number of ‘role’ assignments. There is also a substantial difference between ‘policy’ in this thesis and Enterprise Viewpoint policies, which are based on Deontic Statements. Deontic statements are essentially the obligation, permission and prohibition operators defined in deontic logic. Yet theses operators have several shortcomings. For example, the inter-definability axiom mentioned in section 7.5 cannot be applied for distributed systems management since all invocations that require authorisation are not specified as obligations. Furthermore, paradoxes can be proved in most deontic logic frameworks which limits the usefulness of the logic for analysing policy-based specifications. Finally, deontic logic adopts a very static view of the system expressing what is permitted, forbidden or obliged. The obligations and authorisations specified in this thesis have a more dynamic view and attribute responsibility explicitly. Variants of deontic logic try to address some of these issues, but there does not seem to be a framework successfully addressing all the problems that is mature enough for policy specification in distributed systems management. A full discussion on deontic logic frameworks would be outside the scope of this thesis. The Enterprise Viewpoint of ODP-RM is still in its infancy. Although it rigorously defines a set of inter-related concepts, the underlying model and specifics of the definitions remain to be refined. In particular, the assignment model of individuals to roles, the task representation model, and the enforcement of roles and policies require more attention.

156

Chapter 9

Discussion

9.1.2 Relationship to Role-Based Access Control (RBAC) There are two substantial differences between the model described in this thesis and classical RBAC models as described in (Sandhu, 1996; RBAC 1995). The first is the absence of the concept of obligation in the RBAC model and the second relates to the inheritance model between roles (Lupu, 1997a). RBAC models the rights of the users in a system in terms of roles. Role-Based Management as presented in this thesis models users’ rights and duties. Thus, RBAC is a subset of role-based management. Yet the two have taken substantially different approaches. In Role-Based Management, roles are derived from organisational specifications. They are composed of obligation and authorisation policies, which are then interpreted and enforced in terms of the access control model of the system and invocation model of the agents (Figure 9.2). RBAC has taken a different approach by considering a system in which roles are essentially an indirection between a set of users and a set of permissions. Thus, while role-based management has adopted a “top-down” approach to defining roles, RBAC has concentrated on a “bottom-up” approach which optimises the specification of permissions in the system (Figure 9.2). It is important to note that, in many RBAC models, permissions include the specification of both target object and access method (e.g., read(), write(), update()). ●

Positions

Roles

● ●

organisational policy procedures job descriptions

read(); write()

Permissions Users read(); write() read(); write() read(); write()

read(); write()

Role Based Access Control (RBAC)

Figure 9.2

Role Based Management (RBM)

RBAC and RBM: different approaches

The absence of obligation policies in the RBAC model affects the model indirectly, in that it does not explicitly modify the role model but results in a different manner of using roles. In the scenario described in Chapter 8, several instances of the help-desk staff role within a branch were

157

Chapter 9

Discussion

responsible for dealing with customers. Each help-desk staff has positive obligation policies, which may be triggered by different event disseminators. Yet, on a new service subscription the same action is performed on the same object, i.e., update the Home Location Register. Therefore, while having different obligation policies, all help-desk staff have the same authorisations and in RBAC only one role would be specified. Thus, in RBAC, there is no difference, at the specification level between a role, to which multiple managers have been assigned, and the set of permissions associated with a group. This has often led to confusions in the RBAC community. The second difference between RBAC models and the framework defined in this thesis is in the use of inheritance. As RBAC has evolved by using roles to make efficient use of permissions, the inheritance model is geared towards reuse of permissions between role instances rather then specialisation of class objects from which multiple instances are created. If we consider the example of nurses in a hospital, the following comparison between the two models can be made (Figure 9.3). In the framework described in this thesis (left part of the figure), inheritance is used to specialise role classes. Yet, if two instances of classes related by inheritance are created within the same ward, inherited policies are instantiated independently for the two roles. Hence, the access rights to the same target objects (i.e., the patients in the ward) are not inherited between the instances. In RBAC (right part of the figure) two role instances (e.g., nurse and specialised nurse) in the same ward can inherit access rights from one another. However, nurses in different wards cannot be created from a class specification parameterised by target objects. The RBAC approach is partly due to the fact that permissions include both the access method and the target objects. Thus, targets cannot be parameterised.

Role Class

Role Instance

Ward 2

Role Class

Role Instance

No sharing of permissions between instances in the same application domain

Figure 9.3

Ward 2

Role Instance

read();write()

Role Instance

No common specification

Multiple uses of inheritance

It would be feasible to support the RBAC approach in our model through the concept of an application domain – the ward in this example. A class-based inheritance model then provides the means to simplify and reuse role specifications, e.g., a paediatric surgical nurse role class can inherit from a paediatric nurse role class as shown in Figure 9.4. However, if two instances are

158

Chapter 9

Discussion

created, for the same target (application) domain (e.g., Ward 3), from classes that have an inheritance relation between them, then access rights can be inherited between instances. nurse

Role Instances Ward 3

specialised nurse

paediatric nurse

Ward 3 paediatric nurse

surgical nurse

paediatric surgical nurse

Figure 9.4

instantiation

Ward 3 paediatric surgical nurse

Instance and Class inheritance

The usefulness of supporting both instance level inheritance and class level inheritance may however be questioned. While several roles may have the same access rights within the system, they will rarely have the same obligations; since this implies managers perform the same activities at the same time and in identical conditions. For example, the paediatric surgical nurse in Figure 9.4 may inherit the obligation to administer analgesics from the paediatric nurse. Since both nurses are in the same ward, analgesics will be administered twice to the same patients. Furthermore, supporting different forms of inheritance also makes the model more difficult to understand and complicates the support tools. There are other differences between the role model described in this thesis and the model defined in (Sandhu, 1996). In particular, Sandhu considers the use of sessions to allow a manager assigned to multiple roles, to combine the access rights of different roles in one session. Our framework requires a complete separation of context between the actions of a manager in different roles. Also, Sandhu considers the use of Administrative Roles that specify access rights to role objects. Since, in our framework, roles and policies are implemented as objects, access rights and obligations can be specified in terms of other policies and roles. The framework is in this sense self-managing.

Recapitulation The framework defined in this thesis adds the concept of policies, which specify both duties and access rights, to most of the work originating from the OIS and CSCW communities. In addition to the use of interaction between managers to support collaboration, the roles described in this thesis specify the actions to be taken in response to events occurring in the system. Furthermore, the approach taken to interaction protocol specification expresses rules that take the history of the

159

Chapter 9

Discussion

interaction into account. Most studies on office automation and collaborative work concentrate on the support and knowledge that can be built from the interaction (e.g., SpeechActs) rather than on the interaction protocol specification itself. These studies are complementary to the framework described in this thesis. Speech Acts can be added because the messages exchanged during the interactions are typed. The roles described in this thesis are fundamentally different from the concept of role adopted in the Enterprise Viewpoint of the ODP-RM. While both frameworks consider rights and duties applied to roles, the Enterprise Viewpoint concept of role is more abstract and applies to any object (enterprise object). The Enterprise Viewpoint still requires much refinement. Role-Based Access Control studies have fostered complete role models, which differ from the framework defined in this thesis in more technical aspects. Two main differences are in the use of obligation policies (which are not considered in RBAC) and in the use of inheritance. RBAC frameworks use inheritance as a means of reusing permissions, while, in our framework inheritance implements specialisation of role classes.

9.2 A critical evaluation of the framework Although the framework described in this thesis achieves many of its initial goals, in terms of the task representation model, assignment model, and role specification, several aspects must still be improved. This section outlines some of them. Although the policy notation has many shortcomings, we will not comment on them here as possible amendments to the notation have not been discussed in this thesis.

9.2.1 Policy templates and Type issues The relationship between policy templates and “abstract” policies has not been given particular attention. A policy template, as defined in this thesis, is an abstract policy. However, it is also a particular abstract policy since its refinements: (1) are all “leaf-level”, implementable, policies and (2) do not refine the abstract policy but are a mere instantiation of the policy. Typing issues have been ignored in defining policy templates as they were during the specification of policies themselves (Marriott, 1997). However, the use of policy templates could be greatly improved by specifying type restrictions on the trigger, subject and target. For example, a policy template could be specified as: policy mode [ event type : domain ] subject type : domain { actions } target type : domain

160

Chapter 9

Discussion

This would have the advantage of placing two types of restriction on the policies created from a template. One would restrict a policy to apply to objects of a given type while the other would restrict a policy to apply to objects within a given domain, e.g., branch, department. These restrictions can also simplify policy-based specification.

9.2.2 Relationships and Interactions The interaction protocol specification (defined in Section 5.3) is based on regular expression matching of the sequence of message types exchanged in the current interaction. This approach offers several advantages: it permits a rule-based specification of protocols, and rules can be specified with regard to the previous history of an interaction. However, with the exception of the type, the format of a message has not been specified. Consequently, a notation for the specification of guards, in terms of message content, has not been defined. Protocol rules triggered by regular expression matching are less intuitive to specify and the “flow” of messages during an interaction is more difficult to follow. This is why rules could be generated from a network transition diagram such as the one used in (de Greef, 1992). A more general criticism can also be made of relationship specification. Current notations allow relationships with a fixed number of participants to be specified. It is therefore not possible to specify relationships between help-desk staff and a variable number of customers. Instead, a different relationship has to be instantiated for each customer role. There are no inherent limitations, in either the policy or interaction protocol notation that prevent the implementation of relationships with a variable number of participants. However, specification of the participant roles and the enforcement of the relationship specification would need to be changed. The interaction protocols defined in this thesis do not cater for partial failures and loss of messages. However, this criticism would also be valid for most of the related work in CSCW or OIS, which generally presume that message-loss is prevented by the messaging infrastructure.

9.2.3 Constraint model In the framework described in this thesis, both structural and concurrency constraints have been included in role specification. Furthermore, constraints can be included in relationships and then apply to policies which are enforced by the related roles. However, there is currently no means of specifying constraints across unrelated roles and, in particular, no global constraints can be specified. Two problems need to be solved to address these issues: (1) the fact that constraints can apply to potentially all the policies and roles of an organisation and (2) determine which component(s) must enforce the constraints. Partial solutions can be adopted by:

161

Chapter 9 •

Discussion

Specifying within a constraint (e.g., Meta-Policy) its scope of application (i.e., the domain of policies and roles to which it applies).

•

Checking some of the constraints within the policy and role specification tools. The conflict detector has been used to experiment with Meta-Policies in this fashion. However, since domain membership may change at run-time, this cannot ensure constant enforcement of the constraint.

•

Enforcing constraints (e.g. separation of duty) within the access control mechanisms.

However, a framework for the distributed enforcement of global constraints would require considerable work.

9.2.4 Conflict analysis There are some criticisms regarding the conflict analysis aspects. The main one would be that the problem has only been partially addressed. In Chapter 7 we established: •

a clear distinction between modality conflicts and application-specific conflicts

•

the need for precedence relationships in order to ensure a flexible specification, and to cater for an unlimited number of exceptions to a policy, which cannot be foreseen

•

the need for an external specification for detecting application-specific conflicts.

However, many precedence relationships can be established in the case of modality conflict between policies. Among these, we have used domain-based nesting (or the specificity principle) since it seems the most intuitive for a domain structure. Nevertheless, this precedence relation does not apply successfully in all cases. Therefore, in general, there is a need for combining precedence relationships between them. Although some researchers (e.g., Minsky, 1997b) use Meta-level rules in order to define and choose between precedence relations, this only delays the resolution of the problem, as consistency between Meta-level rules must also be ensured. Prakken has studied the problem of combining precedence relations within the scope of legal reasoning (Prakken, 1997). However, the framework proposed requires non-monotonic reasoning and involves two opposing actors (e.g., prosecutor and defence), trying to negate each other’s claims based on a different precedence relation. The conflict detection tool (described in Chapter 7) can only perform static conflict detection. Since domain membership can change at run-time, and constraints within policies may depend on run-time state, it is necessary to be able to detect conflicts at invocation time. This has not been covered in this thesis and is the subject of on-going research.

162

Chapter 9

Discussion

9.2.5 Partitioning In this thesis, we have sometimes referred to concepts such as “application domain”, “organisational pattern” and “organisational structure within a domain”. These expressions betray a shortcoming of our model to partition adequately the organisational scope. Partitioning is the problem that the ODP-RM Enterprise Viewpoint attempts to address by the concept of “community”. In our role-based framework, we have often used domains to partition an organisation. Domains offer the advantage of allowing multiple groupings of the same elements: a domain structure is not a hierarchy but a directed acyclic graph. In particular domains have been used implicitly both for decomposition and for providing multiple views on the same set of objects. However, domains fail to encapsulate the manager and managed objects together with the policies and constraints that apply to them. Enterprise Viewpoint communities do not address this problem completely either since the decomposition and attribution of a community’s objectives to its member roles is not detailed. This issue is further discussed in Section 10.4.

9.3 A critical evaluation of the implementation The implementation of the various concepts has concentrated on the specification and analysis tools necessary to an administrator to define policies, roles, role and relationship classes etc. A full implementation of the User Role Agent could not be achieved due to the lack of an adequate obligation policy interpreter. Furthermore, the policy editor had unacceptably poor performance and had to be completely re-implemented.

9.3.1 Distribution The implementation of the role-based framework is entirely distributed in that all objects including domains, policies, roles, relationships and their respective classes are persistent objects maintained on distributed servers. Orbix was used as the middleware distributed programming environment. The interaction protocol agent was implemented in Java using OrbixWeb, while the specification and analysis tools were implemented in the [incr Tcl/Tk] framework with various extensions written in C++. In particular the conflict detection algorithm (which takes into account domain nesting precedence) has been implemented in C++ in order to achieve better performance. The Tcl based tools interact with the Orbix platform through a Dynamic Invocation Interface extension originally implemented by H. Fossa and D. Marriott and slightly modified for the purpose of this thesis.

163

Chapter 9

Discussion

9.3.2 Scalability and performance Although the framework is distributed, the main bottlenecks to scalability are the analysis tools. In particular, the conflict detection algorithm requires: •

Evaluation of the subject and target scope of each policy. This involves a number of remote invocations to domain objects including the evaluation of the membership of sub-domains.

•

Finding all triple overlaps between policies

•

Comparing policy scope and determining precedence relations.

The complexity of the search for triple overlaps − and therefore of potential conflicts − in a set of 2 n policies is bounded by Cn = n*(n-1)/2 ≅ O(n ). Using a precedence relation based on domain 2

nesting to resolve some of the conflicts may require significant computation during the conflict analysis. In particular, a conflict between two policies P1 and P2 may be resolved by a single policy P3 (as shown in Section 7.3.2) or by several policies which together cover the overlapping sets of P1 and P2. Thus, if we presume that precedence relationships are established while checking for overlaps the complexity is still multiplied by n bringing the overall limit to O(n3). A complete analysis of all the tuples to which a different set of policies apply, requires calculating triple overlaps in all possible sets of policies and has thus a complexity given by Ρ (n) = 2n. However, precedence based analysis is required only for those policies which are in conflict. Therefore, the set of policies analysed is substantially smaller than the initial set of policies checked for conflicts. The complete analysis is not required for detecting conflicts but may be performed in order to determine which policies apply to which agents in the presence of precedence. Since this type of analysis is computationally expensive the administrator must choose a restricted set of policies to be analysed, e.g., policies within a role, between related roles or within a specific domain. The size (in terms of number of policy objects) of the specifications derived from case studies has been reasonably small and therefore the limit of the tools has never been reached. The main limiting factors in both analysis and specification tools was the time required for an Orbix invocation and the time required to display complex [incr Tcl/Tk] widgets. We have measured an invocation latency of 7 msecs on a Sparc SS 20 running Orbix 2.1. This measurement is to some extent misleading in that it was made with a pre-established binding. The binding delay to a remote object, is much larger, in the order of hundreds of milliseconds (binding times of more the 500 msecs have been measured). Although [incr Tcl/Tk] widgets built on this platform ease the development of user interfaces and graphical applications, the Tcl/Tk framework proved to be slow once the application had reached a certain level of complexity. It is not uncommon for complex widgets to have a creation time in the order of a significant fraction of a second. (The first policy editor required 6-10 seconds before starting to edit a new policy.) Since roles may

164

Chapter 9

Discussion

require binding to several policies it would not be possible to achieve a reasonable response-time for the user interface. However, after a number of optimisations and re-implementation of the policy editor, the editing time for any object (e.g. policy, role, relationship) was reduced to a 3-4 seconds. For roles and relationships, this includes the creation of all necessary widgets and context-dependent menus. In comparison, the algorithm for conflict detection requires in the order of a 170 msecs to analyse 16 policies and either detect 11 conflicts (without any precedence relationship) or determine 7 precedence relationships, resolve 9 of the conflicts and detect the remaining 2. This timing also includes adding the precedence relationship edges to the display graph. Note however, that these measurements were for domains with few objects in them, and all domain objects residing on the same host. Newer versions of Tcl/Tk that can be byte-compiled are now available. These versions offer the same ease of application development with vast improvements in performance. However, while Tcl has proved to be a reasonably good choice for a prototype, it also has several shortcomings, which would make it unsuitable for further developments to the framework. In particular the Tcl interpreter constrains the programmer to a single thread of executions. In our framework, many aspects can be run concurrently such as the evaluation of the subject and target scope of the policies, multiple views on the attributes of a role, etc. Thus, a multi-threaded environment would be more suitable. Furthermore, large programs become difficult to manage in Tcl since the language does not enforce strong typing and its Object-Oriented extensions do not provide a rigorous model for encapsulation of private data.

9.4 Lessons learned The framework defined in this thesis (and also its shortcomings and comparison with related work) have led us to draw a number of conclusions regarding role-based frameworks. These identify a set of problems to be solved, architectural choices to be made and techniques that can be used for solving the problems. Roles are an adequate means of structuring the responsibility of managers in an organisation. The initial choice of defining roles as a set of policies with the same subject domain has offered several advantages: •

Roles are defined as a set of rights and duties − which corresponds to the role-theory definition.

•

Managers can be assigned and removed from roles dynamically, thereby acquiring the rights and duties specified within the role.

165

Chapter 9 •

Discussion

Roles define a scope of conflict checking as the set of policies grouped within a role must be consistent (i.e., non-conflicting).

•

Roles are transparent to the policy enforcement level and may therefore be used as only a specification tool.

The need for supporting structured interaction between the managers assigned to roles is emphasised in most collaborative work studies. The specification of interaction protocols has been the starting point for introducing the concept of “relationship” between roles. Relationships have also proved an adequate concept for grouping the rights and duties of managers towards each other. The specification of interaction protocols defined in this thesis is novel. In comparison with most protocols supported in collaborative work environments it presents two main advantages: •

Rules can be dynamically changed similar to policies.

•

Interaction rules can be specified with regards to the past stages of the interaction instance.

Although this approach makes it more difficult to program fully automated agents, it is better suited for defining (constraining) interactions in an environment which includes both human and automated managers. With regards to an approach based on finite state processes the protocol specification described in this thesis has the disadvantage of not being supported by analysis tools. Future work on this topic is currently envisaged. The case-study presented has outlined the importance of the relationship between policy and interaction protocol specifications. Interactions are often initiated as a result of an event (e.g., failure) to which several managers must react in a concerted manner. Also, obligation policies are often triggered as a result of being notified of an event occurrence by another manager, or after an agreement has been reached between two or several managers. Classes are used to reduce the size and complexity of the specifications. Since an organisation is often sub-divided in similar domains (e.g., regions, branches) instances can be created from common class descriptions for each one of the domains. Furthermore, constraints on the policies of a role or relationship may be specified in classes, thus reducing the size and complexity of instance objects. Some of the relationships between roles are required by the nature of the role. For example, the work of every Network Element Administrator must be directed by a Base Network Operator. Maintaining references to required elements in role and relationship classes permits the definition of organisational patterns. As shown in the case-study the pattern may be instantiated in each domain (e.g., branch) and customised to its characteristics (e.g., number of Network Element Administrators in each branch, relationships to the respective Base Network Operators).

166

Chapter 9

Discussion

The problem of conflict detection has been solved in this thesis only in part. Precedence relationships are needed since removing all conflicts between policies may not be desirable or computationally effective. Domain nesting precedence is a promising relation, but a framework in which different precedence criteria may be used is still required. The implementation of the tools described in this thesis was realised using the Orbix environment and Tcl. As Orbix introduces non-negligible performance overheads multi-threaded manager agents and tools are needed. Tcl fails to provide multi-threading, and while it proved to be a good prototyping language it is not suitable for future developments to the framework.

9.5 Chapter Summary This chapter has offered a new perspective on the role-based framework. We have situated the role model in the context of related work and made detailed comparisons with the RBAC and Enterprise Viewpoint approaches. This has enabled us to draw two main conclusions: •

Although specialisation of role classes by inheritance is necessary, in terms of access control an instance-level inheritance of access rights may allow better optimisation of the implementation. This optimisation can be realised only for access rights not obligations.

•

While organisational roles are a useful concept for specifying decentralised responsibilities and grouping of rights and duties, they do not provide an adequate means of partitioning organisational goals and (manager and managed) objects present in the organisation. In our framework, we have used domains to group objects but do not provide sufficient means of partitioning organisational goals and structuring the goal refinement process. Goal partitioning must be done according to several criteria and cannot be restricted to goal decomposition.

In addition to a critical view on the role model, this chapter has also presented a critical view on the implementation of the specification tools and agents. The lessons drawn from the development of this framework point to: •

The baseline definition of a role as a consistent set of rights and duties.

•

The importance of the integration of policies with interaction protocol specification.

•

The use of role and relationship classes with mutual references to each other.

•

The need for precedence relations between policies in order to automatically resolve conflicts and the need for Meta-policies to define application-specific conflicts.

167

Chapter 10 Conclusions

The arguments and examples presented so far have often been based on organisational management and “human” managers. We therefore need to substantiate the claim that role-based management is also applicable to both human and automated managers and summarise the assumptions made about the underlying management system. This thesis set out to address a modest problem: the structuring of devolved control. But has this objective been reached? In addition to answering this question, we summarise the main achievements of this work. Although work remains to be done on a full implementation of the role-based framework, we emphasise here the new horizons our framework has identified and future research directions towards more ambitious goals in network and distributed systems management.

10.1 Relevance to Distributed Systems Management The concepts of role, relationship and policy can be intuitively applied to human managers in an organisation. Although many aspects of an organisation depend on automated or computerised systems, and many business processes are at least partially automated, distributed systems management frameworks attribute responsibility to human managers only. This does not correspond to reality, since automated systems are implicitly invested with both authority and duties. Even the sociologically-based definition of an organisational role, can be applied to automated agents or applications in a computer system. This definition is based on two concepts: norm and expectations. The norm defines what the behaviour of actors in an organisation should be, while expectations develop as a consequence of the assumption that actors are well-behaved, i.e., that they behave as the norm prescribes. Both are true of an automated agent. Organisational policies specify what automated agents and management applications should do (i.e. how they

168

Chapter 10

Conclusions

should behave), and the other managers in the organisation interacting with the automated components develop the expectation that components will abide by the norm. Three characteristics exemplify the difference between human and automated managers although the boundary is not clearly defined: •

for automated agents, activities are programmed and performed identically under the same circumstances,

•

an automated manager does not take the initiative but responds to changes in its environment,

•

a human manager may be prompted for choice between alternatives.

The boundary defined by these characteristics is blurred because an automated agent performing management activities may be supported by more sophisticated computerised systems that have deduction capabilities, take initiatives and make choices. Policies, roles and relationships, as defined in this thesis, are applicable to both human and automated managers. The only part of the specification applicable to human managers alone is the specification of abstract actions. The use of ‘or’ in the interaction protocol rules must be furthermore prevented if automated managers cannot choose between several alternatives. Both policies and interaction protocols are specified as rules, which constrain agent execution but do not entirely define their process model. This allows rules to be applied to human managers, who decide upon their schedule of execution, and to automated managers for which execution is programmed. The underlying system model assumed by the role-based framework is that of remote object invocation. Although CORBA has often been mentioned, no parts of the model are CORBAspecific. Whether CORBA or another remote object invocation environment is used, adapters and abstractions of managed objects that translate method invocations into the appropriate management protocol actions must be implemented. In addition, alarms, events and trap messages received from low-level protocols must be translated into events for use within the GEM monitoring system (Mansouri-Samani, 1997).

10.2 Decentralised control The implementation of decentralised control has been implicit throughout this work. The original perspective (in which management actions are essentially performed by one highly skilled GURU) has been replaced by a perspective where potentially every manager in the organisational structure may be responsible for performing management activities defined by policies.

169

Chapter 10

Conclusions

Control is thus specified by policies, which allow separation of management strategy from the programming of management actions. Organisational roles provide a powerful tool for grouping policies in structured entities to which managers can be assigned and removed. Furthermore, the object-oriented extensions allow incremental extension of organisational structure, either by specialising role classes or by creating multiple instances for different target domains. Relationships add another characteristic to the role framework, grouping policies that relate roles to one another and specifying interaction protocols for collaboration between managers assigned to roles.

10.3 Achievements The problem of structuring devolved control is new to the distributed systems management community. Yet, it is a problem that human organisations have had to face for a long time. The fundamental contribution of this work is in analysing the role-based structure of human organisations, identifying their normative aspects and defining a novel framework suitable for structuring decentralised management responsibility in large-scale distributed systems. Not all the bricks are necessarily new; however, the construction is. The framework defined in this thesis can be used to specify Role-Based Access Control, but could also form a basis for the Enterprise Viewpoint of the ODP Reference Model. Although initially aimed at distributed systems management, the framework is general enough to permit specification of devolved responsibilities at enterprise level in any organisation. We have surveyed the literature on the definition and use of the concept of ‘role’ which covers a broad spectrum of studies from different areas of computer science. To the author’s knowledge this is the first time that such a survey has been made. Throughout the surveyed studies the concept of ‘role’ has often been used in an ad-hoc manner. Therefore, the author’s research contribution has not only been limited to a classification of the presented studies but has also included: (1) identifying the issues which are (or need to be) resolved by using roles and (2) defining the requirements of a role-based framework with particular focus on distributed systems management. Management policies have provided the basic concept for separating the specification of actions and the strategy of management from its implementation. Through their normative specification, they provide the means of specifying rights and duties of managers with regard to target managed objects or to other managers. The ability to dynamically load and retract policies from managers allows changing the behaviour and strategy of management at run-time, without significant interruption of service. Although the policy notation used here has been developed by others, this

170

Chapter 10

Conclusions

thesis is the first study which makes extensive use of the notation. The case-study presented in Chapter 8 is the first example of reasonable size in which the notation has been used. In this thesis, we have defined roles which aggregate policies in the building blocks of the organisational structure. Managers can be dynamically assigned or removed from them, enabling the atomic attribution and removal of responsibility. The main purpose of distributed computer systems is to facilitate the business objectives of the organisation that owns them. In this context, a further advantage of management roles is that they can be identified with organisational roles. The framework defined in this thesis specifies the architectural aspects of a complete role model, which may be invisible at policy enforcement level. When surveying the related work from various subject areas, we have defined a complete model as one that specifies: how roles and relationships between roles are defined, how managers may be assigned or removed from roles (assignment model), how roles are managed (administrative model), how consistency can be ensured and how the specification can be enforced. Most of these issues have been addressed in this thesis. Relationships between roles specify the obligations and rights of managers towards each other and the rules according to which institutionalised interaction and collaboration take place. With respect to the interaction protocol specification, we have introduced a novel approach based on typed messages and rule-based specification. Typed messages offer the advantage of associating the message with an illocutionary value and deriving knowledge about the interaction. Sufficient work exists in CSCW to illustrate how this can be achieved. Rule-based specification allows changing the protocol at run-time with minimal disruption to the interactions. Messages contain the sequence of all message types exchanged in the current interaction and interaction protocol rules are triggered by regular expression matching against the type-sequence. This style of interaction protocol specification is novel and well suited to relationships that involve both human and automated managers, since: •

A protocol is specified in terms of constraints which do not prescribe an execution model for the interacting agents as in the case of multi-agent systems. Protocols for multi-agent systems are generally not applicable to human managers for this reason.

•

The state of the current interaction is implicitly determined from the incoming message. This allows an agent (human or automated) to engage in multiple interaction instances at the same time, not tying interaction state to the agent’s execution state.

Tools for specifying roles and relationships have been implemented. The tools interact with the existing platform providing the domain and policy services. Distributed servers which maintain persistent role and relationship objects have also been developed. Although a full implementation

171

Chapter 10

Conclusions

of the User Role Agent could not be achieved, an architecture for it has been developed and the agent component interpreting the interaction protocol rules has been implemented. The assignment model defined in this thesis caters for several managers assigned to the same role and allows separation of a manager’s actions in the various roles. A manager is assigned to a role by specifying an authorisation policy, to permit the manager adapter object to connect to the User Role Agent (URA) included in the Manager Position Domain of roles. The policies grouped within the role apply to the URA and the adapter object provides an invocation forwarding service between manager and URA. We have also defined Object-Oriented extensions which implement the specialisation of role and relationship classes. Role classes correspond to generic management roles (e.g., engineer, analyst) that can be instantiated in different contexts (e.g., different branches, teams, departments and wards). Classes are also used to constrain the instantiation in terms of types of role (which are required to participate in a relationship) and types of relationship (which need to be created in association with new roles). This constraint allows us to preserve organisational patterns when instantiating groups of roles, e.g., adding a new branch or creating a new team for a project. Although the general principles of object-orientation are not new, the contribution of this thesis has been to apply these principles to role and relationship objects. This has required defining and using the concept of ‘policy template’, choosing and defining how class based inheritance is achieved and elaborating the specification of the role and relationship classes. The use of mutual references between role and relationship classes is a novel and promising approach and its use has been exemplified and tested in the case-study. The tools for role and relationship specification have been extended to cater for the specification of their respective classes and a generalised browser of the relationship between classes, instances and policies has been implemented. The administrative model necessary to manage roles and policies is considerably simpler than in other role frameworks. Sandhu (1996) needs to define a completely separate hierarchy of administrative roles and Singh (1992a&b) defines separate observer roles for this purpose. In our framework, domains, policies and roles are implemented as objects. Thus, access to these objects can be managed by other policies and roles. This considerably simplifies the administrative model. Consistency of a policy-based specification is desirable, since conflicts may arise whenever multiple policies apply to the same objects. We have defined a basic classification distinguishing between modality conflicts and application-specific conflicts. While modality conflicts may be detected by syntactic analysis of the policies, application-specific conflicts require the specification of the conditions which result in conflict. Thus, consistency is defined in terms of both incompatible policies and compliance of a set of policies with external constraints such as

172

Chapter 10

Conclusions

the requirement for separation of duty. Furthermore, in the case of modality conflicts we have identified the need for precedence relationships between policies to cater for exceptions, which arise when some policies apply to more specific sets of objects and conflict with more general policies. Although domain-nesting precedence is not appropriate in all situations, it is the most intuitive and flexible approach for domain based structures. A tool for analysing a set of policies to detect conflicts with (or without) domain nesting precedence has been implemented. A case-study has been used to test the concepts defined in this thesis. It helped determine the usefulness of type-based restrictions in the instantiation of roles and relationships and contributed towards identifying some of the framework’s limitations. The specification of the case study is an achievement per se since many commercial organisations contacted over the recent years do not have documented policy specifications. The case-study was developed based on the current available standards and documentation on the operations, administration and maintenance of GSM cellular networks. The specification of the interaction protocols and the study on the conflict analysis have also been supported by a survey and comparison with related work.

10.4 Future work Our framework opens new approaches to providing consistent enterprise role-based specification. In particular, we have identified a need for partitioning enterprise goals in a manner allowing both goal decomposition and multi-viewpoint perspectives on this decomposition. This complements the current domain-based strategy for grouping objects in the enterprise scope. The ‘partitioning’ problem is closely related to the policy refinement issue. Policies are derived from high-level organisational (enterprise) goals and refined progressively until they reach an implementable form in which they explicitly identify the roles having the responsibility and authority to perform the management actions. Therefore, in their more abstract form, policies are enterprise goals and requirements, e.g., the managing director should protect the assets of the company. Software engineering based requirements analysis techniques and tools have been developed for refining goals and eliciting requirements (Dardenne, 1993, Anton 1996). These techniques could also be used in the context of enterprise goal decomposition and policy refinement. For example, the KAOS method and associated GRAIL environment (van Lamsweerde, 1997), facilitate progressive identification and refinement of goals until constraints can be assigned to individual agents. Conceptual taxonomies, well-formedness rules and elaboration tactics guide the goal elaboration process. The process of policy and goal refinement should accommodate multiple viewpoints (Nuseibeh, 1994) and maintain complex dependency relationships similar to the

173

Chapter 10

Conclusions

problems encountered in requirements traceability. A recently approved EPSRC project will be addressing these issues. The concept of roles as a consistent set of duties and rights can also be used in the context of mobile agent systems. This is necessary since the use of mobile agents leads to variation of trust relationships between agents and the host environment. Obligation policies are necessary in this context in order to ensure integrity of access control policies. This use of obligations − to ensure the integrity of access control − was introduced in a different context by Minsky (1985). The tools for specifying policies, roles and relationships and for performing conflict detection and analysis can be used to specify management policies and organisational structure for existing organisations. Often, existing organisations use the absence of any tools to avoid specifying their policies and attributing responsibilities. New requirements could then be derived for the development of more sophisticated specification and analysis tools. Future work is also needed on the present framework. In particular, once an implementation of the Obligation Policy Interpreter is available, the User Role Agent should be implemented. The interaction protocol framework would also benefit from a higher-level specification tool, to define the initial protocol in terms of a network state diagram. Furthermore, analysis of the interaction protocol rules should be possible by translation to a labelled transition system. This would enable checking for properties such as termination and coverage and also to simulate the protocol. Current tools for labelled transition analysis implemented at Imperial College could be used for this purpose. In order to detect all conflicts in a policy-based specification, a run-time analysis mechanism would need to be defined. In this thesis, we have restricted our study to static policy analysis. An investigation of the concepts for dynamic conflict detection has already started in the form of an MSc project.

10.5 Closing remarks Some of this work has appeared in varying forms, in journal and workshop publications. In particular, an early overview of the specification of roles and relationships has been described in (Lupu, 1997b) and (Lupu, 1997e). Its implications in terms of security, access control enforcement and Role-Based Access Control (RBAC) have been examined in (Lupu. 1995) and (Yialelis, 1996c). The Object-Oriented Extensions to the role framework are described in more detail in (Lupu, 1997c) and the relationships of the framework to related work on RBAC are

174

Chapter 10

Conclusions

examined in (Lupu, 1997a). Conflict analysis issues are described in (Lupu, 1997d) and are the subject of further work.

175

Bibliography

Abrams, M.D. and J.D. Moffett (1995). A higher level of computer security through active policies. Computers & Security, 14 (1995), pp. 147-157. Antón, A. (1996). Goal-Based Requirements Analysis. In Proceedings of the 2nd International Conference on Requirements Engineering (ICRE ’96), Colorado Springs, Colorado, pp. 136-144, IEEE CS Press, April 1996. Austin, J. L. (1962). How to Do Things with Words. Harvard University Press, Boston, 1962. Awischus, R. (1997). Role Based Access Control with the Security Administration Manager (SAM). In (RBAC, 1997), pp. 61-68. Baldwin, R. W. (1990). Naming and Grouping Privileges to Simplify Security Management in Large Databases. In Proceedings of the IEEE Symposium on Computer Security and Privacy, Oakland, California, pp. 61-70, IEEE CS Press, May 1990. Becker K., et al. (1993). Domain and Policy Service Specification. Esprit Project IDSM Deliverable D6 and Esprit Project SysMan Deliverable MA2V2, 1993. Berry, G. and G. Gonthier (1992), The Esterel Synchronous Programming Language: Design, Semantics, Implementation. Journal of Science of Computer Programming, 19(2):87-152, 1992. Bertino, E., E. Ferrari and V. Atluri (1997). A Flexible Model Supporting the Specification and Enforcement of Role-based Authorizations in Workflow Management Systems. In (RBAC, 1997), pp. 1-12. Biddle, B. J. and E. J. Thomas (1979a). Role Theory: Concepts and Research. Robert E. Krieger Publishing Company, Huntington, New York, 1979. Biddle, B.J. (1979b). Role Theory: Expectations, Identities and Behaviors. Academic Press, New York, 1979. Bond, A. H. (1990). A Computational model for organizations of Cooperating Intelligent Agents. In Proceedings of the ACM Conference on Office Information Systems, Cambridge, MA, USA, April 1990. Bußler, C. (1992), Capability based Modelling. In Proceedings of the First International Conference on Enterprise Integration Modelling, Carolina, Ed. C. Petrie, MIT Press, pp. 389-398, 1992.

176

Bibliography Chen, F. and R. S. Sandhu (1995). Constraints for Role-Based Access Control. In (RBAC, 1995), pp. II-(39-46). Chrysanthis, P. K., D. Stemple and K. Ramamritham (1990). A Logically Distributed Approach for Structuring Office Systems. In Proceedings of the ACM Conference on Office Information Systems, Cambridge, MA, USA, April 1990. Clark D. and D. Wilson (1987). A Comparison of Commercial and Military Computer Security Policies. In Proceedings of the IEEE Symposium on Security and Privacy, 1987. Conklin, J. and M. Begeman (1988). gIBIS: A tool for exploratory policy discussion. ACM Transactions on Office Information Systems, 6(4), October 1988. Crowston, K., T. W. Malone and F. Lin (1988). Cognitive Science and Organizational Design: A Case Study of Computer Conferencing. In (Greif, 1988). Dardenne, A, A. van Lamsweerde and S. Fickas (1993). Goal-Directed Requirements Acquisition. Science of Computer Programming, vol. 20, pp. 3-50, 1993. de Greef, P., K. L. Clark, and F. G. McCabe (1992), Towards a Specification Language for Cooperation Methods. In Proceedings of the 16th German AI-Conference (GWAI’92), Berlin, pp. 313-320, 1992. DSOM (1994) Proceedings of the IEEE/IFIP Distributed Systems Operations and Management Workshop, Toulouse, France, October 1994. Elliott, J. (1976). A General Theory of Bureaucracy. Heinemann Press, London, U.K, ISBN 0 435 824 732. Ellis, C. A. and G. J. Nutt (1988). Office Information Systems and Computer Science. In (Greif, 1988). ETSI (1). Digital cellular telecommunications systems (Phase 2); Network Management (NM); Part 1: Objectives and structure of Network Management (GSM 12.00), ETS 300 612-1, August 1996. ETSI (2). Digital cellular telecommunications systems (Phase 2); Network Management (NM); Part 2: Common aspects of GSM/DCS1800 Network Management (GSM 12.01), ETS 300 612-2, August 1996. ETSI (3). Digital cellular telecommunications systems (Phase 2); Subscriber, Mobile Equipment (ME) and services data administration (GSM 12.02), ETS 300 613, June 1996. ETSI (4). Digital cellular telecommunications systems (Phase 2); Security Management (GSM 12.03), ETS 300 614, August 1996. ETSI (5). Digital cellular telecommunications systems (Phase 2); Performance data measurements (GSM 12.04), ETS 300 615, August 1996. ETSI (6). Digital cellular telecommunications systems (Phase 2); Subscriber and Equipment Trace (GSM 12.08 version 4.5.0), ETS 300 627, September 1997.

177

Bibliography ETSI (7). Digital cellular telecommunications systems (Phase 2); Base Station System (BSS) Management Information (GSM 12.20), ETS 300 622, June 1996. Evangelist, M. et al. (1988). Using Raddle to Design Distributed Systems. In Proceedings of the 10th International Conference on Software Engineering (ICSE’88), Singapore, April 1988. Fernandez, E. B., and J. C. Hawkins (1997). Determining Role Rights from Use Cases. In (RBAC, 1997), pp. 121-126. Finin, T. et al. (1993). Draft Specification of the KQML Agent-Communication Language. Issued by the DARPA Knowledge Sharing Initiative, External Interfaces Working Group, June 1993. Available from http://www.cs.umbc.edu/kqml/papers Finin, T. et al. (1994). KQML as an Agent Communication Language. In Proceedings of the 3rd International Conference on Information and Knowledge Management (CIKM’94), ACM Press, November 1994. Finkelstein, A. and H. Fuks (1989). Multi-Party Specification. In Proceedings of the 5th IEEE/ACM International Workshop on Software Specification and Design, Pittsburgh, Pennsylvania, May 1989. Flores, F. et al. (1988). Computer systems and the Design of Organisational Interaction. ACM Transactions on Office Information Systems, 6(2):153-172, 1988. Forman, I. R. (1986a). Raddle: an Informal Introduction. Technical Report Number STP-182-85, Microelectronics and Computer Technology Corporation (MCC), Austin, Texas, USA, February 1986. Forman, I. R. (1986b). On the Design of Large, Distributed Systems. Technical Report Number STP-098-86, Microelectronics and Computer Technology Corporation (MCC), Austin, Texas, USA, March 1986. Fossa, H. (1997). Interactive Configuration Management for Distributed Systems. Ph.D. Dissertation, Imperial College, Department of Computing, London, U.K., April 1997. Fuks, H. et al. (1993). Towards the Requirements for Computer Supported Cooperative Software Design. Design Models, Theories, Research Education and Practice, 27(4), OctoberDecember 1993. Gaines, B. R. (1991). Organizational modelling and problem solving using an object oriented knowledge representation server and visual language. In Proceedings of the International Conference on Organizational Computing, Atlanta, Georgia, USA, November 1991. Georgakopoulos, D., M. Hornik and A. Sheth (1994). An Overview of Workflow Management: From Process Modelling to Workflow Automation Infrastructure. International Journal on Distributed and Parallel Databases, 3(2), Kluwer Academic Publishers, Nov. 1994. Giuri, L. (1995). Role Based Access Control: A Natural Approach, In (RBAC, 1995), pp. II-(3338).

178

Bibliography Goldszmidt, G. (1995). Distributed Management by Delegation. PhD dissertation, Columbia University, New York, 1995. Goodman, R. M. and B. E. Ambrose (1995). NOAA – An Expert System managing the Telephone Network. In Proceedings of the 4th International Symposium on Integrated Network Management, Santa-Barbara, California, pp. 316-327, Chapman & Hall, 1995. Greif, I. (1988). Computer Supported Cooperative Work: A book of Readings. I.Greif, editor, Morgan Kaufmann Publishers Inc., 1988. Griffeth, N. D. and H. Velthuijsen (1993). Reasoning about goals to resolve conflicts. In Proceedings of the International Conference on Intelligent Cooperative Information Systems, Los Alamitos, California, pp. 197-204, 1993. Hamada, T. (1997). Dynamic Role Creation from Role Hierarchy. In Proceedings of TINA’97, Santiago, Chile, November 1997. Heydon, A. et al. (1990). Miró: Visual Specification of Security. IEEE Transactions on Software Engineering, 16(10):1185-1197. Hirschheim E. A. (1996). Understanding the Office: A Social-Analytical Perspective. ACM Transactions on Office Information Systems, 4(4):331-344, October 1986. Hoare, C. A. R. (1985). Communicating Sequential Processes. Prentice-Hall, 1981. IONA (1993), “OrbixTM - A Technical Overview,” IONA Technologies Ltd. Dublin, Ireland, Technical Report PN: PR-TEC-7-5, July 1993. ISO/IEC 7498-4 (1989). Information Processing Systems – Open Systems Interconnection – Basic Reference Model – Part 4: Management Framework Jefferee, T. (1994) Guidelines for the Definition of Managed Objects. In (Sloman, 1994ed) pp. 131-164. Johannesson, P. (1995) Representation and Communication - A Speech Act based approach to Information Systems Design. Information Systems, 20(4):291-303, 1995. Jones, A. J. I. and M. Sergot (1993). On the characterisation of Law and Computer Systems: The Normative Systems Perspective. Chapter 12 in Deontic Logic in Computer Science, J.-J. Ch. Meyer and R. J. Wieringa (eds.), John Wiley and Sons, 1993. Jonscher, D., J. D. Moffett and K. R. Dittrich (1994). Complex Subjects or: The Striving for Complexity is Ruling our World. In Database Security VII: Status and Prospects, pp. 1937, North Holland. Koch, T. et al. (1996). Policy Definition Language for Automated Management of Distributed System. In Proceedings of the IEEE 2nd International Workshop on Systems Management, Toronto, Canada, 1996. Kuhn, D. R. (1997). Mutual Exclusion of Roles as a Means of Implementing Separation of Duty in Role Based Access Control Systems. In (RBAC, 1997), pp. 23-30.

179

Bibliography Lander, S. E. (1994). Distributed Search and Conflict Management Among Reusable Heterogeneous Agents. Ph.D. Dissertation, University of Massachusetts, Amherst, USA. Langsford A. (1994). OSI Management model and standards. Chap 4 in (Sloman, 1994ed) pp. 6993. Larrondo-Petrie, M. et al. (1990). Security Policies in Object-Oriented Databases. In IFIP Database Security, III: Status and Prospects, Elsevier Science Publishers B.V. (NorthHolland). Laufer, C. and H. Fuks (1995). ACCORD Conversation Cliches for Cooperation. International Workshop on the Design of Cooperative Systems (COOP’95), Antibes, France, pp. 351-369, 1995. Lin, Y.-B. (1997). OA&M for the GSM Network. IEEE Network, 11(2):46-51, March-April 1997, Lupu, E. C., et al. (1995). A Policy Based Role Framework for Access Control. In (RBAC, 1995) pp. II-(15-24). Lupu, E. C., and M. S. Sloman (1997a). Reconciling Role Based Management and Role Based Access Control. In (RBAC’1997), pp. 135-142. Lupu, E. C. and M. Sloman (1997b). Towards a Role-based Framework for Distributed Systems Management. Journal of Network and Systems Management, 5(1):5-30, Plenum Press Publishing, 1997. Lupu, E. C. and M. S. Sloman (1997c). A Policy Based Role Object Model. In Proceedings of the 1st IEEE International Enterprise Distributed Object Computing Workshop (EDOC’97), Gold Coast, Queensland, Australia, pp 36-47, October 1997. Lupu, E. C. and M. Sloman (1997d). Conflict Analysis for Management Policies. In Proceedings of the 5th IFIP/IEEE International Symposium on Integrated Network Management (IM’97), San-Diego, eds. A, Lazar, R. Saracco, R. Stadler, pp. 430-443, Chapman & Hall, May 1997. Lupu, E. C., M. Sloman and N. Yialelis (1997e). Policy Based Roles for Distributed Systems Security. In Proceedings of the HP-Openview University Association (HP-OVUA) Plenary Workshop, Madrid, Spain, April 1997. Magee J. and Moffett J. eds. (1996). IEE/BCS/IOP Distributed Systems Engineering Journal Special Issue on Services for Managing Distributed Systems, 3(2), 1996. Magee, J., J. Kramer and D. Giannakopoulou (1997). Analysing the Behaviour of Distributed Software Architectures: a Case Study. In Proceedings of the 5th IEEE Workshop on Future Trends of Distributed Computing Systems, Tunisia, 1997. Malone, T. W. (1985). Computer Support for Organizations: Towards and Organizational Science. Working Paper Number 85-012, Management in the 1990s, MIT Sloan School of Management, September 1985.

180

Bibliography Malone, T. W. et al. (1993). Tools for inventing organizations: Towards a handbook or organizational processes. In Proceedings of the 2nd IEEE Workshop on Enabling Technologies Infrastructure for Collaborative Enterprises (WET-ICE’93), Morgantown, West-Virginia, USA, April 1993. Malone, T. W. and K. Crowston (1994). The Interdisciplinary Study of Coordination. ACM Computing Surveys, 26(1):87-119, May 1994,. Malone, T. W. et al. (1995). Experiments with Oval: A Radically Tailorable Tool for Cooperative Work. ACM Transactions on Information Systems, 13(2):177-205, April 1995. Maly, K. J. et al. (1996). A Privilege Management System for a Secure Network. In Proceedings of the 3rd IEEE International Workshop on Services in Distributed and Networked Environments (SDNE’96), Macau, pp. 147-154, IEEE Computer Society Press, June 1996, Mansouri-Samani, M. and M. S. Sloman (1997). GEM: a generalized event monitoring language for distributed systems. Distributed Systems Engineering Journal, 4(2):96-108, June 1997. Marriott, D. A., M. Mansouri-Samani and M. S. Sloman (1994). Specification of Management Policies. In Proceedings of the 5th IFIP/IEEE International Workshop on Distributed Systems Operations and Management (DSOM’94), Toulouse, France, October 1994. Marriott, D. A. and M. S. Sloman (1996a). Management Policy Service for Distributed Systems. In Proceedings of the 3rd IEEE International Workshop on Services in Distributed and Networked Environments (SDNE’96), Macau, June 1996. Marriott, D. A. and M. S. Sloman (1996b). Implementation of a Management Agent for Interpreting Obligation Policy. In Proceedings of the 7th IFIP/IEEE International Workshop on Distributed Systems Operations and Management (DSOM’96), L’Aquila, Italy, October 1996. Marriott, D. A. (1997). Policy Service for Distributed Systems. Ph. D. Dissertation, Department of Computing, Imperial College, London, U.K., October 1997. Martens, C. and F. H. Lochovsky (1991). OASIS: A Programming Environment for Implementing Distributed Organisational Support Systems. In Proceedings of the ACM Conference on Organizational Computing Systems (COCS’91), Atlanta, Georgia, USA, November 5-8, 1991. Martin, P. et al. (1996) SpeechActs: A Spoken-Language Framework. IEEE Computer, 29(7):3340, July, 1996. McCabe, F. G. and K. L. Clark (1995). April – Agent Process Interaction Language. In Intelligent Agents, vol. 890, Lecture Notes in Artificial Intelligence, eds. N. Jennings and M. Wooldrige, Springer-Verlag, 1995. McLennan, M. J. (1993). [incr Tcl]: Object-Oriented programming in Tcl. In Proceedings of the Tcl/Tk workshop. University of California at Berkeley, California, USA, 1993.

181

Bibliography Michael, J. B. (1993) A Formal Process for Testing Consistency of Composed Security Policies. Ph.D. Dissertation, George Mason University, Fairfax, Virginia, USA. Milosevic, Z. et al. (1995). Supporting Business Contracts in Open Distributed Systems. In Proceedings of the 2nd International Workshop on Services in Distributed and Networked Environments (SDNE’95), Whistler, Canada, June 1995. Milosevic, Z., D. Arnold and L. O’Connor (1996). Inter-enterprise Contract Architecture for Open Distributed Systems: Security Requirements. In Proceedings of the 5th IEEE Workshops on Enabling Technology: Infrastructure for Collaborative Enterprises (IEEE WET-ICE’96), Stanford California, USA, June 1996. Milner, R. (1989). Communication and Concurrency. Prentice-Hall, 1989. Minsky, N. H. and A. D. Lockman (1985). Ensuring Integrity by Adding Obligations to Privileges. In Proceedings of the 8th International Conference on Software Engineering, London, U.K., pp. 92-102, August 1985. Minsky, N. H. et al. (1996). Building Reconfiguration Primitives into the Law of a System. In Proceedings of the 3rd IEEE International Conference on Configurable Distributed Systems (ICCDS’96), Annapolis, Maryland, USA, pp. 89–97. Minsky, N.H. and V. Ungureanu (1997a). Regulated Coordination in Open Distributed Systems. In Proceedings of the 2nd International Conference on Coordination Models and Languages, Berlin, Germany, September 1997. Minsky, N.H. and P. Pal (1997b) Law-Governed Regularities in Object Systems – Part 2: A Concrete Implementation, Theory and Practice of Object Systems (TAPOS), 3(2), John Wiley. Moffett, J. D., D. Jonscher, and J. A. McDermid (1993). The Policy Obstacle Course: A Framework for Policies Embedded within Distributed Computer Systems. Technical Report SCHEMA/York/93/1, Department of Computer Science, University of York, U.K., 1993. Moffett, J. D. and M. S. Sloman (1994). Policy Conflict Analysis in Distributed Systems Management. Journal of Organizational Computing, 4(1):1-22, 1994, Mouly, M. and M.-B. Pautet (1992). The GSM System for Mobile Communications. Published by the authors ISBN 2-9507190-0-7. Nishikawa, S., J. Kikuchi and M. Hasegawa (1992). Mobile Communications Integrated Operations System. NTT Review 4(4):19-22, July 1992. Notargiacomo, L.-A. (1995). Role Based Access Control in Oracle 7 and Trusted Oracle 7. In (RBAC, 1995), pp. 65-69. Nuseibeh, B., J. Kramer and A. Finkelstein (1994), A Framework for Expressing the Relationships Between Multiple Views in Requirements Specification. IEEE Transactions on Software Engineering, 20(10):760-773, October 1994.

182

Bibliography Nyanchama, M. and S. L. Osborne (1994). Access rights administration in role-based security systems. Database Security VIII, Status and Prospects, Proceedings of the IFIP WG11.3 Working Conference on Database Security, Eds. J.Biskup, M. Morgenstern and C.E. Landwehr, pp. 37-56, North-Holland, 1994. Oeser, O. A. and F. Harary (1964). A Mathematical Model for Structural Role Theory, II. Human Relations, 17, pp. 3-17. Oeser, O. A. and F. Harary (1979). Role Structures: A Description in Terms of Graph Theory. In (Biddle, 1979a), pp. 92-102. ODP-RM (1995). ITU-T X.901 | ISO/IEC 10746-1 ODP Reference Model Part 1: Overview. ISO/IEC JTC1/SC21/WG7 Reference Model of Open Distributed Processing. ODP-RM (1997). Working Document for RM-ODP Enterprise Viewpoint and Application Architecture (Canberra Output), ISO/IEC JTC1/SC21/WG7N1203, June 1997. Object Management Group (OMG) (1996). The Common Object Request Broker: Architecture and Specification, Revision 2.0 July 1995, Updated July 1996. OORam (1996). OOram Professional: A Method Guide for Real Time/Telecommunication System Development. Numerica Taskon AS, Oslo, Norway, September 1996. Osborne, S. L. (1997). Mandatory Access Control and Role-Based Access Control Revisited. In (RBAC, 1997), pp.31-40. Ousterhout, J. K. (1994). Tcl and the Tk Toolkit. Addison-Wesley, Reading, Massachusetts, USA, ISBN 0-201-63337-X, 1994. Pell, A. R. et al. (1995). Managing in a distributed world. In Proceedings of the 4th International Symposium on Integrated Network Management, Santa-Barbara, California, Chapman & Hall, 1995. Pernici, B. (1990). Objects with Roles. In Proceedings of the ACM Conference on Office Information Systems, Cambridge, MA, USA, pp. 205-215, April 1990. Peterson, J.L. (1981). Petri Net Theory and the Modelling of Systems. Prentice-Hall. Pitt, J., M. Anderton, and J. Cunningham (1995), Normalized Interaction Between Autonomous agents: A Case Study in Interorganizational Project Management. In Proceedings of the International Workshop on the Design of Cooperative Systems (COOP’95), Antibes, France, pp. 76-95, 1995. Prakken, H. (1997) Logical Tools for Modelling Legal Argument, A Study of Defeasible Reasoning in Law. Kluwer Academic Publishers, Dordrecht, The Netherlands, 1997. RBAC (1995). Proceedings of the First ACM Workshop on Role Based Access Control. Eds. C.E. Youman, R.S. Sandhu, E.J. Coyne, Nov. 1995, Gaithersburg, Maryland, USA. ACM Press, ISBN: 0-89791-759-6. RBAC (1997). Proceedings of the Second ACM Workshop on Role Based Access Control. Fairfax, Virginia, USA. ACM Press, ISBN 0-89791-985-8, November 1997

183

Bibliography Rein, G. L., B. Singh and J. Knutson (1992a). The Grand Challenge: Building Evolutionary Technologies. In Proceedings of the 26th Annual Hawaii International Conference on System Sciences, Information Systems: Collaboration Technology and Organizational Systems & Technology Track, Vol. 4, pp. 23-31. Rein, G. L. (1992b). Collaboration Technology for Organization Design. In Proceedings of the 26th Annual Hawaii International Conference on System Sciences, Information Systems: DSS/Knowledge-Based Systems Track, Vol. 3, pp. 137-148. Rein, G. L., C.W. Holsapple and A. B. Whinston (1993). Computer support of Organization Design and Learning. Journal of Organizational Computing, 3(1):87-120. Rumbaugh, J. et al. (1991). Object Oriented Modelling and Design. Prentice-Hall International Inc., ISBN 0-13-630054-5, 1991. Sandhu, R. S., et al. (1996). Role-Based Access Control Models. IEEE Computer 29(2): 38-47. Schmidt, K. and C. Simone (1995). Mechanisms of Interaction: An approach to CSCW Systems Design. In Proceedings of the International Workshop on the Design of Cooperative Systems (COOP’95), Antibes, France, pp. 56-75, 1995. Searle, J.R. (1969). Speech Acts. Cambridge University Press, 1969. Sen, S. and E. H. Durfee (1994). The role of commitment in cooperative negotiation. In Proceedings of the 2nd International Conference on Cooperative Information Systems, Toronto, Canada, May 1994. Sibley E., J. Michael, R. Wexelblat (1992). Use of an Experimental Policy workbench: Description and Preliminary Results. In Database Security V: Status and Prospects, Eds. C. Landwehr and S. Jajodia, Elsevier Science, pp. 47-76. Sibley E. (1993) Experiments in Organizational Policy Representation: Results to Date. IEEE International Conference On Systems Man and Cybernetics, Los Alamitos, California, pp. 337-342. Silva, A. R., T. Goncalves and F. Rosa (1997). Organization, Information System and Distribution Modelling: An Integrated Approach. In Proceedings of the First Enterprise Distributed Computing Workshop (EDOC’97), Gold Coast, Australia, pp. 57-65, IEEE CS Press, October 1997 Singh, B. (1992a). Interconnected Roles (IR): A Coordination Model. Technical Report Number CT-084-92, Microelectronics and Computer Technology Corporation (MCC), Austin, Texas, USA, July 1992. Singh, B. and G. L. Rein (1992b). Role Interaction Nets (RINs): A Process Description Formalism. Technical Report Number CT-083-92, Microelectronics and Computer Technology Corporation (MCC), Austin, Texas, USA, July 1992. Skarmeas, N. (1993). Roles as Processes in Office Environments. In Final Report, Esprit Project Imagine P5362.

184

Bibliography Skarmeas, N. (1994). A Framework for Multi-Agent Modelling and Office Automation. Second In Proceedings of International Conference on Applications of Prolog, London, U.K., Ed. Leon Sterling, pp. 517-526, April 1994. Skarmeas, N. (1995). Organizations through Roles and Agents. In Proceedings of the International Workshop on the Design of Co-operative Systems, Nice, France, pp.385-404, January 1995. Sloman, M. S. and K. P. Twidle (1994a). Domains: A Framework for Structuring Management Policy. Chapter 16 in (Sloman, 1994ed), pp. 433–453. Sloman, M. (1994b). Policy Driven Management for Distributed Systems. Journal of Network and Systems Management, 2(4):333–360, Plenum Press. Sloman, M. S. (1994c). Management: What and Why ?. Chapter 1 in (Sloman, 1994ed) pp. 433– 453. Sloman, M. S. (1994ed). Network and Distributed Systems Management. Addison-Wesley Publishers Ltd., ISBN 0-201-62745-0, 1994. Sloman, M.S. (1995). Management Issues for Distributed Services. In Proceedings of the 2nd IEEE International Workshop on Services in Distributed and Networked Environments (SDNE’95), Whistler, British Columbia, Canada, June 1995. Smith, R.G., (1980) The Contract Net Protocol: High-level communication and control in a distributed problem solver. IEEE Transactions on Computers, 29(12):1104-1113, 1980. Stallings, W. (1994). Simple Network Management Protocol. In (Sloman, 1994ed), pp. 165-196. Tari, Z. and S.-W. Chan (1997). A Role Based Access Control for Intranet Security. IEEE Internet Computing, 1(5), September-October 1997. Thomas, R. (1997). Team-based Access Control (TMAC): A Primitive for Applying Role Based Access Controls in Collaborative Environments. In (RBAC, 1997), pp. 23-30. Tivoli (1997). Application Management Specification Version 2.0. Tivoli Systems, Austin Texas, November 1997. Twidle, K. P. (1993). Domain Services for Distributed Systems Management. Ph.D. Dissertation, Imperial College - Department of Computing, 1993. Tyndale-Biscoe, S. and B. Wood (1997). Machine Responsibility – How to deal with it. In Proceedings of the First Enterprise Distributed Computing Workshop (EDOC’97), Gold Coast, Australia, pp. 48-56, IEEE CS Press, October 1997. UML (1997). Unified Modelling Language version 1.1, Rational Software Corporation. September 1997. Available from http://www.rational.com/. van Lamsweerde A., R Darimont and P. Massonet (1995). Goal-Directed Elaboration of Requirements for a Meeting Scheduler: Problems and Lessons Learnt, In Proceedings of the 2nd IEEE International Symposium on Requirements Engineering, York, U.K., pp. 194-203, March 1995.

185

Bibliography Velthuijsen, H. (1993) Distributed Artificial Intelligence for Runtime Feature-Interaction Resolution. IEEE Computer, 26(8):48-55, August 1993. Wies, R. (1995a). Using a Classification of Management Policies for Policy Specification and Policy Transformation. In Proceedings of the 4th IFIP/IEEE International Symposium on Integrated Network Management (ISINM’95), Santa-Barbara, California, pp. 44-56, Chapman & Hall, May 1995 Wies, R. (1995b). Policies in Integrated Network and Systems Management: Methodologies for the Definition, Transformation and Application of Management Policies. Ph.D. Dissertation, Fakultat fur Mathematik der Ludwig-Maximilians-Universitat, Munchen, Germany, 1995. Winograd, T. and F. Flores (1986). Understanding computers and cognition: A new foundation for design. Ablex Publishing, Norwood, NJ, USA, 1986. Winograd, T. (1988) A Language/Action Perspective on the Design of Cooperative Work. In (Greif, 1988), pp. 623-653. Wong, R. (1997). RBAC Support in Object-Oriented Role Databases. In (RBAC, 1997), pp.109120. Woo, C. C. (1990). SACT: A Tool for Automating Semi-Structured Organisational Communication. In Proceedings of the ACM Conference on Office Information Systems, Cambridge, MA, April 1990. Yialelis, N. and M. S. Sloman (1995). An Authentication Service Supporting Domain Based Access Control Policies. Research Report DoC 95/13,Imperial College - London, U.K., September 1995. Yialelis, N. and M. S. Sloman (1996a). A Security Framework Supporting Domain Based Access Control in Distributed Systems. In Proceedings of the ISOC Symposium on Network and Distributed Systems Security (SNDSS96), San Diego, California, USA, IEEE Press, Feb. 1996. Yialelis, N. (1996b). Domain-based Security for Distributed Object Systems. Ph.D. Dissertation, Department of Computing, Imperial College, London, U.K., 1996. Yialelis, N., E. Lupu and M. Sloman (1996c). Role Based Security for Distributed Object Systems. In Proceedings of the 5th IEEE Workshops on Enabling Technologies: Infrastructure for Collaborative Enterprises (WET-ICE’96), Stanford University, June 1996. Yemini, Y., G. Goldszmidt and S. Yemini (1991). Network Management by Delegation. In Proceedings of the 2nd International Symposium on Integrated Network Management, Washington DC, pp. 95-107, April 1991. Yu, E. S. K. and J. Mylopoulos (1993). An Actor Dependency Model of Organizational Work – With Application to Business Process Reengineering. In Proceedings of the ACM

186

Bibliography Conference on Organizational Computing (COOCS’93), Milpitas, California, pp. 258-268, ACM Press, November 1993. Yu, E. S. K. (1995). Models for Supporting the Redesign of Organizational Work. In Proceedings of the ACM Conference on Organizational Computing (COOCS’95), Milpitas, California, pp. 225-236, ACM Press, August 1995.

187

Appendix A Syntax Specification

A.1 Policy Notation – EBNF As defined by D. A. Marriott in (Marriott, 1997). In the EBNF of the policy notation which follows, the lexical tokens are denoted by single quotes, e.g. ‘+’, or capital letters, e.g. COMMENT, optionality is denoted by brackets, e.g. [description], and repetition (zero or more occurrences) is denoted by braces, e.g. {‘,’ object}. policy: [description] identifier mode [trigger] subject ‘{’ action ‘}’ target [constraint] [exception] [parent] [child] [xref] ‘;’ description: COMMENT identifier:

IDENT

mode:

‘A+’ | ‘A-’ | ‘O+’ | ‘O-’

trigger:

‘on’ COMMENT | ‘at’ COMMENT | ‘every’ COMMENT | event_expression

event_expression: ‘on’ event_id_label | ‘at’ ‘[‘ time_point_const ‘]’ | ‘every’ ‘[’ time_period_expr ‘]’ event_id_label:

[event_label ‘:’] event_id

event_label: IDENT event_id:

object

time_point_const: time_of_day | weekday | date | time_of_day date | time_of_day weekday time_of_day: INTconst ‘:’ INTconst [‘:’ INTconst] | INTconst ‘:’ INTconst ‘:’ DOUBLEconst weekday:

‘Sun’ | ‘Mon’ | ‘Tue’ | ‘Wed’ | ‘Thu’ | ‘Fri’ | ‘Sat’

date:

day ‘/’ month ‘/’ year

day:

‘-’ | INTconst

month: ‘-’ | INTconst | monthname year:

‘-’ | INTconst

monthname: ‘Jan’ | ’Feb’ | ‘Mar’ | ‘Apr’ | ‘May’ | ‘Jun’ | ‘Jul’ | ‘Aug’ | ‘Sep’ | ‘Oct’ | ‘Nov’ | ‘Dec’

188

Appendix A

Syntax Specification

time_period_expr: period | INTconst ‘*’ period | time_period_expr ‘+’ time_period_expr | ‘(‘ time_period_expr ‘)’ period: ‘year’

‘msec’ | ‘sec’ | ‘min’ | ‘hour’ | ‘day’ | ‘week’ | ‘month’ |

subject:

COMMENT | [dse_label ‘:’] domain_scope_expression

dse_label:

IDENT

domain_scope_expression: ‘any’ | [‘{’] object [‘}’] | ‘*’ [INTconst] object | | domain_scope_expression ‘+’ | domain_scope_expression ‘–’ | domain_scope_expression ‘^’ | ‘(‘ domain_scope_expression object:

‘@’ [INTconst] object domain_scope_expression domain_scope_expression domain_scope_expression ‘)’

OBJECT_PATH | IDENT

object_list: object {‘,’ object} action:

COMMENT | method_call {‘;’ method_call}

method_call: object_method_call | switch_action_element {‘,’ switch_action_element} object_method_call: [dse_label ‘.’] method_name ‘(’ [parameter_list] ‘)’ method_name: IDENT switch_action_element: object_method_call switch_selector:

switch_selector {‘,’ switch_selector} ‘:’

STRINGliteral | ‘default’

target:

COMMENT | [dse_label ‘:’] domain_scope_expression

constraint:

‘when’ COMMENT | ‘when’ logical_expr

logical_expr: logical_expr ‘||’ logical_expr | logical_expr ‘&&’ logical_expr | ‘!’ logical_expr | expression |‘(‘ logical_expr ‘)’ expression: expression operator expression | ‘–’ expression | ‘+’ expression | object_attribute | object_function_call // must return some value – no side-effects | system_attribute | constant | dse_label ‘in’ ‘{’ domain_scope_expression ‘}’ operator: ‘!=’

‘+’ | ‘–’ | ‘/’ | ‘%’ | ‘*’ | ‘==’ | ‘’ | ‘>=’ | ‘

A Role-Based Framework for Distributed Systems ... - Semantic Scholar

A Role-Based Framework for Distributed Systems ... - Semantic Scholar

Suggest Documents

A FRAMEWORK FOR BUILDING DISTRIBUTED ... - Semantic Scholar

A Simulation Framework for Dependable Distributed Systems

Glinda : A Framework for Accelerating ... - Distributed Systems

Agile Framework for Globally Distributed ... - Semantic Scholar

performance assessment framework for distributed ... - Semantic Scholar

Resilient Framework for Distributed Computation ... - Semantic Scholar

Infrastructure Web: A Distributed Framework - Semantic Scholar

A framework for a distributed CAD system - Semantic Scholar

A Security Framework for Systems of Systems - Semantic Scholar

Practical accountability for distributed systems - Semantic Scholar

Type Systems for Distributed Programs ... - Semantic Scholar

Synchronous collaborative systems for distributed ... - Semantic Scholar

Using NetLogger for Distributed Systems ... - Semantic Scholar

Type Systems for Distributed Programs ... - Semantic Scholar

DISTRIBUTED SYSTEMS SUPPORT FOR ... - Semantic Scholar

DISTRIBUTED PARAMETER SYSTEMS WITH A ... - Semantic Scholar

A QoS management framework for distributed ... - Semantic Scholar

OPF: A Distributed Context-Sensing Framework for ... - Semantic Scholar

2001: a framework for distributed simulation ... - Semantic Scholar

timed distributed systems - Semantic Scholar

A large-scale distributed framework for information ... - Semantic Scholar

GPU, a framework for distributed computing over ... - Semantic Scholar

A distributed service oriented framework for ... - Semantic Scholar

A Distributed Framework for Remote Monitoring of ... - Semantic Scholar