Domain Services for Distributed Systems Management - Computing ...

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

Domain Services for Distributed Systems Management

Kevin Twidle

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.

May 1993

1

Abstract Organisational structures evolve and develop rapidly in response to economic, social and technological changes. These frequent changes induce a demand from management on the distributed computing systems which support their organisations. In a very large distributed system there may be millions of objects that have to be managed, making it impossible to deal with in terms of individual components. The domain model offers a solution to manage this complexity by grouping hardware and software components as named objects in an hierarchical structure similar to an hierarchical file system. The domain model can also be used to describe the authority for configuration management using access rules between domains, allowing managers in one domain appropriate access to managed objects in other domains. This thesis describes an object management system supporting the domain model that is fully distributed and scalable and shows how it can be applied to configuration management. Objects may be files, processes, hardware components, groups and even abstractions of organisations or users; all may be managed using the same concepts. One of the key features is the novel approach to user interaction with such large systems. This thesis presents: • the management architecture of a domain service providing a scalable distributed naming service that has no central management and provides dynamically configurable directory services with minimum overheads. The system is scalable to large distributed networks with multiple sources of authority. • the implementation architecture of a domain service including the different components providing distributed support services. The degree of distribution can be chosen by the administrator and dynamically adjusted to suit local conditions. • the technique for translation of access rules into non-centralised access control information that is distributed throughout appropriate sub-trees of the domain hierarchy for speed and reliability. • the federation of independent domain systems allowing them to become aware of each other and to interact whilst maintaining their independent policies. The use of the domain service is demonstrated by showing how domains can be used to partition responsibilities and specify authorisation policy for software configuration management of open systems. Software configuration management can be used in an interactive fashion to inspect distributed application configurations and permits users to make adjustments by altering the binding between component interfaces. The concepts described in this thesis are being used by the SysMan and IDSM Esprit projects.

2

Acknowledgements It is impossible to undertake a piece of work on this scale without the support of many people and I mention below just some of those to whom I am indebted. First and foremost to my supervisor Morris Sloman, one of the hardestworking people I know, who has shown great patience and given much constructive criticism. My thanks are due, not only to Morris, but also to Naranker Dulay, Jeff Kramer and Jeff Magee (in alphabetical order) all members of the original Conic group, with whom I have worked for many years and whose intellectual enthusiasm and friendship I value highly. My thanks also to Jonathan Moffett who was the catalyst I needed to start writing up and who read everything that I gave him so meticulously. The comments of Morris Sloman, Jonathan Moffett, Naranker Dulay and Jeff Magee, who took time to read drafts of this thesis, were much appreciated. Keng Ng was responsible for the design and implementation of ConicDraw the Conic graphical configuration manager. He patiently changed his program again and again to my specifications allowing me to demonstrate the domain system and giving me the screen dumps used in this thesis. To Susan Eisenbach, Anthony Finkelstein, Bashar Nuseibeh and Stephen Crane for their encouragement and support. Last but not least to Jane Neagle for all of the above and for doing my share of the washing-up whenever I used the excuse “I am working on my thesis”. This work has been carried out initially with the support of the DTI/SERC (grant number GR/F 35197) for the Domino Project and later the Esprit SysMan project (project number 7026).

3

To Jane, Jenni, Geoff and Susan

4

Table of Contents

List of Abbreviations

11

List of Figures

12

List of Tables

14

Chapter 1

Introduction

15

1.1

What is Management and why is it Important?............................................15

1.2

Characteristics of Large Distributed Systems...................................................17

1.3

Requirements of a Management System.........................................................18

1.4

Management Domains........................................................................................19

1.5

Objectives of the Thesis.......................................................................................20

1.6

What is new in this thesis? ................................................................................21 1.6.1 Extensions to the domain concept.......................................................21 1.6.2 Domain Service .......................................................................................22

1.7 Thesis Outline .......................................................................................................22

Chapter 2

Distributed Systems Management

24

2.1

Introduction...........................................................................................................24

2.2

Requirements of a Management System.........................................................24

2.3

Management Architectures................................................................................27 2.3.1 OSI Management Framework ..............................................................28 2.3.2 ISO/IEC Management Domains...........................................................29 2.3.3 DEC Enterprise Management Architecture (EMA)..........................37 2.3.4 DEC Enterprise Management Director Domains..............................41 2.3.5 HP Openview ...........................................................................................42 5

Table of Contents

2.3.6 2.3.7 2.3.8 2.4

OSF DME ...................................................................................................44 DOMAINS Project...................................................................................46 OSFA - Object Systems Framework Architecture.............................50

Implementation Approaches.............................................................................51 2.4.1 DEC DNS ...................................................................................................51 2.4.2 Andrew File System (AFS)....................................................................54 2.4.3 ANSAware Trader ..................................................................................55 2.4.4 Internet Domain Name System (DNS) ..............................................57

2.5 Chapter Summary ................................................................................................58

Chapter 3 3.1

The DOME System

60

Domains..................................................................................................................60 3.1.1 References .................................................................................................62

3.2 Domain Relationships.........................................................................................63 3.2.1 Subdomains and Cyclic Structures ......................................................63 3.2.2 Overlapping Domains............................................................................64 3.2.3 Parents and Ancestors ............................................................................65 3.3 Objects......................................................................................................................65 3.4

Interfaces.................................................................................................................66 3.4.1 Object Operations.....................................................................................66 3.4.2 Domain Object Interface Operations ...................................................66 3.4.3 Factory Object Interface Operations .....................................................67

3.5 Management..........................................................................................................67 3.6

Management Policy..............................................................................................68

3.7

Access Rules...........................................................................................................69 3.7.1 Access Rule Inheritance.........................................................................71

3.8

Federation...............................................................................................................72 3.8.1 Context Links............................................................................................73

3.9

Chapter Summary ................................................................................................76

Chapter 4

The DOME Architecture

78

4.1

DOME Managed Objects ......................................................................................78 4.1.1 Attribute Information ............................................................................78 4.1.2 Operations.................................................................................................81

4.2

Domain Managed Object (Domain)..................................................................81

6

Table of Contents

4.2.1 4.2.2 4.2.3 4.2.4 4.2.5 4.2.6

Domain Requirements...........................................................................83 Domain Referencing...............................................................................84 Attribute Information ............................................................................85 Domain Membership .............................................................................85 The User View .........................................................................................85 Operations.................................................................................................86

4.3 DOME Factory Managed Object (Factory).........................................................87 4.4 Access Control .......................................................................................................87 4.4.1 Introduction..............................................................................................87 4.4.2 Access Rules..............................................................................................89 4.4.3 Management Role Objects.....................................................................90 4.4.4 Access Rule Operations - User Interface.............................................92 4.5

User Interfaces .......................................................................................................93 4.5.1 User State Manager (USM)....................................................................95 4.5.2 USM Operations ......................................................................................96 4.5.3 USM DOME Domain Service Operations..........................................97

4.6

Chapter Summary ................................................................................................99

Chapter 5

Examples

100

5.1

Cellular Network Example...............................................................................100

5.2

Conic 5.2.1 5.2.2 5.2.3

5.3

Configuration Management.............................................................................111

5.4

Chapter Summary ..............................................................................................116

Chapter 6 6.1

Simulation of the Mobile Telephone example ................................104 Conic Basics.............................................................................................104 DOME Integration .................................................................................106 Conic Telephone Example...................................................................108

DOME Services

117

Conventions ........................................................................................................117 6.1.1 Operation Names ..................................................................................118

6.2 DOME Objects ......................................................................................................118 6.2.1 Virtual Operations ................................................................................118 6.2.2 Attribute Information ..........................................................................119 6.2.3 General Operations ...............................................................................121 6.2.4

DOME Factory Objects (Factories).......................................................122

7

Table of Contents

6.2.5

Object Destruction .................................................................................123

6.3 Domain Service...................................................................................................123 6.3.1 Domains as Managed Objects..............................................................124 6.3.2 Domain Service Operations................................................................125 6.4 Access Control .....................................................................................................126 6.4.1 Introduction............................................................................................126 6.4.2 Access Rules............................................................................................127 6.4.3 ACEs and Domain Structure Changes..............................................135 6.4.4 Access Rule Operations - User Interface...........................................136 6.5

USM Operations..................................................................................................137

6.6

Chapter Summary ..............................................................................................139

Chapter 7

DOME Runtime Implementation

141

7.1

Objects....................................................................................................................141 7.1.1 Object References...................................................................................141 7.1.2 Parent Set.................................................................................................142

7.2

Domain Service...................................................................................................143 7.2.1 Domain Servers.....................................................................................144 7.2.2 Node Managers......................................................................................147

7.3

Implementation of Access Control Operations............................................149 7.3.1 Access Rule Operations (Mechanism View) ...................................151 7.3.2 Management Role Operations (Mechanism View).......................151 7.3.3 Domain Server Interface to support Access Control .....................151

7.4

Consistency Issues...............................................................................................152 7.4.1 Consistency between Source and Mechanism Versions...............152

7.5

Implementation of the Reference monitor ..................................................152 7.5.1 Search for an Authorising ACE..........................................................152 7.5.2 Matching the Originator ......................................................................153 7.5.3 ADF & AEF .............................................................................................154

7.6

Creating New Managed Objects.......................................................................154

7.7 Chapter Summary ..............................................................................................155

Chapter 8 8.1

Conclusions

157

Revisiting the Requirements...........................................................................157 8.1.1 Management Hierarchy .......................................................................158

8

Table of Contents

8.1.2 8.1.3 8.1.4 8.1.5 8.1.6 8.1.7 8.1.8 8.1.9 8.2

Namespace Management ....................................................................158 Scalability and Single Model...............................................................158 Partitioned Management.....................................................................159 Multiple Management of Common Resources..............................159 Decentralised Management.................................................................159 Adaptability............................................................................................. 160 Security ....................................................................................................160 Fault Tolerance ......................................................................................160

Critical Evaluation and Future Work............................................................161 8.2.1 Access Rules............................................................................................161 8.2.2 Capabilities versus Access Control Entries ......................................161 8.2.3 Concurrent Access and Domain Locking.........................................162 8.2.4 Constraints..............................................................................................162 8.2.5 Cyclic Hierarchies ..................................................................................162 8.2.6 Inheritance Blocking.............................................................................163 8.2.7 Trading.....................................................................................................163 8.2.8 Man Machine Interface ........................................................................164 8.2.9 Future work............................................................................................165

References Appendix A

166 DOME Information Interchange

173

A.1 Details of Domain Service status messages...................................................173 A.2 Object Type Strings .............................................................................................175 A.3 General Object Attributes for all objects.........................................................176

Appendix B

Conic DOME Service Interface

177

B.1 Object Interface ....................................................................................................177 B.2 Domain Interface ................................................................................................179 B.3 Domain Server....................................................................................................181 B.3.1 Domain Server Interface......................................................................181 B.4 Node Manager.....................................................................................................182

Appendix C

Smalltalk DOME Service Interface

9

185

Table of Contents

C.1 Description ...........................................................................................................185 C.2 Starting the Smalltalk Interface.......................................................................187

Appendix D

Mobile Telephone Display States

10

188

List of Abbreviations

ACE

Access Control Entry

ACL

Access Control List

ADF

Access Decision Facility

AEF

Access Enforcement Facility

AR

Access Rule

CMIP

Common Management Information Protocol

CMIS

Common Management Information Service

DCE

Distributed Computing Environment

DME

Distributed Management Environment

DOME

Domain Object management Environment

EMA

Enterprise Management Architecture

MIS

Management Information Service

MMI

Man Machine Interface

MRO

Management Role Object

NFS

Network File System

OID

Object Identifier

OSF

Open Software Foundation

RFS

Remote File System

SNMP

Simple Network Management Protocol

UPD

User Personal Domain

URD

User Representation Domain

USM

User State Manager

11

List of Figures

Figure 2.1 - Management Policy Managed Object ...................................................36 Figure 2.2 - Domain Co-ordinator Managed Object................................................37 Figure 2.3 - Director/Entity Framework....................................................................38 Figure 2.4 - OpenView Operational Model ..............................................................44 Figure 2.5 - DOMAINS’ Recursive Model of Management..................................47 Figure 2.6 - DOMAINS’ Nested Domain Structure................................................48 Figure 3.1 - A domain containing some objects......................................................61 Figure 3.2 - Showing a sub-domain within a domain...........................................62 Figure 3.3 - User view and “Real” view of domains..............................................62 Figure 3.4 - Hierarchical Domain Diagrams.............................................................63 Figure 3.5 - Overlapping Domains.............................................................................64 Figure 3.6 - More complex overlapping domain representations.......................65 Figure 3.7 - Domain and Object Management.........................................................68 Figure 3.8 - Access Rule between Two Domains.....................................................69 Figure 3.9 - Management access to accounts for different departments.............70 Figure 3.10 - Company Accountants’ Access to the Accounts..............................71 Figure 3.11 - Company Accounts Structure with Access Rule Inheritance......72 Figure 3.12a - Interconnecting Two Organisations.................................................74 Figure 3.12b - Interconnecting Two Organisations.................................................74 Figure 3.12c - Interconnecting Two Organisations .................................................75 Figure 3.13 - Standard Domain Naming System ....................................................75 Figure 3.14 - Two Organisations Interconnected with Conventional Names..76 Figure 4.1 - User View of a Domain...........................................................................82 Figure 4.2 - Implementation View of figure 4.1......................................................83 Figure 4.3 - User Representation and User Personal Domains............................86 Figure 4.4 - Example Access Rules..............................................................................89 Figure 4.5 - A Security Administrator Management Role Object .......................91 Figure 4.6 - Composition of the generic Domain Manager ..................................94 Figure 4.7 - The Graphical Domain Manager ..........................................................94 12

List of Figures

Figure 4.8 - Adaptive Naming of Object on Include ..............................................98 Figure 5.1 - The Cellular Network Topology.........................................................101 Figure 5.2 - Managing Service Access for Mobiles................................................102 Figure 5.3 - Showing How Provider A Grants Access to Provider B................103 Figure 5.4 - Provider B’s Namespace Management..............................................104 Figure 5.5 - A Conic module with an interface .....................................................105 Figure 5.6 - A Conic node...........................................................................................106 Figure 5.7 - A Conic node containing a DOME Management Interface...........107 Figure 5.8 - Communication Structure of Conic Telephone Nodes.................108 Figure 5.9 - Base Station Domain Hierarchy..........................................................109 Figure 5.10 - The Mobile Telephone Domain Hierarchy ....................................110 Figure 5.11 - A Great British Domain......................................................................111 Figure 5.12 - Domain Structure for Students.........................................................112 Figure 5.13 - Student’s Exercises................................................................................113 Figure 5.14 - Configuration of a Conic Distributed Application........................114 Figure 5.15 - Access Controls for Group Project ....................................................115 Figure 5.16 - Students’ Context Links to Group Project Domain.......................115 Figure 6.1 - Domain Service Interface .....................................................................124 Figure 6.2 - Example to Illustrate Generating Domains ......................................129 Figure 6.3 - Include and Remove on Domains .....................................................134 Figure 6.4 - Rule R345 and its ACEs.........................................................................135 Figure 7.1 - Object Address Contents and Examples.............................................142 Figure 7.2 - System View of the Domain Service .................................................143 Figure 7.3 - A Distributed Partitioned Domain Service.......................................144 Figure 7.4 - Steps in creating a new object using Unix.........................................155 Figure 7.5 - Steps in creating a new object using a factory...................................155 Figure D1 - Mobile Telephone Layout.....................................................................188 Figure D2 - A Telephone Barred and Connected to a Base Station...................189 Figure D3 - A Telephone Making a Connection...................................................189 Figure D4 - Number Unobtainable and a Ringing Telephone ..........................190 Figure D5 - A Pleasant Telephonic Conversation ................................................190

13

List of Tables

Table 4.1 - Domain Expressions .........................................................................88 Table 4.2 - Example Access Rules.......................................................................89 Table 4.5 - Management Authorities................................................................91 Table 4.6 - Role Types and Authorities ............................................................92 Table 6.1 - Layout of Operation Tables............................................................117 Table 6.2 - Virtual Operations ..........................................................................118 Table 6.3 - Attribute Operations.......................................................................119 Table 6.4 - Object Information Attributes ......................................................120 Table 6.5 - General Object Operations.............................................................121 Table 6.6 - Factory Specific Attributes .............................................................122 Table 6.7 - Virtual Creation Operation...........................................................122 Table 6.8 - Example Creation Operations.......................................................122 Table 6.9 - User’s Create Operations................................................................123 Table 6.10 - Domain Factory Operations ........................................................125 Table 6.11 - Domain Object Operations ..........................................................125 Table 6.12 - Access Rule Propagation Categories..........................................131 Table 6.13 - Access Control Entries for Example...........................................133 Table 6.14 - Access Control Entries after Change..........................................135 Table 6.15 - Access Rule Server Operations...................................................136 Table 6.16 - Access Rule Operations................................................................137 Table 6.17 - Virtual Operations for the User State Manager......................137 Table 6.18 - User State Manager State Change Operations.........................138 Table 6.19 - User State Manager Domain Service Operations...................138 Table 6.20 - User State Manager Domain Service Operations...................139 Table 7.1 - Domain Object Operations ............................................................146 Table 7.2 - Domain Server Operations ...........................................................147 Table 7.3 - Node Manager Operations ............................................................149 Table 7.4 - Domain Server ACE operations...................................................151 Table 7.5 - Scope of Subject Domain Expressions.........................................153

14

Chapter 1

Introduction

The technical problems of building large distributed systems have been partly solved but the effective management of these systems is still a grey area. This thesis is concerned with the services required for the support of management of large distributed systems. It builds on the concepts of Domains [Sloman 1986], Access Permissions [Twidle 1988] and Access Rules [Moffett 1990] identifying the necessary services and providing a practical system for real use.

1.1 What is Management and why is it Important? Management is defined as: “skilful handling, cajolery, the manager(s) of a concern” [OXFORD]. We will refine that definition for application to distributed systems and add to it “the long term monitoring and control of the system” with the aim of maintaining the goals of the system. A distributed system may consist of a variety of types of objects which have to be managed, for example: users and the agents representing users in the system; hardware components such as workstations, mainframes, modems; software components such as processes, threads or files; services such as databases or electronic mail; and the servers which implement them. In a very large distributed system there may be millions of objects, making it impossible to specify management policy for individual objects. Instead it is necessary to specify policy for groups of objects. As more and more organisations are depending on distributed systems to maintain their businesses and they often share resources on common networks it can be seen that multiple independent management is required. Different organisations may want to interact to some degree and this will require co-operative management of a common set of objects.

15

Chapter 1

Introduction

The ISO/OSI Management Framework [Klerer 1988] has identified five management functional areas: configuration management, fault management, performance management, accounting management and security management. Configuration Management is usually defined as the means to identify, configure and control devices on a network. This concept will be extended to include all objects on our network. So, configuration management refers to both hardware and software configuration management. Hardware configuration management provides the ability to collect information relating to the status of the devices and their interrelationships. It also provides support for the ability to set or change operating parameters of, and relationships between, the network devices. Software configuration management supports the allocation of software components (processes) to hardware components and the configuration of the logical bindings between different processes of a distributed application or system. It also includes the monitoring and control functions support similar to hardware configuration but applied to the software components [Dulay 1987, Magee 1993]. This thesis will concentrate on the software configuration aspects of configuration management. Performance management deals with monitoring and evaluation of the performance of applications for the purpose of maintaining a particular quality of service. This function also requires data gathering abilities. The data used to evaluate the performance of, say, the throughput of a particular communications link, can then be used by configuration management to tune the system by modifying attributes accordingly. Fault management refers to the detection and diagnosis of error conditions on a network. Error or alarm messages may be generated asynchronously and fault management may invoke diagnostics to identify faults. Configuration management is utilised for the isolation and recovery of network and system faults.

16

Chapter 1

Introduction

Security Management is the management of security information including detection of security violations and maintaining security audits. Accounting management has the capability of monitoring resource usage and of generating accounting records for charging against the appropriate network accounts. The OSI Management Framework describes resources with a management interface in terms of an object modelling paradigm. The management interface to resources is characterised as a managed object. In this thesis the term managed object is used to indicate an object (a resource or process) which supports a management interface. This interface is independent of any other interfaces that the resource or process possesses for its normal operation.

1.2 Characteristics of Large Distributed Systems Scale Networks can span continents taking in thousands of organisations totalling millions of components such as host computers, software processes, routers and gateways. Independent Authorities Many independent organisations may be connected to common networks. Distributed applications may span these organisations with each organisation having independent authority over parts of the application. The network suppliers will also have control over the network itself. Managers must be able to work co-operatively; there is no central overall authority. Heterogeneity Distributed systems are usually heterogeneous in nature. Hardware products with proprietary operating systems from different manufacturers will be connected to a single network. The networks themselves use a wide variety of protocols and communications mechanisms, both standard and nonstandard. Different languages will be used to create processes, which may cause problems with their interpretation of “standard” types such as integer or real.

17

Chapter 1

Introduction

Physical Distribution Physical distribution of systems have a number of implications. Processes running in a distributed system have disjoint address spaces and rely upon remote communications via explicit message passing. Interprocess transit delays are variable and some time always elapses between one process sending a message and another process receiving it. In addition to this the computers are running asynchronously thus there is no coherent view of the global instantaneous state of the system. Without stopping or freezing everything on a distributed system it is impossible to take a snapshot of the exact state of all the components. Processes may have different views of the state of the system which may result in inconsistent decisions. Reliability In any distributed application, involving two or more co-operating components, there is a chance of partial or total failure either because a component itself fails, its host computer fails or network communications are lost. Some distributed systems are able to cope with most failures in either the host computers or the networks connecting them. Fault tolerance techniques may simply reroute messages or may have to migrate or restart components using a previously checkpointed state. Distributed systems can be more reliable that centralised ones. Components can be replicated with the copies being kept in a cold or hot standby situation. If a component fails then the standby can be started ensuring that the application does not fail.

1.3 Requirements of a Management System The key requirements for a management system are summarised below and explained more fully in chapter two: Management Hierarchy - Management structures in organisations are hierarchical, and so distributed systems management should also be structured hierarchically. Single Model - The management model should be independent of the size of the network.

18

Chapter 1

Introduction

Namespace Management - With many thousand of objects in a network, a local context for names and a way of grouping names together is required. Partitioned Management - Many managers may manage different parts of a distributed application. Multiple Management of Common Resources - More than one manager may manage the same object. Decentralised Management - Management should not require a central service but should be distributed for speed and reliability. Adaptability - Management structures must be flexible and be able to adapt to the changing system. Scalability - The size of a network should not restrict or force users to manage the network in any particular way. Security - Managers must be authenticated to the system and operations that managers can perform on managed objects must be subject to authorisation and monitoring. Fault Tolerance - The management support system must be able to cope with failures.

1.4 Management Domains This thesis introduces and describes DOME (Domain Object Management Environment) which addresses the above issues. It builds on the domain concept [Robinson 1988, Sloman 1989] which supplies a basic model for structuring and management of object names within a distributed system and on access rules [Moffett 1990] which supply a basic model for specifying security. A domain based system needs to be supported with tools giving a high degree of availability whilst maintaining flexibility and security. We will concentrate on the use of domains for support and configuration of managed objects such as Rex Composite Components [Kramer 1991] or Conic Logical Nodes [Kramer 1983] but they can be applied to other distributed operating systems and development environments. Domains offer an important service for Managers and their Managed Objects; they provide the framework for partitioning management responsibility.

19

Chapter 1

Introduction

Domains can group together managed objects which have a common set of management operations or to which a common management policy applies. Managed objects may be grouped in a domain which allows only a limited set of managers access to those objects. Managers themselves can be grouped into domains and the access conditions (rules) specified in terms of domains. Management benefits from domains because domains can represent management positions, managers within these domains holding those positions. For example: a domain of Account Managers and another of Account Records could be created with read and update access conditions permitted from the Account Managers’ domain to the Accounting Records’ domain. This allows the members of the Account Managers’ domain to read and update any of the accounting records in the Accounting Records’ domain. If the individual managers change then the membership of the Account Managers’ domain can be changed without having to change the rules between the individual managers and the individual accounting records. Domains can be used to specify the authority for configuration management; this applies to both hardware and software configuration management. Distributed network components can be grouped into domains to give appropriate access to managers; similarly for distributed application components. An additional function of a domain service is to translate the names of objects within domains to addresses. It is, therefore, necessary to register the names and locations of components in the system. This permits managers and users to locate components for the purpose of status gathering, reconfiguration or any other management operation. For example, components need to be located in order to bind interfaces of new components to interfaces of existing ones.

1.5 Objectives of the Thesis The objectives of this thesis are to provide support for the domain concept and to show how it can be applied to configuration management. It shows how access rules can be decomposed into Access Control Lists and distributed around the domain hierarchy for speed and reliability. It also shows how the federation of independent systems can be achieved without compromising

20

Chapter 1

Introduction

security. The user will be provided with a manageable partitioned namespace with the user’s chosen local names for objects. The user is able to interact with DOME using a Domain Command Shell, a graphical interface and a windowing domain browser. A programming interface is also provided to enable the user to produce managers capable of automatic control of their objects or of self-management. DOME offers name lookup and maintains a distributed database of the domain structure and the name to object mappings. The actual distribution of the domain information is dynamically configurable, being adjusted to the requirements of the local administrators. A Server Subsystem has to exist within the distributed system to support the above; some management functions must exist either as a standard part of managed objects in the system or as agent processes standing in front of the object to be managed. In keeping with the concepts of a distributed system, a distributed set of management processes is preferable to a centralised one to provide support. The domain service is itself a distributed application having no centralised component; access to the service is through agents on host computers. The use of the domain service is demonstrated by applying it to Configuration Management. Configuration Management can be used in an interactive fashion to inspect configurations and make adjustments or as an ordered set of specified changes. Configuration management can make changes to a system at predetermined times or events.

1.6 What is new in this thesis? 1.6.1

Extensions to the domain concept

The domain concept in general has been elaborated during work carried out with Drs. M. Sloman and J. Moffett. In particular, non-policy domain members have been introduced; they make the domain concept more useful for namespace management, thus removing the requirement for an external naming mechanism and enabling different, independent domain systems to become aware of each other and to interact (federation).

21

Chapter 1

1.6.2

Introduction

Domain Service

The Management Architecture based on a Domain Service has been specified, including the Domain Service interface allowing all the domain operations to be performed. The distributed Implementation Architecture for the Domain Service based on local client and distributed servers has been specified. The mapping for security policy into access control has been designed and implemented and mechanisms defined for access control information to be propagated within the distributed domain service. The concepts have been validated with an example application of the Management Architecture applying to configuration management and access control.

1.7 Thesis Outline This chapter has given an introduction to Management issues in relation to large distributed systems and has identified the requirements for such management. Chapter two explains the requirements and looks at existing work that covers various aspects of Distributed Systems Management. Chapter three describes the DOME management environment from the Manager’s point of view and discusses the design decisions which have been made to satisfy the distributed management requirements. The use of DOME is described using some examples in chapter four. Chapter five describes the DOME architecture giving complete descriptions of the design of the underlying DOME services that support the concepts introduced in chapters three and four. Chapter six gives a more formal definition of the DOME component operations. Chapter seven describes the implementation of the DOME environment. Chapter eight provides a critical assessment of DOME examining the degree to which it meets the requirements. The chapter discusses the success of DOME and makes suggestions for further work. 22

Chapter 1

Introduction

The appendices describe implementation information including language specific interface structures to the DOME operations.

23

Chapter 2 Distributed Systems Management

2.1 Introduction This chapter examines the requirements identified in the previous chapter: management hierarchy, single model, namespace management, partitioned management (federation), multiple managers, decentralised management, adaptability, scalability, security and fault tolerance. The current approaches to Distributed Systems Management are then described with respect to Management Architecture and Implementation Approaches.

2.2 Requirements of a Management System Management Hierarchy In any large system or organisation there are many goals to be attained. These range from an overall goal that the Chairman might have such as “This system must run properly” down to the lowest level of management which might be “keep this component running, if it stops, swap it out.” It can be seen that the lowest level goal is a sub goal of the overall goal; the overall goal itself may be split into many intermediate goals for second level management and so on. This is known as Goal Refinement [Moffett 1992] and reflects hierarchical management structures in organisations. Distributed systems management should be structured hierarchically allowing managers to have a small number of goals each of which may generate a set of sub goals for a manager at a lower level. Management is therefore implemented as a hierarchical distributed application using peer to peer protocols for peer management entities and hierarchical protocols for managers at different levels.

24

Chapter 2


Different levels of management in a distributed system include [Digital 1989]: Manual Management - Human management making complex decisions dealing with large scale goals such as optimisation, planning and design. This management corresponds to the higher level aspects of management maintaining the overall goal. Manual management may well discuss problems and make decisions outside the environment of the distributed system. Automated Management - A pre-programmed management object/process in the system making simple management decisions based on monitoring the parts of the system which it is managing. Automated management will normally be configured by manual management and corresponds to the intermediate levels of management. Self Management - This corresponds to the lowest level of management whereby an intelligent managed object can monitor and control itself; such as reconfigure itself if it detects certain conditions. Single Model The management system should be independent of the size of the network. One management paradigm should be applicable to a small in-house network and equally to a large international network of machines. It would not be desirable to have to use one management architecture for a small network and then find that it has to be changed when the network grows more complex. Namespace Management With many thousands of objects in a network it is impracticable to specify management policy for each object separately. Management must be structured to enable groups of components to be managed. Namespace structuring is also required because with so many separate components it would be very difficult to enforce network-wide unique names. Namespace structuring provides a local context for names; users can then choose names that need only be unique within their local context. The naming scheme should be uniform, open-ended and must support federated namespaces i.e. the union of two different organisations’ management systems.

25

Chapter 2


In a distributed system managers and managed objects may come and go; the name directory service must be able to cope with many changes. The ANSA Trader [ANSA 1991] is such a name service whereas the Domain Name Service [RFC1034], while dealing with many hundreds of thousands of names is designed for a relatively stable namespace. Partitioned Management In an organisation there may be more than one independent application or set of objects to be managed. It must be possible for independent management structures to co-exist, each with their own manager(s) managing their managed objects. It must also be possible for managers to delegate their responsibilities to other managers. Multiple Management of Common Resources Often different managers will have different responsibilities for the same object or objects. For example, a directory service supplying user information. A user’s factual details, eg. phone number, could be managed and updated by that user but the supervisor’s management responsibilities allow the supervisor to update the user’s privileges. Any management system must be capable of allowing different managers with different management responsibilities appropriate access to the same object or objects. Decentralised Management It is very important that there are no centralised components or management systems within the overall framework. It is preferable to maintain management database resources local to the manager using those resources wherever possible both to reduce network overheads and reduce the impact of component failures. This contributes to the flexibility and scalability of the system. Adaptability Changing environments require adaptable software systems and systems must also evolve with time [Lehman 1982]. A distributed system is dynamic in nature with new objects being created or added and existing ones being moved or removed at any time. Distributed systems may be active for a long

26

Chapter 2


period and it may be impossible to halt the system when some components need to be altered. Management structures must be flexible and be able to adapt to the changing system. Scalability Scalability refers to the potential of the system to be viable in larger environments than the test system. The system behaviour must be independent as possible of the size and topology of the environment. It must be capable of handling the larger amounts of data that will be associated with a larger network, it must be capable of growing as the network grows. The size of a network should not restrict or force users to manage the network in any particular way. Security Security needs to be enforced in a distributed system. There are three aspects to security management: preventive security providing protection from unauthorised activities, detective security providing information about security violations and recovery dealing with security violations. In this thesis we are concerned with preventive security in the terms of access control. To satisfy this managers must be authenticated to the system and operations that managers can perform on managed objects must be controlled and optionally logged. Logging will aid detective security and recovery. Fault Tolerance In any distributed system there are going to be times when failures occur. There may be failures in the communications sub-system causing loss of messages or a host computer that is supporting components may crash. The management support system must be able to cope with these failures.

2.3 Management Architectures This section looks at the framework for the management of distributed systems and discusses the design of existing related work.

27

Chapter 2

2.3.1


OSI Management Framework

The OSI Management Framework [ISO/IEC 1989] recognises that management is not catered for in the OSI basic seven layer reference model and, apart from exceptional circumstances (e.g. booting or fault recovery) expects management interaction to be performed using the application layer; this is referred to as Systems Management. The framework describes a general repository for management related data called a Management Information Base (MIB). The framework has identified the five management functions described in the introduction in chapter one. The Systems Management Overview standard describes architecture for communications for management purposes in a distributed system. A management process in one system manages a managed object in another system using a remote peer entity. The managing process operates in a Manager Role, the remote entity in an Agent Role which communicates with the managed object itself. These roles are not fixed, they are just to identify the participants in a single management interaction. The agent role is specified because ISO only recognises remote communications as being peerto-peer. A manager managing a remote managed object may only communicate with a remote manager (an agent) which performs operations on the object on the first manager’s behalf. In this thesis we do not distinguish between local and remote management actions and see managers directly managing their managed object by interacting with its management interface regardless of location. We can relate our system to the standard by saying that the managed object itself acts in the agent role as part of its internal support of its management interface. Supporting services for management include addressing groups of managed objects, the synchronisation of operations, controlling access to managed objects, selective filtering of operations to be performed and control of the flow of data arising from notification. Management functions are defined in a Common Management Information Service (CMIS) [ISO 1988b] for communication between managers and agents. These operations include getting, setting and resetting data, getting and setting set values and attributes, object creation and object deletion. A Common Management Information Protocol (CMIP) [ISO 1988a] has been defined to

28

Chapter 2


carry the CMIS requests allowing a single mapping from service functions to protocol. There is no domain concept in OSI Management, its main purpose is to define management functions. The following section (2.3.2) describes the attempts of ISO/IEC to introduce management domains which give more structure to management. 2.3.2

ISO/IEC Management Domains

The domains described here are from recent draft working documents of ISO/IEC JTC1/SC21 WG4 [ISO 1992a, ISO 1992b] referred to in this section as “the draft standard”. They are described here in some detail as they are an attempt to standardise the type of domain system described in this thesis; indeed they include concepts from some of the work done at Imperial College but have not yet been smoothly integrated into a coherent model. The basic objects, requirements and relationships are described followed by a more detailed description with observation about the concepts. Overview of OSI Domain Related Objects The objects described in the draft are: Management Domain Managed Object - A collection of managed objects which are explicitly grouped together and to which a systems management policy applies to constrain their behaviour (sec 7.1)1 Domain Co-ordinator Managed Object - represents the management domain for the purposes of managing the domain. This is unnecessary as it overlaps with the functionality of the Management Domain Managed Object. Management Policy Managed Object - represents the systems management policy for the purpose of managing the policy This should not be part of the domain service because the domain service should just support the grouping of managed objects; policy management and enforcement (policy service) may utilise the domains but should be done at a higher level.

1

References are made to the original document in parentheses

29

Chapter 2


Grouping Criterion Managed Object - controls the membership of a domain. This is unnecessary as a managed object. A domain constraint, in the form of an attribute, can be used to control membership. A criticism of grouping criteria when used to determine candidates for domain membership is given below. Conflict Detector Managed Object - identifies the managed objects, the conflicting policies and the domains to which the conflicting policies are related. This should not be part of the domain service, but is part of a policy service. Domain Member Relationship Binding - binds managed objects in four roles2: domain, member, policy and domain member co-ordinator. This is incomprehensible and almost certainly unnecessary. Management Co-ordinator Managed Object This seems to overlap with the Domain Co-ordinator and domain managed objects. Domain Hierarchy Co-ordinator Object - co-ordinates the hierarchy of domains and policies. This is unnecessary as there is no need to “discover” domain relationships. In our view they are explicitly defined by the inclusion of one domain in another. Model “A Management Information Service (MIS) user in the manager role interacts with a managed object via a MIS-user in the agent role. The managed object is a member of zero or more domains and has, therefore, to comply to zero or more policies” 3 (sec 7). It is not described anywhere what management may be performed on an object which does not comply to any policies; can anything be done to it or nothing at all?

2

A Role in ISO terms is simply the current behaviour that an object is exhibiting

3

Text in italics denotes quotes from the draft standard.

30

Chapter 2


Domain Managed Object A Domain Managed Object has the following relationship roles: One and only one Policy One and only one Grouping Criterion Zero or more Members One and only one Domain Co-ordinator A Domain Management Object supports membership verification, membership enumeration and queries to discover the participants of each of the above relationship roles. The draft standard also states that a management domain does not remain in existence when there is no formal requirement to scope a set of managed objects according to a grouping criterion. Surely the way of indicating that there is no longer a formal requirement is by removing the domain? Grouping Criteria Candidates for domain membership are determined by a grouping criterion. Members are added to the member set if they are selected by the grouping criterion and they are capable of complying to the policy. “The grouping criterion may explicitly specify the membership by listing all the members, or implicitly specify the membership by listing common characteristics of the domain members or both” (sec 7.3). It is impractical to specify membership by means of a predicate on managed object attributes for a large distributed system. The implicit specification does not give any context limiting the scope of the possible members i.e. the set of objects which have to be queried to determine membership. All the members of a particular domain have to be known to satisfy the requirements that “It shall be possible to generate a membership list for a given management domain (membership enumeration)” and that “It shall be possible to determine which managed objects are fulfilling the domain policy role and the grouping criterion role (relationship query)” there is no indication as to how this can be implemented in a large distributed system; in fact, in our view, this is an unimplementable concept.

31

Chapter 2


Policy, Conflict Detection and Resolution Management Policy is a set of rules and rule selection procedure that regulate how members of a management domain should behave and how they should be managed. They contain attributes, authority and rules. Attributes include the characteristics of domain members. Authority is the set of administrators who determine the rules and can change attributes of the policy. Different administrators can be given different scopes of authority. Rules are the conditions that regulate the behaviour of the domain members. Rules determine whether a particular management operation will be allowed to be performed upon an object. The management domain may maintain a reference to the object(s) which detect conflicts and may maintain references to the object(s) which resolve conflicts in management policies. (page 19) A Conflict Detector Managed Object detects (run time) conflicts (sec 8.2.3). It detects conflicts in rules applying to managed objects that are members of multiple domains and operations that conflict with a policy to which the managed object complies. It is impossible to talk about detecting conflicts between policy without a clear definition of what a policy is, what conflicts can arise and some idea on how to detect the conflicts. There is no evidence that the authors are able to provide these. The Domain Co-ordinator also seems to detect conflicts as part of its responsibilities (sec 3.6.1). This conflicts with the Conflict Detection Managed Object’s responsibilities. Domain Co-ordinator A domain co-ordinator provides services for managing a domain. It offers services for adding members to a domain, deleting members, querying membership and modifying membership of a management domain (sec 3.6.1). If the domain object holds information about domain members we cannot see a need for a domain co-ordinator.

32

Chapter 2


The domain co-ordinator managed objects are able to detect changes in the values of their attributes and hence to emit notifications upon managed object creation, managed object deletion and attribute value change. (sec 7.1). We do not see this as a function of a domain service; it is the function of a monitoring service. There may be one Domain Manager and zero or more Domain Authorities referred to by the Domain Co-ordinator: There is no reason given for Domains knowing what managers are managing them. Domain Authority The Domain Manager and Domain Authorities are responsible for the policy represented by the management domain. The Domain Manager and Domain Authority information is held in the Domain Co-ordinator (page 11). It is barely referred to in the document and is unclear exactly what its function is. Sub-domains The domain hierarchy is maintained by a Domain Hierarchy Co-ordinator. A domain hierarchy co-ordinator is a support object that co-ordinates the hierarchy of domains and policies. (Annex C sec 8.x.1) This object is used to create, alter and terminate hierarchy relationships. It is also used to query domain hierarchy relationships and to signal conflicts between policies of super-and sub-domains. There is a binding between three roles: a super-domain, a sub-domain and a domain hierarchy co-ordinator. A sub-domain is enclosed by one or more enclosing domains. Subdomains are domain objects which are members of a parent domain. Domains also need to know their parent domains but this is a domain attribute. The members of the sub-domain are also members of the super-domain. This is plainly incorrect. It prevents partitioning of a large domain into subdomains which is, in our view, one of the main requirements of a domain service.

33

Chapter 2


Each super-domain should be a part of exactly one hierarchy relationship. A sub-domain is always part of at least one hierarchy relationship. This does not make sense, it appears to say that a sub-domain may be a super-domain to another domain but the super-domain restriction does not allow this to happen. If it means that the sub-domain may be a sub-domain of another super-domain; what does ‘enclose’ mean? Either way it implies that a subdomain cannot be a super-domain to another sub-domain. This whole section on domain hierarchy relationship seems to be completely confused and inconsistent. Unresolved Issues The draft standard has a set of issues still to be answered (Annex D). The questions are repeated here verbatim, with our answers: D1. Whether the grouping criterion managed object is needed? Grouping criteria can be useful when specifying the initial members of a domain. This could then be stored as a domain attribute which can be used as a constraint on future membership i.e. only objects which fulfil the constraint can be made members of the domain. The grouping criterion must have a limited scope from which it is to make its selection. D2. Whether there is a requirement for selection of management policies applied to a managed object? This is not part of the domain service but it may be part of the policy specification itself i.e. a policy specifies that it applies to a subset of objects in a domain. D3. Is there a requirement to know the management domains to which certain managed objects are members? If policy conflict is not handled by the object itself then there must be a way of finding out what policies are applying to an object. It can be useful also to satisfy a human user’s curiosity as to which domains a particular object is a member of.

34

Chapter 2


D4. How an instance of policy managed object may reference to instances of rules? Should the references be done by containment or some other means, e.g. direct object referencing? This is meaningless unless a clearer definition is given of a policy and a rule and the relationship between them clarified. D5. Should a policy managed object be allowed to select from different sets of rules? Therefore many sets of rules, represented as rule managed objects may exist for one policy, but only one of these sets shall be active at a given time. As in D4 above, clearer definitions are required. Comments on ISO/IEC Management Domains The draft document defines so many different managed objects which overlap in functionality that it is very difficult to understand. Many of the concepts being proposed are either unnecessary or unimplementable. A domain service is essentially concerned with providing a means for grouping managed objects for management purposes. This is a fundamental service to be used by all aspects of management as a means of grouping objects and structuring management. The basic service has to be simple and incur minimal overheads for management operations. A policy service provides a means of specifying and manipulating management policy, analysing it for consistency and conflicts. Most of the complexity related to a domain service is a result of using it as a means for structuring the application of management policy. However a policy service can be provided above the basic domain service rather than being integrated within it as being proposed by this document. We believe that the concept of a Domain Hierarchy Co-ordinator is unnecessary; it would be equivalent to stating that there is a need for a coordinator for creating subdirectories within a file system. The draft document does not describe a structure that will cope properly with the following fundamental concepts relating to a domain service: •

The domain service has to be scalable to cater for millions of objects if it is to be of any use in future large scale distributed systems. 35

Chapter 2


•

Domains should not enforce policy applying to managed objects other than domain objects themselves. There may be a level of manager agents above the domain objects which enforce policy if necessary.

•

Policy functions related to conflict detection should not be part of the domain service.

•

A subdomain is not the same as subset (cf. a subdirectory is not a mathematical subset of the files in a directory.

Management Domain Figures Some of the managed objects defined above are shown as diagrams - figures 2.1 & 2.2, these are not from the draft document but have been created in an attempt to provide greater clarity. Key

DomainID Read-Only Attributes Read-Write Attributes

DomainPolicy

DomainMembers

Notifications

GroupingCriteria

DomainManager Reference

SubDomains

DomainAuthority

ConflictDetectors ObjectCreation AttributeValueChange ObjectDeletion PolicyConflict

ConflictResolvers Modify Query

Figure 2.1 - Management Policy Managed Object

36

Chapter 2


Key

ManagementPolicyID Read-Only Attributes Read-Write Attributes

RuleAuthority

Notifications

ConflictDetectorsList

SchedulingInformation (optional)

Reference

PolicyDomains Policy (Rules)

ObjectCreation

ConflictResolversList RuleModifiersList PolicyAccessList

AttributeValueChange ObjectDeletion

Figure 2.2 - Domain Co-ordinator Managed Object

2.3.3

DEC Enterprise Management Architecture (EMA)

The DEC EMA [Digital 1989] provides an environment for management systems and managed components to interoperate. EMA conforms, where possible, to the ISO/OSI Common Management Interface Protocol (CMIP) standards. The EMA defines a framework and two models: The director/entity framework defines the structure of the management interfaces between the directors (the management system) and entities (the managed objects). The director/entity framework expands on the OSI Management Framework (section 2.3.1) to allow the use of non-standard management protocols. The entity model defines the management information and operations to be supported by a managed object. It identifies the kinds of information and operations needed in a management environment. The director model defines the structure of a modular, extensible system capable of managing any entity. Modules designed to support specific tasks or managed objects can be plugged in as required.

37

Chapter 2


The Director and Entity models are layered giving explicit division of management responsibilities. The layers reflect specific management capabilities required by users. They comprise: • Presentation - the external interface to the director model. It may be a Man Machine Interface (MMI) for a user presenting information and allowing commands; it may be a more strictly defined interface for connection to other management systems. • Function - This layer contains the actual services offered by the management applications within the director. • Access - This layer contains the mechanisms for control and monitoring of managed entities

Monitor/Control Terminal Policies/Knowledge

Presentation Director Model Function Access Entity Model Agent Management Protocol

Managed Object

Figure 2.3 - Director/Entity Framework

The entity model defines an internal structure common to all entities: • Management Agent - acts as a control panel for the managed object. It maps the management interface to information for and control actions of the managed object itself. Using the management protocol management information can be passed between the object and a director. • Managed Object - The actual hardware or software product being managed. This layer typically provides a service or services for its client.

38

Chapter 2


The director/entity framework uses the different levels of management described in section 2.2: Manual Management, Automated Policy Management and Self Management. Management Information The entity model defines classes or types of entities according to the properties that they share. This is consistent with ISO/OSI Structure of Management Information [ISO/IEC 1992]. A class comprises: Directives, Attributes, Attribute Groups, Events and Subordinate Entities. These are defined as: Directives A request/reply operation between a director and one or more entities. Each entity returns a single reply. A successful reply is called a response; a failed reply is called an exception. A reply may be split into more manageable partial-replies. Directives may be: •

Show - ask for the state of an entity

•

Set, Add, Remove - modify management variables

•

Create, Add, Delete, Enable, Disable, Test - perform specific actions on entities

Attributes and Attribute Groups These are data providing management information about specific entities. Eg. Status, Line State, bytes received, Characteristics and Counters etc. Some are set by the director and some are set by the object. Events Events are unsolicited data sent by the entity’s agent to a director to indicate state transitions or alarms. Subordinate Entities (Sub-classes) An entity class can contain other, subordinate, entity classes; that is, an entity class “Decnet Nodes” may have a subordinate entity class called “Communication Links” which is an entity class in its own right.

39

Chapter 2


Global Entities Top level entity classes are not contained within another entity class and are known as Global Entities. Since they have no parents they are known by unique names. eg. Within DECnet NODE4 and NODE are global entity classes for DECnet Phase IV nodes and DNA Phase V nodes respectively. EMA Director Model The director model contains: • Management Modules - these provide services to management users and to each other. The management modules are layered to give the director’s layers of Presentation, Function and Access modules. • Executive - provides the environment for the management modules (cf. kernel). • Management Information Repository (MIR) provides storage of management information within a director. The Management Interface Repository provides a private database within the director for the access modules and the function modules. The MIR maintains: • Class Data - defines the service that a module provides. • Instance Data - configuration information relating to entity instances. • Attribute Data - specific entity instance information recorded over time. eg. current state • Private Data - management module information. Comments There is no concept of policy and access control within the management model itself. DEC EMA is not a self-contained system, authentication and access control/Security is maintained by an existing DEC services. Global Entities require unique names, this requires a centralised registry for the allocation of these names. If two organisations need to link their EMA systems they must agree on their top level names.

40

Chapter 2

2.3.4


DEC Enterprise Management Director Domains

EMA [Strutt 1991] sees the world as Directors that perform management operations on Entities. As there will be many entities to be managed it is recognised that a global naming scheme is required. The Directors can create Domains which represent a sphere of interest of some set of managed objects. Domain membership is completely arbitrary. The concept of a domain is known only to the Director, entities are not aware of domains. An entity may be added to more than one domain. A Domain may be used by more than one Director and therefore requires a global name. As domain membership changes infrequently the Domain information is stored within the Global Naming Service itself. The Domain is also used to store historical data for the entities within it. The disk space used by a domain and its historical data is accounted to the Manager that owns the Domain. Since Domains are globally named entities they may be referred to in other domains. There are three types of Domains defined: Definitional Domains, Dynamic Reference Domains and Static Reference Domains. Definitional Domains: These domains are never active. Their sole use is to define a common set of entities which may be shared between multiple domains. They are not seen by the user in the standard user interface and contain no historical data. They are rather like a macro definition but are enumerated each time another domain references the information. Dynamic Reference Domains: The user interface contains Icons that can be altered if the entity that they represent changes. If a dynamic reference domain references such an entity then the domain’s icon will also change. The change will be reflected upwards until an icon currently on the screen changes to let the user know that attention is required. Dynamic Reference Domains are considered to be organised as directed graphs. It is stated that “Clearly it is important that there be no loop in the sequence of references.” It is not clear whether this is prohibited by the system or whether there are dire consequences if it is allowed to happen.

41

Chapter 2


Static Reference Domains: These domains do not have the dynamic properties described above and are used solely for navigation. Static Reference Domains can be organised as a mesh topology. Comments on Director Domains Although the Domain Model gives structure to the management of DEC EMA there are no policy implications attached to them. DEC EMA Domains seem simply to be a method of namespace partitioning; enabling one name to correspond to a set of entities. They are maintained entirely by the directors that define them. They are not applied to security, the access authorisation is performed elsewhere. Entities are not aware of the domains of which they are a member. This implies that polling has to be performed for all entities within a Dynamic Reference Domain to discover whether there have been any changes of state; this action can obviously be very expensive in terms of resources in a distributed environment. 2.3.5

HP Openview

Hewlett-Packard’s OpenView [Klemba 1989] is a network management architecture designed to help developers model network management solutions. It consists of an Organisational Model and an Operational Model. The organisational model helps to identify the management functions and their inter-relationships. The model consists of three components: User Interfaces, Management Applications and Management Services comprising objects and datastores cf. DEC EMA. There is no fixed number of components required in a model, a single Management Application can support several User Interfaces and control many Management Services.

42

Chapter 2


The Operational Model is used to determine how to deploy the components of the organisational model and to model the data flow and analyse management supervision. The model identifies nine components required within a physical system; e.g. a network bridge, a PC or a workstation. The nine components are: User Interface: the man machine interaction module Management Application: supports a specific management activity through a specific user interface. Environment Services: These are local services such as file access, sorting etc. Supervisor: The local operating system, this can range from Unix [Richie 1978] to a small PROM on a controller board. Postmaster: used for routing object-oriented type messages from component to component Communication Profile: used by the Postmaster for communicating with other systems. Object: represents the objects from the organisational model Datastore: represents the datastores from the organisational model Management Services: all the management services available to the system not previously included.

43

Chapter 2


SYSTEM User I/F

Applications

Environment Services

Supervisor

Postmaster

Comms. Profiles

Objects

Management Services

Datastores

Figure 2.4 - OpenView Operational Model

The OpenView model certainly addressed the issue of decomposing management functions for the management of single entities. However, while there is the notion of the fact that managers can themselves be managed there is no overall structuring of management; there is no domain concept. Management is done on a one-to-one level and is therefore not suitable for large systems. There is no concept of authority, only of relying on some outside agency, a security entity, supplying passwords or telling the managed objects who may manage them. 2.3.6

OSF DME

The Open Software Foundation’s Distributed Management Environment Architecture [OSF 1992] is designed to provide a consistent approach for system and network management. It provides a development environment and a support framework. DME comprises an object-oriented infrastructure for distributed management applications, support for different underlying management protocols such as the Simple Network Management Protocol (SNMP) [RFC1157 1990] and CMIP, a management user interface and several distributed services.

44

Chapter 2


Services include: •

notification services

•

software distribution and installation

•

printing

•

software licensing

•

personal computer integration

•

host management

The management model is defined in terms of co-operating objects that provide application functions. In this way different proposed management models, such as OSI and OMG models, can be incorporated. I4DL (Interface, Inheritance, Implementation, Instantiation Description Language) is used to support the specification of managed objects. I4DL covers four areas: Interface: specifying the syntax of operations and the public attributes of objects Inheritance: specifying how objects reuse implementation of operations Implementation: specifying attribute data storage and object server environment Instantiation: specifying instantiation properties such as default access control, privilege level and target directory. DME Objects There are three categories of object: presentation object, management object and adapter objects. These can be compared to DEC’s presentation, function and access and to HP’s user interfaces, management applications and management services. Presentation objects are those which provide services for interaction with a graphical display. Management objects provide some services and may request services from others so can act as both clients and servers.

45

Chapter 2


Adapter objects map specialised and proprietary protocols and mechanisms into the DME object model. They are used for any objects outside the DME environment eg. for objects that use protocols such as SNMP and CMIP, RPC calls to other servers such as an SQL database or for access to configuration files on a system. There is a basic object adapter which can be used to map objects from an object based system into Object Request Broker (ORB) objects which can then receive invocations from the ORB. For systems that cannot use the basic object adapters a special-purpose adapter can be created. All the interfaces and implementations in a DME system are kept in a Repository. The repository conforms to the Object Management Group’s (OMG) Common Object Request Broker (CORBA) [DEC 1991] specification. Location, security and communication for managers and managed objects is done using a Management Request Broker modelled on OMG’s Object Request Broker. When a manager requests another object to perform an operation it does so by providing various operation parameters and a parameter uniquely identifying the managed object. The MRB can then locate the object anywhere within the network. The adapter object works well. One example of an adapter object is a Host Configuration Object (HCO). An HCO maps abstract get, set, add and remove methods onto various system databases. On Unix this might be /etc/passwd when dealing with passwords, on other systems it might map onto a distributed database password file. The OSF DME approach lacks the Domain structuring concept but could be used as the managed object support base in a Domain structured system. 2.3.7

DOMAINS Project

The Esprit DOMAINS (Distributed Management Architecture for Distributed Systems) project [DOMAINS 1992] aims to develop an architecture for distributed systems management. It consists of two models, the Domain Management Model and the Domain Management Architecture. It also has a Notification and Registration Service, a Directory Service, a Transaction Service and a Management Hook access service. 46

Chapter 2


The DOMAINS Management Model (DMM) defines a recursive model of management composed of a manager and one or more resources. The manager is given goals from its superior manager and hands back reports. The manager, in turn, has the usual control and monitoring interface to its resources. A resource can be a managed system with its own manager and resources. In this case the control and monitoring from the high level manager becomes translated at the interface to goals and reports; thus a strictly hierarchical model of management is built up (figure 2.5). Goals

Reports

Manager Control

Monitoring

G

Control

Monitoring

R

Manager C

M

Resource

C

M

Resource

Resource

Resource

Figure 2.5 - DOMAINS’ Recursive Model of Management

Management interworking is allowed in the case where a resource is to be managed by more than one manager. However, the resource in the DOMAINS model may only be a composite resource i.e. one with its own manager because only a manager may have more than one manager supplying it with goals. The managed manager is responsible for detecting and dealing with conflicting goals given to it by more than one manager. This does not necessarily reflect the real world as every resource has one manager which may in turn have more than one manager so multiple managers cannot interact directly with a resource. In the DOME model if there is more that one manager managing a managed object it is solely up to the managers to co-operate, the managed object will do what it is told. The

47

Chapter 2


DOMAINS restriction involves more work than DOME when a “simple” resource managed only by one manager is to be managed by an additional manager. In DOME the resource (managed object) does not perceive any difference, in DOMAINS a new “composite” resource will have to be created with its own manager first. The DOMAINS Management Architecture (DMA) uses the object-oriented paradigm to structure management tasks using domains. Domains are used to deal with complexity and scale, they may be disjoint, overlapping or hierarchical. Domains are also used to support dynamic configuration of managed systems. Each domain encapsulates a kernel, a shield and one or more targets, the managed objects. The kernel is the local manager of the domain. It accepts goals from higher level Kernels’ goals, resolves conflicts and sends commands to its resources via their shields. The shield comprises a set of shield elements that provide management interaction points for particular management interactions. A shield element accepts commands from only one manager and, after possibly translating the commands, sends them on to only one resource. The kernel may talk to many shield elements and many shield elements may talk to one resource presenting different management interaction points for that resource. Domain A Target Resource

Shield A SE

TR Domain B Shield B SE

Kernel A

SE

Kernel B

SE

SE

Shield Element

SE

TR

TR

TR

TR

Figure 2.6 - DOMAINS’ Nested Domain Structure

48

Chapter 2


Domains reflect the management hierarchy: “subdomains are themselves subject to management by the enclosing domain.” Management resources are bound tightly together within a domain. Domains encapsulate the manager and their managed resources, this makes it difficult to create a changeable set of managers that can manage a changeable set of resources such as Accounting Managers and Accounting Records. There are two basic types of domain: Policy Domains and Feature Domains. Policy Domains contain target objects to which a common policy is applied. A Feature Domain has a single kernel which pursues several policies simultaneously to subsets of the contained targets. Feature Domains are used to reflect different criteria such as: organisational, geographical, ownership and functionality. DOME, on the other hand, has a one simple domain type but allows non-policy members for the convenience of grouping objects with non-policy implications. Feature Domains still have policy implications for the contained targets. The DOMAINS project recognises several basic object services required to support its object-oriented model. These comprise: Class Manager, Instance Manager(s), Directory and Naming Service, Persistency Manager, Passivation and Activation Manager, Resource Manager, Communications Manager, Transaction Manager and Time Services. Above these services there are a set of management services: Scheduling Service, Registration Service, Selective Invocation Service and Conferment Management Entity. Comments DOMAINS’ domains encapsulate managers and their managed objects so that the objects in a domain are only accessed by their manager. This strict encapsulation makes it difficult, if not impossible, to rearrange objects dynamically in the management hierarchy. To enable reconfiguration inside a domain they have to have a management hook installed in the domain’s kernel to allow internal reconfiguration of the embedded target resources. DOMAINS’ domains are purely for management purposes unlike DOME domains which can also used for namespace partitioning. DOMAINS also define management as a strict hierarchy, cyclic domains not are envisaged and therefore not dealt with at all.

49

Chapter 2


Domain management is only defined with control from high-level kernels to low-level ones. It is admitted that this model does not reflect the real world as low-level managers might require some information from higher-level ones. The DOMAINS project solves this dilemma by allowing the monitoring/report messages to be a request for information and the goal/control flow may actually be a report! This is a complete reversal of defined structural links and should be redefined to be eg. Management Information Channels. 2.3.8

OSFA - Object Systems Framework Architecture

OSFA [Raeder 1991] is an Object-Oriented Distributed Approach to Network Management. OSFA follows the OSI model for network management with all its components but proposes distributed object-oriented systems as the ideal technology for Distributed Network Management. Conformant Management Entities (CMEs) are used as agents for nonconformant objects that are to be introduced into the system. All OSI managed objects and messages are made visible to OSFA by using CMEs. Each object has a structure consisting of a service template, system schema and message and persistence support. The service template provides the management interface and ensures that the object will behave correctly for message passing, exceptions etc. The system schema provides the standard classes for OSFA and provides persistent storage and message passing. The message and persistence support provides the low-level work for the object such as different communications protocols and storage schemes without affecting the system schema. Administrator Objects have all the attributes of an ordinary object but in addition provide administrative functions for the other objects. There will typically be one administrator per node (much like the DOME Node Manager). Administrator objects communicate with each other to maintain up-to-date information about the total state of the system. The responsibilities of the administrator objects are: • Object creation, start-up and shutdown • Object dynamics - object replacement, migration and replication • Name service - Objects register and are added to an X.500 directory. 50

Chapter 2


• Security and accounting - some of these functions are centralised. Domains and Name Resolution A domain is a collection of management objects that are managed by the same management system. Domains may be members of other domains and thus provide a name lookup facility. Objects can also be addressed through other objects by virtue of the object oriented inheritance in the objects. Policies/Security Policies are not determined by the OSFA framework but are left up to agreement between the administrator objects. Comments The strictly object oriented approach does not lend itself well to distributed environments especially as OSFA objects can be addressed through other objects; the overheads can be quite high. This would be the equivalent of dereferencing remote pointers to access information. OSFA does work as a name service so no external support is required but there is no structure of management so this does not satisfy the requirement for Management Hierarchy.

2.4 Implementation Approaches The work described here are implementations that cover the general area of Distributed Systems Management and included as they deal with some of the requirements identified in chapter one. 2.4.1

DEC DNS

The DNA Naming Service (DNS) [Digital 1991] is a distributed naming system for objects in a heterogeneous network. The DNS supports access controls restricting access to information held within the DNS itself. The DNS has the following attributes: • Decentralised management. Names may be created and removed without recourse to a central authority. 51

Chapter 2


• Unique Names. The DNS uniquely identifies named objects. • Migration. The DNS allows objects to change their physical location. • Merging. The DNS allows two isolated networks to be merged without affecting the names that users use to refer to their objects. • Security. The DNS ensures the privacy and integrity of names by preventing unauthorised access. It prevents unauthorised disclosure, modification, insertion or destruction of the naming information entrusted to it. The DNS specifically does not handle: • Mutual Exclusion of names. Due to the implementation the DNS does not guarantee the mutual exclusion of names. It is possible for one user to create a name, use it and at some later time find that another user had created the same name which has superseded the first user’s name. The user can determine whether the name is safe but this is an extra operation for the user. The DNS requires the following support: • Unique Node Identifiers. The construction of unique timestamps using unique 48-bit node ids. • Accurate Clocks. The DNS requires clocks across one namespace to be accurate enough to satisfy the event ordering requirements of human users. Description All objects have a local alphanumeric name. Names are held in directories which can also contain child pointers and soft links. A child pointer is a link to another (sub)directory; directories form a single rooted tree with one single path from the root to any one directory. An object can be located by using its

52

Chapter 2


full hierarchical path name. A tree of directories is called a namespace. A soft link is an alias for an entry allowing more than one path name for an entry. Multiple namespaces may exist but are completely independent. The DNS ensures that a namespace forms a tree by ruling that directories have only one parent at any time and no directory may be a child of one of its descendants. We allow the DOME Domain to have more than one parent so that multiple policies can be applied based on domain membership. The namespace is stored as a partitioned, replicated database with the directories forming the unit of distribution. A collection of directories is held in a clearinghouse. Partitioning is achieved by placing directories in different clearinghouses; replication is done by storing copies of directories in more than one clearinghouse. All copies of directories are referred to as replicas with one being designated as the master replica. Other replicas are either secondary or read-only replicas. Creation of new child pointer entries may only be done using the master replica, all other operations may be done using a replica of type master or secondary. As the name suggests only read operations may be done on a read-only replica. Clearinghouses have names and are located using the namespace. The node upon which a clearinghouse is running is referred to as a nameserver. Directory consistency is maintained by periodically running a skulker which locates all replicas of a directory and updates them. Security Authentication is provided by an existing service within the operating system. DNS security only prevents unauthorised access to the naming structure itself not to the objects. Access control Each nameserver has its own reference monitor which applies the namespace’s access policy provided through the use of Access Control Sets (ACS). Each ACS protects an object and consists of Access Control Entries (ACE). An ACE specifies the principal, options and access rights.

53

Chapter 2


The principal is either a name registered in the namespace or an implicit group denoted by wildcards or an explicit group denoted by the GROUP option. The options modify the ACE and may comprise a combination of: • Group causes a (possibly recursive) check to see if the principal is a member of the group. • Default (used for directories) copies the ACE to any non directory entry created within that directory. The default option is removed from the copied entry as ACEs with the default option set are ignored during access checks. • Nopropagate (used for directories) indicates that the ACE should not be propagated to child directories. The default is to propagate ACEs. • Unauthenticated indicates that the ACE can be matched with unauthenticated principals. The access rights held in an ACE are Read, Write, Delete, Test and Control. Test allows read access to attributes and Control gives access normally permitted to the owner of the object. 2.4.2

Andrew File System (AFS)

The Andrew File System [Satyanarayanan 1989] has been designed to deal with a large community of workstations which require user’s files from central servers whilst having no control over the security associated with the remote user workstations. Sun’s NFS [Sandberg 1985] or AT&T’s RFS [Cole 1985] were not suitable because of the high overheads of many remote user workstations and the lack of suitable security. AFS splits the user workstation and the central file server into two components called Virtue and Vice respectively. Virtue is a group of BSD

54

Chapter 2


Unix workstations running Venus which maps the Unix file system semantics to make Vice appear as an extension to the local file system. AFS relies on Protection Domains to provide access control. Protection Domains are composed of users and groups. Users are members of groups and groups can be members of other groups. A user’s Current Protection Domain (CPD) is the set of all groups that the user is a member of, either directly or indirectly. The file system maintains Access Lists containing entries that map a member of the protection domain to a set of Rights. The total rights that a user has on an object is the union of all the rights possessed by the members of the user’s CPD. The Access List has a set of positive rights and a set of negative rights. Negative rights override positive rights. Access Lists are associated with directories which correspond to the Access Control Lists on the DOME Domains (section 6.4.1). 2.4.3

ANSAware Trader

Trading is the process of matching offers to support a particular service with requests for that service. The Trader acts as an intermediary between clients and servers. The service provider registers its interface with a trading service. The object requiring a service performs a Lookup operation on a trading service; an interface reference is passed to the calling object after a successful lookup; after this match has been made the two objects can interact. The service provider registers the following information: •

interface specification

•

naming context

•

names and properties of properties with the offer

•

the interface reference

The service consumer provides the following information in a lookup request: •

the desired interface specification

•

the naming context in which to search 55

Chapter 2

•


a constraints expression to be applied to the property values associated with the service offers

The lookup matching succeeds if: •

the service interface is the same as or a superset of that required

•

the correct name is found in the correct context or trading scope

•

the constraints match the properties of the service provider

Federation Two or more trading domains may interact by federating some portions of their trading spaces to permit members from one domain to access services in another. There are two types of federation: •

One trader’s context space can be bound to a context name in another trader’s context space. There are two ways of searching the federated context space: shallow, the federated space is searched if a local search fails or deep where the federated space is always searched when a consumer does a lookup.

•

One trader’s context space appears as an offer in another trader’s space. If a lookup matches the proxy offer it is passed back to the other federation’s trader whose response is returned to the original requester.

A master trader is defined that acts as a federated trader. If the master trader’s context is within the trading scope of the lookup request then the master trader will be asked to resolve the lookup request if the local lookup fails. Implementation The Trader comprises two objects; a context name manager and a type manager. The context manager supports the registration, perusal and deletion of service requests within a context name space. The type manager manages the interface type names and maintains the relation between types and sub-types. The type/sub-type relationship is not expected to change often and is held as an inverted Directed Acyclic Graph to make comparisons as fast as possible. 56

Chapter 2


The context name space is held as a multi-way tree in a way that assumes that addition is the primary method of context name tree modification. The names of the contexts and descendants are separated by a ‘/’ and the root is denoted by a leading ‘/’; similar to a Unix pathname. Registered offers have an interface identifier which is a unique identifier for the service offer. The property lists associated with an offer consist of a name and a value with a type of Number, String or List. Lists are lists of strings only. The Trader server itself must be found at a standard address. Comments on Trading Searching the whole federated space can be expensive in a distributed system and should really be performed by the originator of the request, not by the support system which ties up resources. Clients are given an interface reference to any server that has a suitable offer available at the time the request is made so it is not easy to specify a particular instance. Different context names could be given to obtain a particular instance but the server must have registered the appropriate information first. For our management purposes we are not usually looking for a service but are looking for the particular instance that we want to manage. 2.4.4

Internet Domain Name System (DNS)

The Internet Domain Name System [RFC1034, RFC1035] is a naming and location service designed to cope with large numbers of host computers on a world-wide distributed network. DNS uses an hierarchical naming scheme based on country at the top level, some fairly broad groups (called Domains) at the next level eg. commercial, academic, military etc. followed by domains for individual organisations. The organisations themselves generally define their own domains within their organisation’s domains (subdomains). DNS’s goals include: •

Names should not imply any form of addressing or routing.

•

The DNS information must be maintained in a distributed manner.

57

Chapter 2

•


DNS must be capable of maintaining different types of information eg. Host addresses and mail addresses.

The DNS has three major components: The name space and data records, Name Servers and Resolvers. The Domain Name Space is the previously mentioned tree structured name space and the Resource Records are the data associated with each node and leaf on the tree. The Name Servers generally know about their part of the name space, called a Zone, and they maintain pointers to other name servers that may help resolve information for other parts of the domain tree. Generally the pointers point to one or more name servers higher up in the tree, as a last resort a pointer can be maintained to the top of the tree. When information is found, DNS specifies that all data for that zone must be transferred and cached locally for a time. This increases network loading but reduces response time in the likely event of more information being requested from that same zone. Resolvers are the user interface to the name servers. Generally they are library modules that can be linked into programs. They do all the negotiation with the name servers leaving the user with a simple interface. The current implementations of DNS on Unix systems are geared towards host and mail names and addresses which do not change very frequently. Updates are normally cached for hours at a time taking a while for them to percolate through the system. Although DNS is designed to handle different types of networks and addressing it currently only copes with Internet IP addresses or 16bit octal addresses from an obsolete system.

2.5 Chapter Summary This chapter has described the concepts and abilities required for distributed systems management. The system needs some form of namespace management along the lines of Internet DNS to be able to cope with a very large number of named objects.

58

Chapter 2


The different approaches described in this chapter all use hierarchies to cope with large numbers of components, which is the only scalable way of dealing with many objects. There is a need for a domain service to support management. However it must be a simple basic service which can be enhanced to provide more sophisticated functionality. It should not be based on the concepts described in the ISO/IEC draft standard as they are too complex. Although the DOMAINS approach is the closest of all the configuration management approaches to the DOME view of management (see chapter three) it is far more restrictive; a manager has to exist within every domain, it takes part in all operations involving that domain adding an unnecessary overhead. DOMAINS’ domains reflect the management hierarchy, we believe that the domain hierarchy should be independent of the management hierarchy. It is much more flexible to allow managers to exist anywhere in the domain hierarchy; this allows one manager to manage many different domains and objects and allows many managers to share management responsibilities for a single object or domain. It is also more efficient to allow managers to directly manage objects if they wish to.

59

Chapter 3

The DOME System

This chapter introduces the DOME environment as the user sees it. It is a tutorial that builds up from the concept of a domain being a simple collection of named network objects (software processes or hardware components) to domains being used to manage a well-structured distributed system. As concepts are described we identify various new requirements and give their solutions. Unlike other environments cyclic structures are shown to be acceptable giving more freedom to the user when manipulating domains. Finally the federation of two different organisations’ DOME environments is described; it is shown that a global naming scheme, while being useful, is not actually a requirement.

3.1 Domains Domains are used to partition a large distributed network to make its namespace manageable and to group network components together for management purposes providing an easy to use but full featured access control system. A domain is a network object that may be empty or contains one or more named objects which are within the distributed system; objects must be explicitly included into a domain. Groups of objects that cannot be enumerated are not permitted. e.g. It would be rather hard to list all the members of the domain of all people with blue eyes. The user of a domain system can add objects to the domain or remove them from it. All names in the domain must be unique within that domain so that each object can be individually referred to by using its local name.

60

Chapter 3

The DOME System

Bank Account #0428261

Fred Printer 1

Domain A Figure 3.1 - A domain containing some objects

It can be seen that domains can be used for grouping objects together. It would not only be useful to group the same kind of object in a single domain but it can be made more useful by limiting the kinds of objects allowed. So, domains may have constraints limiting the categories of objects that may be included eg. “Only Unix host computers” or “Only people earning over £100000 per annum.” In the latter case problems can occur if someone’s salary is reduced. It is a violation of the spirit of the constraint for that person to remain a member of the domain; this raises the question of eager or lazy evaluation. Should the domain and its objects be constantly monitored (eager evaluation) or, like Schrödinger’s cat [Gribbin 1985], does it only matter when we look at the domain? Now we have a simple way of grouping objects together but this will not satisfy some of the requirements in chapter two such as scalability. Conic has used a similar, simple grouping system for a number of years and it has worked well for the small user community at Imperial College. However, in a very large system there will be a large number of domains. How should the domains be named? If they share the same namespace there is the likelihood of more than one user choosing the same name for their domains. As previously stated a domain is an object so, like any other object, it may be included in other domains. Users can be given their own domain in which they can create new domains as required for the objects that they want to group together. This gives us a flexible hierarchical way of structuring the name space of the distributed system. cf. an hierarchical file system. Without

61

Chapter 3

The DOME System

hierarchies a large namespace is not manageable and it is easy for naming conflicts to occur between users.

Fred


Jim

Printer 1

Domain B Domain A Figure 3.2 - Showing a sub-domain within a domain

3.1.1

References

From the user’s point of view the domains hold the objects themselves and appear to encapsulate them. If the domain did encapsulate the object it would not be possible to include the object in more than one domain without duplicating it. In fact domains actually hold named references to objects. The collection of the named references within a domain is called its name set. Domain A Bank Account #0428261

Fred

Domain B

Bank Account #0428261 Fred

Jim

Printer 1

Domain B

Jim

Printer 1

Domain A

Figure 3.3 - User view and “Real” view of domains

62

Chapter 3

The DOME System

Domains therefore provide the means of naming the objects within the distributed system. All objects that are to be referenced by anyone must exist within a domain. As a corollary, objects must always be created within a domain. With any hierarchical structure there must a top level or ‘root’ domain from which the hierarchical namespace branches out. Hierarchical name searches can be started from the root or from any domain if the name does not start with the root domain. It is sometimes easier to show nested domains as a tree structure: Domain A


Fred

Jim

Fred

Printer 1

Domain B

Jim


Printer 1

Domain B Domain A

Figure 3.4 - Hierarchical Domain Diagrams

3.2 Domain Relationships 3.2.1

Subdomains and Cyclic Structures

A domain that is included in another domain’s name set is called a subdomain. The domains are independent of each other with respect to their name sets. Similar systems that deal with hierarchies do not allow cyclic structures such as DEC EMA [Digital 1989, Strutt 1991] and Unix. There seems to be little reason for not allowing the users to create them. If a cyclic structure is prohibited the support system has to check to see if one is being created every time one domain is included into another. Unix, though, stops cyclic structures by prohibiting directories from being in more than one directory at a time, this is far too limited for an object based management system. If cyclic structures are permitted the system has to detect them in 63

Chapter 3

The DOME System

certain circumstances such as operations that traverse the hierarchy. Either way the support system has to detect the presence of cyclic structures so it seems more sensible to allow the user the freedom of choice. DOME is aware that this can occur and deals with it appropriately when traversing the domain hierarchy. 3.2.2

Overlapping Domains

If two domains have one or more of their name set entries in common they are overlapping domains. There is no explicit domain corresponding to the overlap. One cannot put an object into the overlapping part; the object would have to be included in both domains separately.

Fred


Jim

Printer 1

Alfred

Domain A Domain B Figure 3.5 - Overlapping Domains

Overlapping domains can complicate the graphical representation slightly. There is no requirement for objects to have the same name in all the domains in which they are members; in fact if there was it would be another unnecessary restriction on the users. The above figure would have to show the common objects with two names. The tree structured diagram has to label the arcs, not the objects, which is in fact a more accurate representation of the name set in the domains.

64

Chapter 3

The DOME System

Bank Account #0428261 Fred

Domain A My Account

Fred

Level 4 Printer 1 Printer Jim

Jim

Printer 1

Bank Account My #0428261 Account

Level 4 Printer

Domain A

Domain B

Alfred

Domain B

Figure 3.6 - More complex overlapping domain representations

3.2.3

Parents and Ancestors

A domain is the parent of all the objects within its name set (This rule will be modified slightly later). The parent’s parents and their parents etc. are known as ancestors of the object. There is a parent set associated with every managed object, the members of this set are the domains in which the object is a member. Objects within a domain’s name set are said to be direct members or children of that domain. Objects which are members further down the hierarchy are indirect members or descendants of that domain.

3.3 Objects Objects may be processes, threads, hardware, domains, people etc. In fact anything that may be referenced or addressed. For an object to be compatible with the DOME environment it must support one or more interfaces (described below). Objects are also capable of destroying themselves when the appropriate command is sent to them. Objects are the members of the domain’s name sets. They are referred to by the user in terms of the domains and the names of the objects within that domain. Although objects are referred to using names local to a domain they also have a unique reference to which the local name is translated.

65

Chapter 3

The DOME System

3.4 Interfaces Every object must have a basic DOME interface allowing it to be queried to determine its attributes; for example its type, its unique identifier and other attributes including creation time, creator, owner etc. In addition to the basic interface there are several other interfaces. These include a domain interface for domain objects and a factory interface for objects that can create or instantiate other objects; these are described later. The minimum set of operations that the interfaces provide are: 3.4.1

Object Operations

All objects must support this operation. Destroy - Remove the object from the system This operation is really implementation dependent. It might be the object itself that is told that it has to disappear or it might be the supporting operating system that will destroy the object. In either case, the object might need to know that it is being destroyed so that it can tidy itself up if necessary; for example to update its log or to save some data. 3.4.2

Domain Object Interface Operations

Include - include an object adding a local name for it into the name set An existing named object may be included in a domain with a new name. To refer to the object in the first place it must be named using a domain; this means that objects may only be created within a domain (see Factory Interface below). The new name must not already be present in the domain’s name set. Note that the same object may be included more that once in a domain but it must be given a different name. An object may be included in several domains with the same name. Remove - Remove an entry from the name set. Any name in the name set can be removed. This will not destroy the object itself but will simply remove the reference to it from the domain. There is a

66

Chapter 3

The DOME System

problem with removing an entry if it is the only reference to that object as the object could never be referred to again; it depends on the implementation whether the object should be destroyed or the remove operation should fail. Rename - Change the name of an entry in the name set This operation changes the name of a reference to an object in the name set to the new name. The new name must not be the same as one already existing in the name set. Link - Unlink - Manipulate a different type of name set entry (described later) List - List the contents of the domain’s name set 3.4.3

Factory Object Interface Operations

Create - create an object in a domain with a specified name Given the correct arguments for creating an object it will be created and added to the domain’s name set with the specified name. Different object types will probably be created by different factories although there is nothing in the model to stop a factory from creating more than one type.

3.5 Management So far we have only described Domains as a method for managing or structuring a namespace and how they may be manipulated. Now we will show how they may be used for management purposes and how they can enforce security within a system by using permissions before allowing management access to objects. Management, in this context, is defined as the monitoring and control operations performed on an object. A user performing operations on a Domain is actually performing management operations and is therefore managing the domain.

67

Chapter 3

The DOME System

Printer 1

Operations Manager


Manager Domain

Managed Domain

Figure 3.7 - Domain and Object Management

The human user interacts with the DOME environment via an interface to the system which must be a DOME object; such an object is a management object. A management object is an object which performs an operation on another object. It may be controlled interactively by a user or may be preprogrammed to be triggered on events such as failures, timeouts, signals/interrupts or message receipt. Once we start looking at the management of Domains we see that there may be conflicts between managers. Managers may also (try to) perform unwanted, or worse, unauthorised operations on objects; some form of security is required. In the first case of two managers legitimately managing the same domain it is up to them to discuss and agree upon a common policy; operations by either of them upon the domain would be valid as far as the system and authorisation is concerned. In the second case we need to define a policy stating which operations the manager many perform on what managed objects.

3.6 Management Policy There are two types of management policy: obligation policy and authorisation policy. The former describes the goals and actions that the manager has to achieve (the motivation) and the latter describes the actions that the manager is allowed to do (the means), to achieve the goals. Obligation policy is not dealt with in this thesis but authorisation policy is described in terms of permitted operations that managers may perform on managed objects.

68

Chapter 3

The DOME System

3.7 Access Rules To prevent unauthorised access to objects an authorisation facility has to be set up and maintained by the DOME environment. Access control (authorisation) is specified between domains in terms of access rules. Managers in a certain domain may be permitted to perform certain operation on objects in another domain. This allows great flexibility by creating domains representing, for example, management positions and employee positions in a company. Individual managers may be moved to and from a domain that has access to another domain without having to change the access rules. An access rule is set up between a manager domain (source domain) and a managed domain (target domain) specifying the permitted operations that may be performed by objects in the manager domain on the objects in the managed domain.

Permitted Operations Access Rule Managed Domain

Manager Domain

Figure 3.8 - Access Rule between Two Domains

It can be seen that access rules give simple control of operations between a domain of management objects and a domain of managed objects. However, there are likely to be a great number of domains structured in an hierarchical manner, often because there are sub-types of managed objects or because different management access is required to some of them. Taking an Accounting system as an example there are likely to be a great number of accounting records. The records may well be sub-divided into different departmental accounts. eg. purchase, stationery, canteen etc. It would make sense to put the departmental accounts into their own domains and, similarly, the departmental account managers into their own domains. We can now give the departmental account managers access to their departmental accounts.

69

Chapter 3

The DOME System

Accounting Records

Access Permissions Access Rule Canteen Accounts

Canteen Managers

Access Permissions Access Rule Stores Accounts

Stores Managers

Access Permissions Access Rule Payroll Accounts

Payroll Managers

Figure 3.9 - Management access to accounts for different departments

However the accounting department managers require access to all the company’s accounts. Using access rules as they have been introduced we would have to create access rules for access to each department’s accounts. See figure 3.10.

70

The DOME System

Pe Ac rm ce A iss ss cc i es s R ons ul e

Chapter 3

Canteen Accounts

Access Permissions Access Rule Accounts Managers

Stores Accounts

s s es n cc sio le A is u rm sR Pe es cc A Payroll Accounts Figure 3.10 - Company Accountants’ Access to the Accounts

3.7.1

Access Rule Inheritance

So far we have seen access rules act upon two domains, the source domain and the target domain. However it is often the case that access is to be given to many domains in a hierarchy; in terms of management this is one of the reasons for creating the hierarchy in the first place. To avoid having to respecify the access rules for each subdomain we will now extend the scope of access rules. Access rules applying to a parent domain, should propagate to member subdomains of the parent. For example an access rule applying to an organisation should also apply to departments within that organisation. A subdomain is said to inherit, the access rules applying to parent domains (but this is not the same as object oriented inheritance). This propagation is performed for both the source and target domains of the access rule. Definition: The access rule gives management objects that are direct or indirect members of the manager domain authority to perform the permitted operations on direct and indirect members of the managed domain.

71

Chapter 3

The DOME System

This gives us the company set-up shown in figure 3.11 using the minimum number of access rules. If a new department is added, two domains and an access rule need to be created; one domain for the new department’s managers and a sub-domain of “Company’s Accounts” for the new department’s accounts and an access rule between them. The new department’s managers will be able to read the new accounts and the company’s accounts managers will also have access to them via the “Company’s Accounts” domain.

Access Permissions Canteen Managers

Access Rule

Canteen Accounts

Access Permissions Stores Managers

Access Rule

Payroll Accounts

Access Permissions Payroll Managers

Accounts Managers Figure 3.11 -

Access Rule ess Acc sions mis Per e Rul ess c c A

Stores Accounts Company's Accounts

Company Accounts Structure with Access Rule Inheritance

3.8 Federation There is no built-in requirement for one single DOME environment in the world with all organisations using it to be under the same root. In the normal course of events different organisations will set up their own DOME systems and use them independently; each having their own root domain and support system. However, there may come a time when it is desired for one organisation to refer to some or all of another organisation’s DOME environment; some form of federation is required.

72

Chapter 3

The DOME System

It is undesirable to include a domain or other object from one organisation’s DOME environment in another because of policy implications. Objects inherit the policy relating to their parent domain(s) and one organisation may not want to grant any access over and above, say, read or list access. We can state our principles for federation as: •

We are only attempting to achieve inter-organisational management between organisations which implement compatible Domain Services.

•

The mutual independence of the organisations must be maintained. References to one independent organisation from another must not, by themselves, carry any policy implications, such as enabling access within the organisation. Therefore the reference cannot be achieved by including a domain from one organisation in the name set of a domain of another.

• 3.8.1

It is desirable to use a familiar naming method. Context Links

So far, all domain members have had policy implications, we now introduce another domain membership type to the domain’s name set, the context link. This is an entry in the name set that has all the appearances of previously discussed entries but carries no policy implications; it is simply used as a convenient way of referring to an object. The name set actually comprises two parts: the policy set for policy entries and the context set for context links. Unlike the policy set the domain is not known as the parent of objects in the context set and does not inherit any policy; this satisfies the mutual independence requirement above. In order to establish inter-organisation connection, reference to another organisation is placed in the context set of the target domain. For example, assume that organisation A wishes to refer to domains in organisation B. See figure 3.12a.

73

Chapter 3

The DOME System

TopA

TopB

Policy References

A1

Policy References

A2

B1

Company A

Company B

B2

Figure 3.12a - Interconnecting Two Organisations

Then a (human) manager in A finds out, e.g. by telephone, the address (actually an Object Identifier described in chapter four) of the required domain of B - TopB, and includes an entry into the context set of the target domain in A, containing TopB’s identity, TopB’s address and a name for TopB (say ‘TopB’). There is now the possibility for processes within A’s organisation to refer to B’s domains and for users to name them. See figure 3.12b. TopA

TopB

Context Policy Reference References

A1

A2

Same Object

TopB

Policy References

B1

Company A

B2

Company B

Figure 3.12b - Interconnecting Two Organisations

At this stage A can refer to B, but not vice versa. To complete the interconnection the reverse process must also be carried out. See figure 3.12c.

74

Chapter 3

The DOME System

TopA

TopB

Context Policy Reference References

A1

A2

Context Reference

TopB

TopA

Company A

Policy References

B1

B2

Company B

Figure 3.12c - Interconnecting Two Organisations

Note that the interconnection which has been made is between two domains with no common ancestors. The user who invokes the operation has no means of referring to the other domain by name using the DOME system. It has been necessary to break the rule that users always refer to objects by name, and have a special operation for inter-organisation connection which enables the user to supply a special address at the user interface. The above example does not achieve the aim of a familiar naming convention. The Domain Naming System (DNS) [RFC1034] is a familiar convention, illustrated below in figure 3.13. We can achieve familiarity by creating in each organisation a domain structure which reflects the upper level structure of DNS. See figure 3.14.

com

ukc

edu

uk

mod

ac

co

susx

bp

ucl

ic

mil

praxis

doc

Figure 3.13 - Standard Domain Naming System

75

Chapter 3

The DOME System

It is simpler to use the DNS system initially but there is no reason why, for example, X500 naming conventions could not be used. Indeed one site may adopt one scheme and another site could adopt a different scheme without any loss of functionality. Sites could use their own scheme because the top level domains are maintained locally, unlike the global entities in DEC EMA [Digital 1989] which must be the same. Figure 3.14 could show BP using an X500 scheme, it would not affect IC users who would still view BP as uk/co/bp.

uk ac

uk co

ac

co

Context References

ic

bp

BP

doc

IC DoC Figure 3.14 - Two Organisations Interconnected with Conventional Names

Note that the use of absolute names to maintain compatibility with DNS depends upon manual maintenance. However the slow rate of change of naming information at the top levels makes this practical [Cheriton 1989].

3.9 Chapter Summary It has been shown in this chapter that the use of domains facilitates the naming and location (by name) of a large number of objects and that grouping for purposes of management is a useful concept. The use of context links is necessary to refer to other domains without any policy implications. This also has advantages for namespace management as it makes its use more flexible allowing objects to be grouped together for convenience rather than for policy. Domains can be used as management positions with the managers that are members of those domains holding that management position.

76

Chapter 3

The DOME System

Domain hierarchies make the management of a large namespace possible and provides a good means of specifying groupings of objects for management purposes.

77

Chapter 4


This chapter describes the DOME Architecture. It describes the minimum interface and operations that are required for an object to be a DOME managed object and introduces the fundamental DOME objects. It introduces the interfaces and operations that the DOME environment offers to the user. The following topics are covered: •


•

DOME Objects

•

Domains

•

Access Control

•

User Authentication

•

User Interfaces

The DOME architecture is based on DOME managed objects. There are certain types of managed object that support the DOME services offered to the user. Other DOME managed objects will be user application objects.

4.1 DOME Managed Objects A DOME Managed Object (managed object) is a software or hardware component that possesses certain attributes (described below) and presents a minimum interface (described in section 4.4) to other managed objects. This is the basic building block for DOME objects; eg. a domain managed object has these basic parts and in addition offers a domain interface for its operations. 4.1.1

Attribute Information

All objects have named attributes that can hold one or more items of information as their contents. Some of these attributes can only be inspected and altered by privileged objects; this is done by using more than one

78

Chapter 4


operation to access the different sets of attributes with the appropriate access rules being applied to them. An attribute may be a single item or a set of items and may be read-only or read-write. Some read-only attributes may, however, be changed internally by the object itself although not through the object interface. The managed object must therefore support get and set operations to access its attributes. The minimum set of attributes that a managed object must maintain is: Essential Attributes These object attributes are necessary for the DOME environment to deal with managed objects; they contain identification and addressing information Unique Identifier Every managed object must have a unique identifier which can be used to refer to managed objects and to distinguish one managed object from another. Unique identifiers are never reassigned. This identifier is required because the name used by a human user to refer to an object may change, and objects may migrate and so change their addresses. It is assumed that names and addresses may be eventually be reassigned to different objects. A unique identifier may be created using the host IP address where the object was originally created and adding a time stamp. This identifier remains unchanged even if the object migrates to a new host. Object Address Objects may be located by their object address consisting of an address part and a generation number. The address part can be a direct network address such as an X.25 or IP number or it can be a distinguished name to be looked up via some sort of directory service such as X500, Arpa DNS or OSI MIB. The generation number is a number that is incremented whenever there is a change to the address part; this may happen if an object migrates from one host to another or the service name is changed in some way. The generation number enables the more recent of two object addresses to be determined.

79

Chapter 4


Object Identifier (OID) An OID is the means by which managed objects can locate, and verify, other managed objects. An OID comprises the managed object’s unique identifier and its object address. The OID is the “unit of reference” for an object. Desirable Attributes The following attributes are really for the human manager but are specified as being compulsory, because if standards have optional parts it can be guaranteed that different implementations conforming to the standard will be incompatible. These attributes are the general basic items that we consider to be interesting and useful information about any object. The object type described below can also help a manager to determine the operations that can be performed upon the object. Creation Time The date and time in GMT when the managed object was created. Creator A string with the creator’s name. This name may be a full name or a user id that is only recognised locally. It may be more useful to hold the creator’s email address eg. [email protected]. Host The host name or address where the managed object was first created. Depending on the underlying support for the managed objects, some systems may allow objects to migrate from one host to another. Object Type This is not necessarily a unique type but may well be unique to the creator and makes it much easier to assess the types of a list of managed objects. This will help a manager to determine the interface supported by the object. If subtyping is involved then the inheritance of operations (type) can be shown by using a “dotted” string which indicates all the operations that the object

80

Chapter 4


supports. e.g. the type “dome.object.domain” would indicate that the object supports the general DOME object interface and the domain interface. Comment Any text that may indicate what the object does, what it is responsible for, why it was created etc. 4.1.2

Operations

These operations must be supported for all managed objects: •

Get an attribute

•

Set an attribute

The following operations will become clearer after reading the next section about domains. They are included here for completeness: •

Get parent list

•

Get ancestor list

4.2 Domain Managed Object (Domain) A domain is a managed object which represents a collection of named, managed objects which have been explicitly grouped together for a purpose eg. to which a common management policy applies. The objects may be resources, workstations, modems, processes etc., depending on the purpose for which a particular domain is defined. A domain is used in the DOME environment to define a “scope,” i.e. a set of member objects over which operations such as configuration management can be performed. Domains can be structured hierarchically using subdomains, where a subdomain is a domain object that is a member of another domain. A domain is thus similar to a Unix directory and can be accessed using pathnames in the same way as Unix pathnames, when applied to domains they are known as Domain Path Expressions (DPE) e.g. One of the objects in figure 4.1 is called “D2/D3/O5”. If necessary, access rules can be used for controlling access to objects in a domain (defining the managers who have access and the operations that they can perform). Domains are persistent

81

Chapter 4


even if they do not contain any objects - it is possible to create an empty domain and later include objects in it. D2 D1 01

D3

02

05

03

04

06

Figure 4.1 - User View of a Domain

It can be seen that domains also provide a name service for objects. Using the hierarchical nature of the domain structure a large number of objects can be managed efficiently. A configuration manager would use the Domain Service to navigate through the domain structure, inspect the contents of the domains and possibly manipulate the objects within them. Domains do not encapsulate the objects themselves - objects may be in more than one domain and managers or external objects may interact directly with an object once located via a domain. Domains actually maintain a (name, reference) pair for each object - figure 4.2. Since the name is the primary source of reference for a manager to refer to an object the name must be unique within the domain. References need not be unique; an object may therefore be included more than once (under different names) within a single domain.

82

Chapter 4


D2

D1 03

01 02

03

03

04

D3

D3 D3

01

02

04

05 05

06

06

Figure 4.2 - Implementation View of figure 4.1

4.2.1

Domain Requirements

Requirements for a Domain include: i)

Users should be able to choose their own names for objects, i.e. aliases for objects should be permitted. The name need only be unique within a single domain. However the overall path name to the domain plus the object’s name must be unique.

ii)

An object may be a member of more than one domain at a time and may have a different local name in each domain. Thus an object can have multiple path names and the path name may change if the overall domain hierarchy is modified.

iii) The implementation of a Domain Service must permit efficient and quick name lookup. Domain path names are likely to be used in a similar fashion to Unix filenames and should be resolved without unreasonable delays. Access to local objects should require minimum access to remote parts of the Domain Service. iv)

Isolation of a local host computer or a local network should not prevent management operations being performed on objects within the local environment although remote objects may be inaccessible.

v)

The Domain Service must have minimal overheads for users performing simple actions like just running a process as a short-lived command. For example, in the Conic system, a Unix command may run 83

Chapter 4


a Conic node. When the command is used, the Conic node is instantiated, it produces its output and terminates. This node when it runs also registers itself with the Conic server and de-registers itself when it terminates; the overhead of these actions is small and causes no visible delay to the user. The Domain Service should continue this tradition. vi) The implementation of the Domain Service must have an availability commensurate with that of the objects to which they are providing access. For example if a set of objects in a domain are running on a single host computer, the domain object holding information about them should be on the same host. It would not matter if the domain is inaccessible when the objects are inaccessible. However if the set of objects are distributed, a single failure should not leave the objects accessible but the domain inaccessible. vii) The information held by the Domain Service must be persistent over machine and/or storage media failures. 4.2.2

Domain Referencing

Domain references to objects are name and OID pairs maintained in a policy set or a context set. A domain’s policy set is a set of object entries, each of which identifies and names an object. A name in the object entry is a local name. The object entry serves two purposes: to allow a user to refer to the object by name relative to its parent domain, and to include it in the domain membership for policy purposes such as the applicability of access rules. A domain’s context set is a set of object entries which refer to other objects, normally domains, which are not members of the domain’s policy set. Contexts are convenient for referencing domains in other organisations without them being subject to ‘this’ organisation’s policies. The policy set and the context set of the domain are collectively known as the name set of the Domain; we only have to distinguish between the two when we are referring to policy. Names must be unique within the name set which means that names used in the policy set cannot be used in the context set and vice versa; OIDs do not have to be unique. 84

Chapter 4

4.2.3



The attributes held by the domain include: •

The policy set

•

The context set

Domains also hold information about the policies that apply to them. This is an implementation issue and will be addressed in section 6.4. 4.2.4

Domain Membership

Direct Domain Membership The objects in the policy set of a domain are referred to as the direct members of that domain and the domain is said to be a parent of those objects. In figures 4.1 and 4.2 above, object O6 is an direct member of domain D3. Indirect Domain Membership Since domains are themselves objects, they may be members of other domains. An object is an indirect member of a domain Dx if it is a member of a domain Dy which is a member or indirect member of Dx. The domain Dx is known as the ancestor of the object. In figures 4.1 and 4.2 above, object O6 is an indirect member of domain D1 and domain D2. 4.2.5

The User View

As previously stated, the human user does not refer to objects by identifiers or addresses, but by names relative to the domain structure. Users can refer to members of a domain by names which are local to the domain, and to any object by hierarchical names. Operations are provided to allow users to query the names of objects in a domain, and to add, alter or remove a local name of an object. User Representation Domains When a human user is registered, a domain is created - his User Representation Domain (URD), to act as the persistent representation of that user. Whenever he logs into the system, a manager user interface process is

85

Chapter 4


created in his URD. The user’s access rights and other authority are defined in terms of this representation domain or its ancestors. Thus, to give an individual user access to a domain of objects, the security administrator creates an access rule in which the URD is the User Domain of the access rule, with appropriate values for its Target Domain and Operation Set. This domain is a persistent domain which will normally be empty unless the user has instantiated a manager object. User Personal Domains The User Personal Domain (UPD) is the default domain in which a user creates managed objects or subdomains. This is similar to a Unix home directory. The user may also have management access rights to other predefined domains. User Personal Domain (UPD)

User Representation Domain (URD) Default Access Rule = all rights

User interface (Manager)

Limited Access Rules

Service Domains

Figure 4.3 - User Representation and User Personal Domains

4.2.6

Operations

Access to the domain’s attributes could be seen as using set and get attribute commands but this is really syntactic sugar for the following operations: •

Include a (name, OID) pair in the policy set of the domain. The name must be unique within the domain’s name set.

•

Remove a (name, OID) pair from the policy set of the domain.

86

Chapter 4


•

Include a (name, OID) pair in the context set of the domain. The name must be unique within the domain’s name set.

•

Remove a (name, OID) pair from the context set of the domain.

•

List the domain’s name set.

4.3 DOME Factory Managed Object (Factory) Objects will be created either within the DOME system using another DOME object or apparently “spontaneously appear from nowhere”. Spontaneous creation of DOME objects occurs when an object is created by the host operating system. It may also occur when a hardware component with a DOME interface is added to a network. If the new object wants to become part of the DOME environment it must register itself with a service which decides where to include it in the domain hierarchy. Objects created within the DOME system are created by special objects called Factories. A factory object supports operations for querying the creation parameters required and for creating the actual object itself. Objects are usually created either as a separate independent process supported by an operating system or as an internal database object within the factory itself. Factory objects have an attribute describing the parameters that they require for the create operation. A human manager interface can use the information to elicit the information, check that the parameters are of the correct type and in the correct range and then tell the factory to create the object. An example of a factory is the Domain Server (introduced in chapter seven). It creates domains and maintains them as internal objects within its own database even though they appear to the outside world as managed objects in their own right.

4.4 Access Control 4.4.1

Introduction

Access control is defined using Access Rules. Access rules are a means of specifying the access rights between a domain of user objects and a domain of target objects in terms of the permitted operations. Access rules themselves

87

Chapter 4


may only be created or altered by managers that have an appropriate Management Role specified for them. This section covers the user view of Access Rules and Management Roles. User View of Access Rules Access Rules are managed by users as single objects representing the user’s specification in terms of names relative to his current context. Domain Expressions There may be a requirement that a manager has access to some objects only if that manager holds two specific positions (i.e. a member of two particular domains); alternatively there may be a requirement that a manager may only have access to objects that are members of two particular domains. This can be achieved by replacing the domain of user objects and the domain of target objects by domain expressions. Domain expressions are basically set operations and are used when referring to groups or sets of objects. They can also restrict the inheritance of policy by specifying direct or indirect members of the domains that they reference. They are defined in table 4.1.

Expression

Object Identities Returned

dom_expr ::= domain@ | domain |

The domain object itself All direct members of the domain, and the domain object itself All members, direct & indirect, of the domain, and the domain object itself The objects returned by either dom_expr1 or dom_expr2 (set union)

domain* | dom_expr1 + dom_expr2 | dom_expr1 ^ dom_expr2 |

The objects returned by dom_expr1 which are also returned by dom_expr2 (set intersection)

dom_expr1 - dom_expr2 |

All the objects returned by dom_expr1 except those returned by dom_expr2 (set difference)

(dom_expr1)

The objects returned by dom_expr1

Table 4.1 - Domain Expressions

Interpretation of the expression is from left to right.

88

Chapter 4


Examples Table 4.2 shows two examples of access rules as seen by users. Rule Id R123

Rule SDom1 , Read , TDomB*

R345

SDom2 , {Read, Write}, (TDomB* - TDomC*)

Meaning Direct members of SDom1 have Read access to all members of TDomB Direct members of SDom2 have Read and Write access to all members of TDomB except those in TDomC

Table 4.2 - Example Access Rules

Given the domain structure in figure 4.4, R123 allows members of SDom1 to Read ObjB, ObjC and the members (if any) of TDomD. R345 allows all members of SDomB to Read or Write ObjB and the members (if any) of TDomD, but not members of TDomC. Access will only be permitted to TDomC if there is another access rule granting permission. SDom1

Source

SDom1

Mgr 1

Target

TDomB*

Permissions

TDomB

Read

Access Rule R123 SDom2

Source

SDom2

Mgr 2

Target

TDomB* - TDomC*

Permissions

ObjB

TDomC

TDomD

ObjC

Read, Write

Access Rule R345 Figure 4.4 - Example Access Rules

4.4.2

Access Rules

Access Rule Format Access Rules are managed objects; they contain the following information, inheriting the attributes of a generic Object: •

Subject Domain Expression (see Table 4.1)

•

Target Domain Expression (see Table 4.1)

•

Operation Set

89

Chapter 4


•

Version Number

•

Comment

The Operation Set values are strings that are interpreted by the underlying implementation; see the relevant implementation notes. The Comment can be set and read by the owner of the Access Rule. 4.4.3

Management Role Objects

Access rules control the operations that may be performed by managers on managed objects but there has to be some form of control over the creation of access rules themselves. Management Role Objects provide this control. These have been developed by Moffett [Moffett 1990] and have been included here to show that the creation and updating of Access Rules can be managed securely but this has not been implemented. Management Role Objects (MRO) provide the means of expressing general management powers by controlling the ability to create or change access rules and MROs themselves. A MRO has the following attributes in addition to standard object attributes: •

Type of the MRO - e.g. Security Administrator;

•

Authority - a set of names of object types which the role types may alter. This is a Read-only attribute whose value depends on the Type of the MRO, e.g. Access Rule for Security Administrator;

•

Role Occupants - a domain expression defining the set of subjects which occupy the role;

•

Subject Scope - a domain expression defining the set of subject objects within which the role subjects have the role;

•

Target Scope - a domain expression defining the set of target objects for which the role subjects have authority.

90

Chapter 4


SDom1

TDomB

SDom2

TDomC

ADMIN

ABC_TARGETS

ABC_SUBJECTS

Example Domains Type Authority Role Occupants Subject Scope Target Scope

Sec Admin Access Rule ABC_SUBJECTS/ADMIN* ABC_SUBJECTS* - ABC_SUBJECTS/ADMIN* ABC_TARGETS* Management Role Object

Figure 4.5 - A Security Administrator Management Role Object

Figure 4.5 shows a Security Administrator Management Role Object for the ABC organisation that allows managers within the ABC_ADMIN domain to create (or alter or delete) Access Rules. The Subject Domain of the new Access Rule can contain domains or objects in the ABC_SUBJECTS domain but not the ABC_ADMIN domain. The Target Domain of the Access Rule can contain domains or objects in the ABC_TARGETS domain. The purpose of this MRO is to allows managers in ADMIN to create access rules to the target domains for subjects other than themselves. The access rules in figure 4.4 could have been created by such a manager using this MRO. In this example organisation, the Role Type is one of Owner, Manager or Security Administrator, and the Authority value is one of: Owner, Manager, Security Administrator, or Access Rule. The values have the following meaning: Authority Value Owner Manager Security Administrator Access Rule

Meaning May create and delete Owner MROs May create and delete Manager MROs May create and delete Security Administrator MROs May create and delete Access Rule objects

Table 4.5 - Management Authorities

91

Chapter 4


Different organisations may have different meaning for the Role Type and hence different Authority values for the roles. In this organisation the following values are used: Role Type Owner Manager Security Administrator

Authority Possessed by Occupant Owner, Manager Security Administrator Access Rule

Table 4.6 - Role Types and Authorities

4.4.4

Access Rule Operations - User Interface

This section defines the operations upon access rule and management role objects which are provided at the service interface. Fixed Policy on Access Rule Operations Regardless of the positive authorisation given by (other) access rules, operations on access rules are only permitted provided the following rules are conformed to. They apply to the new attributes of access rules which are being created; to both new and existing attributes of access rules which are being altered; and to the existing attributes of access rules which are being destroyed. There must be a single MRO satisfying: •

Authority set contains "Access Rule" (e.g. a Security Administrator MRO);

•

The originator of the operation is a member of the Role Occupants of the MRO;

•

The Subject Domain (existing and/or new) is a subset of the Subject Scope of the MRO, and;

•

The Target Domain (existing and/or new) is a subset of the Target Scope of the MRO.

The reason for insisting that the originator has both Subject Scope and Target Scope from a single MRO, is to allow such policies as the following: the Security Administrator can make access rules to allow subjects in SDomA access to files in FDomA, and also to allow subjects in SDomB access to files in FDomB, but not to allow subjects in SDomA access to files in FDomB or vice 92

Chapter 4


versa. So the Subject Scope and Target Scope must be tightly coupled together. Operations on Access Rule Server The Access Rule Server is a managed object that acts a factory for creating access rules. It maintains Access Rules as a database but they appear as individual objects to other objects. The Access Rule Server is responsible for checking that a new or modified Access Rule conforms to the fixed policy above. The only operation offered by the Access Rule Server is: •

Create an Access Rule

Operations on Access Rule Objects The Access Rule objects can be listed, altered and destroyed. The alter and destroy operations must be within the fixed policy above. Their operations are: •

Destroy

•

Alter

•

List Rule

4.5 User Interfaces The Domain Manager is the human user’s interface to the DOME system. The Domain Manager can be used as a browser to monitor the system and used to create, destroy and manipulate domains using the Domain Service. The Domain Manager, however, has no special privileges. It appears to DOME as any other object so all domain requests will be subject to the normal access control mechanisms. There will be a separate instance of the Domain Manager for each logged-on user performing management tasks. There may be a number of different implementations of the Domain Manager depending upon the hardware or operating environment used. These will include a keyboard driven interface on Unix (“D”), a graphics interface on a Mac (“M”), a Smalltalk interface (“S”) and an X Windows [Scheifler 1986] interface (“X”).

93

Chapter 4


User Terminal Interface

DOME Services Interface Generic User Interface Manager

Control Monitoring

Control Generic Interface Manager

User State Manager

Monitoring

Figure 4.6 - Composition of the generic Domain Manager

Since the work to be done by the different implementations will be the same in all cases it can be seen that only the user interface part will change. This leads to a simple split of the Domain Manager into two parts, the core part, the User State Manager which will do most of the work and the x Interface Manager which will be specific for each different interface. Figure 4.6 shows the generic makeup of the Domain Manager and figure 4.7 shows as an example the Graphical Domain Manager. This split of functionality can be compared to the DEC EMA management model, the interface being DEC’s presentation layer and the USM being a combination of DEC’s function and access layers. DME’s object categories and HP’s user interface, management application and communication profile have similar functions.

G (Graphical) User Interface Manager

G Interface Manager

User State Manager

DOME Services Interface

Figure 4.7 - The Graphical Domain Manager

94

Chapter 4


The G Interface Manager accepts user requests from the user terminal and converts them into a form acceptable to User State Manager. This transforms object references and interfaces to the DOME services and after processing them hands the output to G Interface Manager for display to the user. The advantage of this design is that User State Manager can be written once and used in all the different types of User Interface Manager and each x Interface Manager can concentrate on the interface knowing that there is already an implementation of all the functions to be performed. 4.5.1

User State Manager (USM)

The User State Manager has two functions: •

To maintain a user’s state variables, e.g. the names of his User Representation Domain and User Personal Domain.

•

Using the state variables, transform the user’s operations from messages in which objects have local names to messages with object references which it passes across the DOME Service interface.

The states include: •

Name of User’s Representation Domain. This is the domain which represents the user. The USM must be a member of this domain from which it derives the policy affecting the User.

•

Name of User Personal Domain. This is the initial Current Domain for the user.

•

Name of Current Domain.

All domain path expressions that do not start with a ‘/’ will be interpreted relative to the Current Domain. The “Parent Domain” of an object will refer to the immediately preceding domain in the Domain Path Expression; if the Domain Path Expression consists of only one element then the parent domain is the Current Domain. The USM will keep track of the path used to get to a particular object and can therefore access parent, grandparent etc. The User State Manager interface has two classes of operations: •

USM operations. These are operations to change or query the USM state variables.

95

Chapter 4

•


USM DOME Domain Service Operations. Every operation supported by the domain service has a corresponding operation in the USM interface. It will be a configuration task to maintain a mapping table of the operations, together with information about their parameters. The USM will transform the operation message, as described below, and send it to the appropriate object.

The User State Manager operations reflect to the user the operations that are offered by the domain service. All the operations are subject to restrictions imposed by the DOME environment itself. The operations borrow heavily from Unix style commands which present a well-known, simple and consistent interface. 4.5.2

USM Operations

These operations change or query the internal state of the USM: Set Representation Domain This operation is used to set the manager’s actual location within the domain hierarchy. The USM is acting in the role of a manager. The USM must include itself in a domain (given the correct access permissions) before performing management activities on other objects. All subsequent operations will get access permissions (policy) with respect to this domain. Set Current Domain This operation will set the current domain to its argument which is a domain path expression. The current domain is simply a means of allowing a prefix to be added to some path expressions, it also specifies the default context for some of the other operations. If the path expression is empty then the current domain will become the home domain, it the path expression starts with a ‘/’ character then it will be read relative to the root domain otherwise it will be relative to the current domain. Set Personal Domain This operation will set the personal domain internal variable to its argument which is a domain path expression. The personal domain simply provides a

96

Chapter 4


default location for the “Set Current Domain” if a domain path expression is not given. 4.5.3

USM DOME Domain Service Operations

These operations change or query the state of domains: Make Domain Given a domain path expression this operation will create a new domain and include it in the correct parent domain. i.e. make domain /a/b/c/d would create domain d in domain /a/b/c. Destroy Domain This operation will destroy the domain named in its domain path expression argument. It is left to the DOME system to determine if the domain is empty and return an error status. Include Object This operation will add an object to a domain’s policy set. The semantics of the operation follow the Unix semantics of the mv and cp commands. For example, given the object to include as / p e o p l e / f r e d and the target argument of posts/skilled/painter may result in one of two new object entries. If the target is a domain, the object will be included as p o s t s / s k i l l e d / p a i n t e r / f r e d . If the target does not exist but p o s t s / s k i l l e d is a domain then the object will be included in p o s t s / s k i l l e d with the name p a i n t e r . Unlike Unix, however, if posts/skilled/painter is a non-domain managed object the operation will fail; Unix would replace it. Figure 4.8 shows this naming scheme graphically.

97

Chapter 4


People

Posts Skilled Painter

Posts Skilled

becomes Posts Skilled Painter

becomes Posts Skilled

Fred

posts/skilled/painter

Fred

Painter

Figure 4.8 - Adaptive Naming of Object on Include

This operation and others that work in a similar fashion are implemented entirely within the USM itself. The USM determines if the target name exists or not and whether it is a domain; the USM then constructs the appropriate name and calls the domain service operations. Include Context Link This operation will add an object to a domain’s context set in a similar manner to the include operation, above. Remove Object This operation will remove an object name entry from a domain. Destroy Object This operation will remove the object named in its argument from the Domain System. The object will also be removed from all of its parent domains. List This operation will list all the objects in the Current Domain or those specified in the optional Domain Path Expression.

98

Chapter 4


4.6 Chapter Summary This chapter has introduced the architecture that will support the DOME system described in chapter three. The attributes and interface operations necessary for all DOME managed objects have been specified; these include “desirable” attributes such as creation date, creator and a comment. The interaction of a human user with the DOME system has been described using a User Representation Domain for the manager object presenting the user interface to the user and a User Personal Domain being the default domain with full access rights containing the user’s managed objects and subdomains. Access rules have been elaborated with Domain Expressions; these allow a manager to fine-tune the scope of the access rules. Using domain expressions the propagation of access rules can be limited and objects can be selected by their domain membership; e.g. domain set intersection will select managed objects that are a member of two or more domains. The basic functionality of a DOME user interface has been described. The user interface comprises an interface manager and a state manager. The interface manager is specific to the I/O medium that it is connected to, for example a character interface for a TTY or a windowing interface for a graphics based system. The state manager is common to all the interface managers; it contains the current state of the user interface and provides basic domain browsing and domain manipulation operations.

99

Chapter 5

Examples

The examples shown here are the actual steps that a Manager uses to perform management operations within the DOME environment. A complete managed system is set up comprising a managed domain and a manager domain. The use of context links is also shown for name management and for federation. This example shows how the DOME environment can be used to manage a cellular telephone network. It shows how subscribers can be added to different systems allowing control over the authorisation and access to the network.

5.1 Cellular Network Example This example is based on a Distributed Cellular Network [Sloman 1992] implemented by [Bannister 1990] using Conic [Kramer 1983]. The original exercise had no concept of access authorisation but had been done to show how the cellular network and accounting information could be implemented in a distributed system. The aim of this example is to show how authorisation for mobile access to the telephone network can be managed. A cellular network is designed to allow users to make telephone calls from their mobile telephones via radio to base stations and on to other users on either the land-based Public Switched Telephone Network (PSTN) or another mobile on a cellular network. The base stations (or Cells) are spread around the country with groups of them being connected to Intermediate Message Switching Centres (IMSC). The IMSCs are in turn connected to a Main Message Switching Centre (MMSC) forming the hierarchy shown in figure 5.1. The MMSC are connected to the Public Switched Telephone Network (PSTN) and MMSCs of other providers. 100

Chapter 5

Examples

Main Message Switching Centre

Intermediate Message Switching Centre

Base Station

Base Station


Connection to another MMSC and/or PSTN


Base Station

Mobile Telephones Figure 5.1 - The Cellular Network Topology

The mobiles roam from base to base as they travel around. They can make and receive calls via their local base. If a call is in progress when a mobile roams from one base to another the first base “hands over” the call to the second base station. Calls take the shortest route from end to end, i.e. if the two mobile telephones are connected via the same base, only that base will be involved in the connection. If the mobile telephones are connected to different bases which in turn are connected to the same IMSC, that call is routed through just that IMSC. For configuration management purposes we are concerned with the access given by the base stations to the mobiles. Mobiles must be authorised before being able to make a call and it must be possible to remove mobiles’ 101

Chapter 5

Examples

authorisation when necessary. access rules:

This gives us the following domains and

Network Managers Include Access Connect Access

Mobile Domain

Base Station Domain

Figure 5.2 - Managing Service Access for Mobiles

It can be seen that, just by adding mobiles to the Mobile domain, they are permitted to use any of the base stations in the Base Station domain. There is already a great saving of effort; without domains, access rules or access control lists would have to be created between every mobile and every base station. Base stations that are to be taken out of general service eg. for testing, can be removed from the base station domain making them inaccessible to all ordinary subscribers. This situation would be all that is required for a cellular network with only a single network provider. However there are many providers, different countries generally have their own national provider, sometimes there are several within the same country. If the above domain scheme was employed for each provider, then mobiles that wanted to roam from one network to another would have to register with each network separately. This would involve much paperwork applying to each provider and each provider would have to generate separate bills. It would be much more convenient if the network providers could make agreements with each other to let them control the access of their registered mobiles to other networks. This could be done on a provider to provider basis; it would not require the agreement of all the providers.

102

Chapter 5

Examples

If provider A wanted to allow provider B authorisation access to provider A’s network, provider A could do this by using a sub-domain. Provider A can simply create a sub-domain in the Mobile Domain giving Provider B the privilege to include and remove mobiles that are registered in Provider B’s registration Domain. This is shown in the figure below: Provider A

Provider B Include Access Connect Access

Provider B Provider A's Authorised Mobile Domain

Provider A's Base Station Domain

Figure 5.3 - Showing How Provider A Grants Access to Provider B

Figure 5.3 shows how network provider B can allow mobiles to access provider A’s network. Provider B may have many such agreements with other networks; B’s view of these domains can be simplified by including all the domains in one single domain accessible by provider B (figure 5.4).

103

Chapter 5

Examples

Provider B's Managers

Include Access Create & Include from Access

Network C Network A Provider B's Registration Domain

Network D

Provider B's Foreign Agreement Domain

Figure 5.4 - Provider B’s Namespace Management

Providers can use domains to: •

register and de-register mobiles

•

allow or prohibit mobiles access to their network.

•

allow or prohibit mobiles registered in their country access to other networks.

•

allow or prohibit other operators access to perform the above action.

5.2 Conic Simulation of the Mobile Telephone example This section describes the actual integration of the Conic Mobile Telephone example into the DOME system. A very brief description of Conic is given below followed by a description and pictures of the implementation. A more complete description of Conic can be found in [Kramer 1983] and [Dulay 1987]. 5.2.1

Conic Basics

Conic comprises a programming language, a configuration language and a multi-tasking kernel supporting distributed applications using message passing. The basic component of Conic is a task module which is a single threaded code module with strongly typed message ports for external communications. Task modules can be grouped together using the

104

Chapter 5

Examples

configuration language into group modules which contain tasks and group module ports; the tasks’ ports are linked to each other and/or the external group module ports. The group module encapsulates the enclosed modules and from outside looks identical to a task module; group modules can also be included in other group modules. As we are not going into the depths of Conic here we will just refer to modules, they may be complex group modules or simple task modules. A module will have the form shown in figure 5.5. Directional Message Port Task Module or Group Module

Figure 5.5 - A Conic module with an interface

Conic modules are loaded and run as nodes. A node is linked code containing the Conic kernel, operating system support modules (ordinary Conic modules that know a little of the kernel’s internal structure) and the user’s application modules(s). The node also has node ports for the internal modules to use for communications, they are all that is visible from the outside world. The Conic kernel supports multi-tasking in Unix processes and bare 68000 single board computers.

105

Chapter 5

Examples

Application Interface

Conic Management Interface

Conic Multitasking Kernel

Figure 5.6 - A Conic node

A single Conic node looks something like figure 5.6. The Conic management interface comprises a standard set of ports; they facilitate: retrieval of node information, dynamic linking of ports to other nodes, and debugging by remote nodes acting as managers. Other ports are those declared by the distributed application for communication with other parts of the application in other Conic nodes. 5.2.2

DOME Integration

We have stated previously that all objects in the DOME system must support a minimum management interface. It can be seen that a Conic node like the one in figure 5.6 can be made into a DOME object by adding the appropriate interface. In Conic we can achieve this by adding a DOME Management Module and external ports to a node as in figure 5.7.

106

Chapter 5

Examples

Application Interface

Conic Management Interface

DOME Management Interface

DOME Management Module

Conic Multitasking Kernel

Figure 5.7 - A Conic node containing a DOME Management Interface.

We now have a DOME managed object without affecting the application, in fact the application does not even know that it is now a DOME object. The DOME management module(s) also know nothing about the application, they are just there to communicate with the DOME system. We stated previously that a DOME object can only be created within a domain. There is a problem with Conic nodes as they can be started by anyone by using a Unix command or by booting a single board computer. As far as DOME is concerned the object spontaneously pops into existence. This is dealt with by requiring the Conic DOME management module to let the DOME system know when the Conic node is started, the DOME system will then include it in a default domain (all users have their own default domain from which they can then move the object to the required domain).

107

Chapter 5

5.2.3

Examples

Conic Telephone Example

The Conic node structure for the mobile telephone application is shown in the “Network” window, figure 5.84 . This is the connection layout for the nodes showing the communication pathways used by this application. The mmsc nodes are the Main Message Switching Centres, the imsc nodes are Intermediate Message Switching Centres, the b nodes are base stations and the m nodes (in black) are the mobile telephones themselves. The am and a c nodes are Accounting Managers and Accounting Controllers and are not relevant in this example. All the nodes are numbered in an appropriate manner reflecting their position in the hierarchy, it can be seen that many more nodes may be added to this structure.

Figure 5.8 - Communication Structure of Conic Telephone Nodes

(Shows port interconnections) When the mobiles roam from base station to base station, the black boxes representing the mobiles move and show their connection to the new base station. They communicate using the shortest path through the

4

The Network and Domains screen dumps are from an existing graphical configuration tool [Kramer 1989] adapted to make it capable of displaying and manipulating domains using drag and drop. It cannot, however, show or manipulate the access rules themselves.

108

Chapter 5

Examples

interconnecting nodes. i.e. if both mobile telephones are connected to the same base station their messages will go no higher than the base station itself. To integrate the Conic telephone example into the DOME environment the DOME management interface was added to the Conic node configurations. This was all that was required for most of the telephone example nodes but the actual mobile telephone code had to be changed to make it aware of possible DOME configuration restrictions when trying to roam. The mobile telephone has to be aware that a connection to a base station may fail because it is unauthorised and, if so, it must indicate “Access Barred” to the user; this was a function not previously envisioned when it was first created. Appendix D shows screen dumps of the mobile telephones in action. The domain based view is, however, quite different. The “Domains” window (figure 5.9) shows the domain hierarchies of the base station domains and figure 5.10 shows the mobile domains. The base stations and mobiles are shown as being members of the four countries Ireland, England, Scotland and Wales.

Figure 5.9 - Base Station Domain Hierarchy (Shows domain membership of base stations)

109

Chapter 5

Examples

Figure 5.10 - The Mobile Telephone Domain Hierarchy (Shows domain membership for mobiles)

Appropriate access rules can be created between domains that allow mobiles in the mobile England domain to connect to base stations in the base station England domain and similarly for the other countries. Currently in figures 5.9 and 5.10 these access rules allow mobile m2102 to roam between b112 and b212 and mobile m1101 is allowed to use only b111. We now have a view of an active DOME system that allows or prevents (strictly - “does not allow” as permission is only granted if a positive access rule exists) the mobile telephone nodes in the Network window from connecting to base stations purely based on the Domains window view i.e. the domains that the mobiles and base stations are in. Currently there are only four access rules defined but the mobiles are restricted to base stations in their own country. If they are to be able to connect to other countries’ base stations more access rules are required. It is probably the case that any mobile registered in any of the Great Britain domains will want to be able to connect to any of the base stations in those domains. One such way of doing this would be to create two new access rules 110

Chapter 5

Examples

from each of the three Great Britain mobile domains to the other two Great Britain base station domains. This would give us nine access rules in total to achieve this. A better solution is to create a GB domain above the England, Scotland and Wales base station domains, see figure 5.11.

Figure 5.11 - A Great British Domain

The addition of a GB domain means that we now only require three access rules permitting access by the three countries’ mobiles to the new GB domain; inheritance of access rules ensures that they now have access to the required domains below it. If a mobile is to have access to both the Ireland domains and to the GB domains, it can be included in both the Ireland mobile domains and one of the other domains. Obviously there must be some kind of agreement between the different authorities as to the uniqueness of the telephone numbers and billing practices but these are beyond the scope of this example.

5.3 Configuration Management This example shows how distributed applications can be managed within a University environment where there are many students configuring their 111

Chapter 5

Examples

own distributed applications. This example also shows how a group project can be set up allowing several designated students access to it. Within a University environment domains can be created for the different years and for different students within each year. Figure 5.12 shows a small domain hierarchy with two domains for first year BSc students. BSC Students

Year 1

Year 2

kpt

jnm

Figure 5.12 - Domain Structure for Students

A particular student’s domain setup would look like figure 5.13. There would be a User Representation Domain (URD) (section 5.2.4) where the student’s management interface resides. There is an access rule between the URD and the student’s User Personal Domain (UPD) allowing objects and domains to be created and deleted in the UPD by a manager representing the student in the URD. Figure 5.13 shows two sub-domains that the student has set up for exercises. Exercise 1 shows some components of the exercise that have been created. The fact that they are in the same domain does not imply that they are on the same host computer; in a distributed exercise they would definitely not be on the same host.

112

Chapter 5

Examples

kpt_URD

kpt_UPD Access Rule

Exercise 1

Exercise 2

Figure 5.13 - Student’s Exercises

Figure 5.14 shows a single domain containing the distributed application and the interconnections between the different modules that comprise the application. Using an appropriate management tool the links between the modules can be changed to configure the application correctly. This is an example of an extended DOME manager, in addition to understanding domains and allowing the user to manipulate them it also understands application specific operations; in this case Conic configuration operations cf. Management Modules in DEC EMA. This allows the manager to interrogate and manipulate Conic modules. We have implemented a text-based version of an extended DOME manager that also performs the functions of the Conic Interactive Configuration Manager (“iman”) [Twidle 1986].

113

Chapter 5

Examples

Conic Node 2

Conic Node 1

Conic Node 4

Conic Node 3

Figure 5.14 - Configuration of a Conic Distributed Application

With the setup so far described every student has complete control over their UPD by using a manager which is a member of their URD; no one else has any authority over their domains. However, it is often the case that several students choose to do a group project. These group projects usually take the form of a more complex distributed application than an individual project. One such example might be a robot controller and assembly line which involves programming a robot arm, programming the assembly line which comprises motors and sensors and programming a user interface to control the whole project. The students design the overall composition of the project in terms of Conic modules reflecting the functionality of the project. They design the interfaces for the various modules and divide the work up amongst themselves usually taking one or more modules which they will implement. Obviously the previously described domain structure is sufficient for each student to write and test the modules that they have chosen to do. Once they have created their modules they need to link them to the others’ modules, they require a group exercise domain. One of the students (S1) can create a new domain within his/her UPD and then grant access to it by creating appropriate access rules between the other students’ URD and the group project domain.

114

Chapter 5

Examples

S1_URD

S1_UPD S2_URD

Key

Group Project

Access Rule

S3_URD

Figure 5.15 - Access Controls for Group Project

The other students can create context links in their UPDs to the group project domain using the domain hierarchy for naming purposes. They can now all create their modules in the new domain and configure the modules for their project. S1_URD

S1_UPD S2_UPD

Key

Group Project

Access Rule Includes Context Link

Robot Project

S3_UPD

Project 260

Figure 5.16 - Students’ Context Links to Group Project Domain

115

Chapter 5

Examples

5.4 Chapter Summary A domain hierarchy can be set up for a cellular telephone network allowing airtime providers to authorise mobile telephones to use the network. An existing Conic telephone application has been taken and using a display tool, management control using domain membership has been demonstrated. The telephone example shows that with only a small addition to an existing distributed application the DOME system can manage both the namespace and can impose policy on applications. This example has shown how easy it can be to control access to objects just by moving objects from one domain to another. The telephone example has also shown how useful policy inheritance can be. Without policy inheritance, a common function like adding a mobile to the three countries of Britain involves many operations for each mobile to be given access. With policy inheritance, by creating e.g. a Great Britain domain, the number of operations are dramatically reduced. The configuration management example is a good choice. A University environment is probably not as ordered or controlled as a commercial company in terms of trust and integrity within its user community. The example has shown how different users can manage their own distributed applications and co-operate in managing a group project. It has also successfully shown how flexible the DOME architecture is in allowing the students to prepare for a group distributed application project.

116

Chapter 6

DOME Services

This chapter describes the DOME Services that support the DOME Architecture. It describes, more formally, the interfaces and operations supported by the components introduced in chapter four.

6.1 Conventions Operations are shown in tabular form grouped either by the object to which they can be applied or grouped in terms of related operations e.g. read and write operations. The table below shows the general form of the operation tables. The “Operation” column shows either a virtual operation or a real operation. The virtual operation is a dummy operation that is used to define pre- or postconditions upon which several other operations may be based. The “Inherits From” column shows the operation parameters and conditions upon which the current operation is based; the current operation’s parameters and conditions are added to those inherited from the inherited operation(s), if any. The “Parameters” column defines the parameters required by the operation (C) and the results generated by the operation (R). The “Conditions” column contains the required conditions before the operation can proceed both in terms of authorisation (A) and other conditions (F). The result (R) of the operation is also described here; these may be used as the preconditions of other operations. Operation (virtual_operation)

Inherits from (virtual_operation)

an_operation

(virtual_operation) or operation

Parameters Conditions (C) call parameter (F) Feasibility preconditions (R) result parameter (A) Authorisation preconditions (R) Result (Postconditions) (C) call parameter (F) Feasibility preconditions (R) result parameter (A) Authorisation preconditions (R) Result (Postconditions)

Table 6.1 - Layout of Operation Tables

117

Chapter 6

6.1.1

DOME Services

Operation Names

Operation names are composed of the group/class that the operation belongs to followed by the operation name itself. e.g. operation Object_Get_Attribute is an operation that can be performed upon any object within the DOME system and operation D o m a i n _ R e m o v e is an operation that can be performed upon any domain object.

6.2 DOME Objects All objects in the DOME environment must present a minimum interface. They must have the set of operations described in the previous chapter and therefore will be able to provide a minimum standard amount of information about themselves. 6.2.1

Virtual Operations

These virtual operations are defined here to capture the general elements which most operations have in common: Operation (Any_Operation)

(Destroy)

Inherits from

Parameters (C) OID of the target object (R) Status return

(Any_Operation)

Conditions (F) Target object exists (A) There is an Access Rule with originator, target and operation in the Subject & Target Domains and Operation Set. (R) The object is destroyed. (R) The OID of the object is removed from the Object Sets of the domains containing it.

Table 6.2 - Virtual Operations

Note that all operations that inherit from “(Any_Operation)” always include the OID of the object upon which the operation is to be performed - the target OID. The target OID is included for two reasons: 1)

To allow objects to be transparently encapsulated within other objects. In this case the address of the target object and the encapsulating object will be the same but the unique ID is different. The encapsulating object can tell that the operation is intended to be performed by one of its encapsulated objects and can pass it on. This

118

Chapter 6

DOME Services

is useful for very small objects which could be more efficiently implemented by a database simulating all the separate objects. 2)

These is no guarantee that an address will not be reused by another object so the OID should always be checked on receipt.

There is also a status return which is simply a string with success or failure information; these are described in Appendix A. Operations will only succeed if the target object exists and the operation is authorised by an Access Rule. The destruction of an object is an atomic operation, in which the object is both destroyed and removed from its parent domains. 6.2.2


All objects have named attributes that can hold one or more items of information as their contents. Some of these attributes can only be inspected and altered by privileged objects; this is done by using more than one operation to access the different sets of attributes with the appropriate access rules being applied to them. An attribute may be a single item or a set of items and may be read-only or read-write. Some read-only attributes may, however, be changed internally by the object itself although not through the object interface. Items may be any one of the following basic types: String, (4 byte) Integer, Boolean or Array. The attributes may be accessed using the following operations: Operation Object_ Get_Attribute Object_ Set_Attribute

Inherits from (Any_Operation) (Any_Operation)

Parameters (C) Attribute Name (R) Attribute Value (C) Attribute Name (C) Attribute Value

Table 6.3 - Attribute Operations

119

Conditions

Chapter 6

DOME Services

There is a minimum set of attributes that all objects hold:

Attribute Name OID

Attribute Type BinaryString

Creation Time

String

Update Status Read Only / Object Update Read Only

Creator Host Object Type

String String String

Read Only Read Only Read Only

Object Creation Comment Object Comment

String

Read Only

String

Read/Write

Object Information

List of Strings

Read Only

Description The actual OID of the object. If the object migrates it will update the address part Creation date and time expressed in seconds since 1st January 1970 Email address of the object creator DNS/IP address of host computer “Dotted” type string showing main type and subtypes. e.g. iman, domain, usm, usm.gman Comment generated at creation time Comment changed as necessary by authorised objects Returns the values of the above attributes: OID, Creation_Time, Creator, Host, Object_Type, Object_Creation_Comment and Object_Comment.

Table 6.4 - Object Information Attributes

120

Chapter 6

6.2.3

DOME Services

General Operations

These operations may be applied for any object5:

Operation Object_ Parents_Set Object_ Ancestors_Set

Inherits from (Any_Operation)

Object_ Lookup_OID

(Any_Operation)

Object_Lookup_ Pathname

(Any_Operation)

(Any_Operation)

Parameters Conditions (R) Unordered set of parent OIDs (R) Unordered set of parent and indirect parent OIDs (C) Pathname (to be (F) If pathname begins from the interpreted relative root then the target OID is to the target OID) ignored and may be null (R) OID of input pathname and null pathname or OID and unresolvable part of input pathname (C) OID whose pathname is to be looked up (R) Pathname of input OID relative to the target OID

Table 6.5 - General Object Operations

The Object_Parents_Set and Object_Ancestors_Set operations provide the domains of which an object is a direct member (parent domains) or direct/indirect member (ancestor domains). These lists are not ordered or structured, but if an application requires it, structuring of the list could be considered as a future enhancement. The Object_Lookup_OID and Object_Lookup_Pathname operations are provided in order to enable translation between OIDs and names. If there is more than one possible pathname for an object then Object_Lookup_Pathname will return any one of them indeterminately.

5

The object itself does not hold its parent set as an attribute. This would require the object to be notified whenever it is included in or removed from a domain’s policy set. As an implementation issue, to keep objects simple, this information is held within the DOME service itself.

121

Chapter 6

6.2.4

DOME Services

DOME Factory Objects (Factories)

Factory objects have an attribute describing the parameters that they require for the create operation: Attribute Name Create Values

Attribute Type List of (Name, Value) Strings

Update Status Read Only

Description Parameter names and types

Table 6.6 - Factory Specific Attributes

This enables a manager object to query a factory object for its parameter requirements. It can then ask the user to supply the correct values by giving the name of each argument and performing some basic type checking upon the answers. The create operation itself is given as a virtual operation because typically the factory object will require other parameters or conditions before being able to create a new object. Operation (Create)


Parameters (R) OID of new object

Conditions (R) A new object exists.

Table 6.7 - Virtual Creation Operation

e.g. in the case of creating a new domain or a new access rule we have the following definitions: Operation Domain_Create6 Access_Rule_ Create7

Inherits from (Create) (Create)

Parameters

(C) User Domain (C) Target Domain (C) Operation Set (C) MRO

Conditions (R) The new Domain’s Policy Set is empty. (A) Subject & Target Domains are within originator's Subject & Target Scopes in MRO (R) The new object has the attributes defined by the parameters

Table 6.8 - Example Creation Operations

6

For further information about this operation see Section 6.3.2

7

For further information about this operation see Section 6.4.3

122

Chapter 6

DOME Services

Note that the Access Rule Create operation requires a valid Management Role Object to authorise and limit the actual access rule being created (see section 5.4.3). The access rule factory performs its own validation checks using the MRO before creating the access rule; this is in addition to the normal domain policy checks made when the operation is invoked. User View The user sees object creation and inclusion in a domain as a single operation. Two operations will actually be performed by the user interface: create and include, if the include fails then best efforts will be made to destroy the object. Operation Atomic_Create

Inherits from (Application Specific Create)

Parameters (C) Parent domain (C) Local name (R) OID of new object

Conditions (R) The object is included in the parent domain

Table 6.9 - User’s Create Operations

6.2.5

Object Destruction

The destruction of an object is an atomic operation, in which the object is both destroyed and removed from its parent domains. The destroy operation is an operation upon the object itself.

6.3 Domain Service The Domain Service supports the creation and management of Domains. The Domain Service is one of several services provided to the user, as illustrated in figure 6.1. The user interface software, whether a GUI, a text interface or some other style, carries out the task of transforming the user’s input and output to and from the operations which are invoked at the Domain Service Interface and other service interfaces. One major difference between the user view and the service interface view is that users will refer to all objects by means of names, while the service interfaces will refer to them by their identifiers.

123

Chapter 6

DOME Services

Other Services Interface

User Interface

User Interface Software

Other Services

Domain Service Interface Domain Service

Figure 6.1 - Domain Service Interface

The Domain Service, which is available both to the user interface software and to other services, provides a means of grouping, naming and locating objects. The assumption is that a managed object is always created in a domain although for simple applications this may be hidden from the user, c.f. on Unix where files are always created in a directory. Objects may then be included in other domains, removed from domains or destroyed. A domain can be queried to find out the names (and identifiers) of objects which are members of that domain. 6.3.1

Domains as Managed Objects

Domains are themselves objects inheriting the attributes of a generic Object and in addition they provide the following attributes: •

Policy Set - identifying each member of the domain.

•

Context Set - references to non members of the domain.

•

Access Control List - policies applying to the domain and its policy set members

•

Other information, such as permitted object types (in the form of constraints).

All objects known to the Domain Service, whether Domains or Managed Objects, have a Parent Set, identifying each Domain of which they are members.

124

Chapter 6

6.3.2

DOME Services

Domain Service Operations

This section describes the user view of the interface provided by the Domain Service. It is split into sub-sections reflecting the type of operations. Factory Operations - Create and Destroy Domains Operation Domain_Create

Inherits from (Create)

Domain_Destroy

(Destroy)

Parameters

Conditions (R) The new domain’s Policy Set is empty (F) The domain’s Policy Set is empty.

Table 6.10 - Domain Factory Operations

Domain Object Operations These operations access the internal state of a Domain: Operation Domain_ Include


Parameters (C) OID and local name of the member to be included

Domain_ Remove

(Any_Operation)

Domain_ Add_Link

(Any_Operation)

(C) OID and local name of the member to be removed (C) OID and local name for linked object

Domain_ Remove_Link

(Any_Operation)

(C) OID and local name of object to be unlinked

Domain_List

(Any_Operation)

(R) Policy Set and Context Set as (local name, OID, Set type) tuples

Conditions (A) There is an Access Rule (AR) with originator in its Subject Domain, member object in its Target Domain, and Domain_Include_Source in its Operation Set. (F) Local name is not in Policy Set or Context Set. (R) (OID, local name) entry is in the Policy Set (F) Member object OID and local name are in the Policy Set. (R) (OID, local name) entry is removed from Policy Set. (F) Local name is not in Policy Set or Context Set (R) (OID , local name) entry is added to the Context Set (F) Member object OID and local name are in the Context Set (R) (OID, local name) entry is removed from the Context Set

Table 6.11 - Domain Object Operations

Note that there are two access rules required for Domain_Include. Including an object in a domain’s policy set is a very powerful operation. It gives managers of that domain the same access to the new object as it does to the

125

Chapter 6

DOME Services

other objects already in the domain. Obviously, we cannot allow any object that the manager can see to be added to one of the Manager’s domains; there must be another form of access control pertaining to that object. The manager also requires Domain_Include_Source permission applied to the object or object’s parent domain before being allowed to include it in another domain’s policy set. This restriction is not required for adding an object to a domain’s context set as no change in privileges are involved. •

One access rule is required by inheritance from (Any_Operation). This states that there must be an access rule allowing the originator to perform the Domain_Include operation on the target domain.

•

The other access rule is required by the authorisation precondition. This states that there must be an access rule allowing the originator to perform the Domain_Include_Source operation on the object to be included.

There is no precondition for Domain_Remove that there must be at least one other parent domain of the removed member. It is an implementation decision as to whether this operation should return a failure status if the object has only one parent.

6.4 Access Control 6.4.1

Introduction

This section covers two aspects of access control implementation, the user view having been covered in section 4.4.4: •

The corresponding mechanism view of the objects and operations

•

Enforcement of access control.

User & Mechanism Views of Access Rules Access Rules are managed by users as single objects but their implementation mechanism is Access Control Entries (ACEs). These are distributed across the target domains affected by an access rule and held in Access Control Lists (ACLs).

126

Chapter 6

DOME Services

We need to distinguish three different views of Access Rules: •

The user view of an Access Rule is a single object representing the user’s specification in terms of names relative to his current context;

•

The source view of an access rule is identical to the user view except that all objects are specified in terms of OIDs; and

•

The mechanism view of an access rule is represented by one or more ACEs associated with target domains, which taken together have the effect which the access rule specifies.

The implementation holds separate source and mechanism versions of access rules. 6.4.2

Access Rules

Access Rule Format (User and Source View) The user and source views of the format of Access Rules are identical except for the way objects are referred to in domain expressions. Access Rule Format (Mechanism View) An Access Rule can affect many domains and other objects. It would be quite a bottleneck if all access attempts had to refer back to the access rule object itself; we would lose a large degree of decentralisation. We require a method of distributing the information around the domain hierarchy. This can be achieved by partially “compiling” the access rule into one or more Access Control Entries which can be held in all the domains referenced by the target domain expression. An ACE contains information about subjects and the permitted operations that they can perform on the domain object where the ACE resides or its members. After an access rule has been created or altered an ACE is handed to all the domains referred to by the target domain expression. They are then propagated as necessary, by the domains, through the domain hierarchy so that for any access rule there is an ACE at every domain specified by the access rule’s target domain expression; this includes all the indirect members of the target domains if that was what was specified in the domain expression. When checking for access permission all the relevant access rules are

127

Chapter 6

DOME Services

represented by ACEs at the parent domains of the object to be accessed, or at the object itself if it is a domain. The ACE contains: •

Source Access Rule OID

•

Source Access Rule Version Number

•

Source Access Rule Subject Domain Expression

•

Source Access Rule Operation Set

•

Plus Generating Domains

•

Minus Generating Domains

•

Propagation Attribute

The Source Access Rule OID is the OID of the access rule from which the ACE is derived. This may be used, by user interfaces, to show the user the source of the access rules applying to any particular target domain. It is also used, in conjunction with the version number, when updating ACEs from a changed access rule, and for reapplying access rules if the domain hierarchy structure is altered. The Source Access Rule Version Number contains the version number of the access rule from which the ACE is derived. In conjunction with the source OID it allows the domain server to control the updates in a possibly cyclic domain structure by tagging domain’s ACEs that have been updated and to identify the entries which are to be removed whenever an access rule is deleted or updated. The Source Access Rule Subject Domain Expression is a copy of the source access rule’s subject domain expression. The Source Access Rule Operation Set is a copy of the operation set from the access rule.

128

Chapter 6

DOME Services

TDomF

TDomE TDomG

TDomG

ObjB

Source

SDom3

Target

TDomE* - TDomF*

Permissions TDomG

ObjH

Read, Write

Access Rule R678

Figure 6.2 - Example to Illustrate Generating Domains

The Plus Generating Domains and Minus Generating Domains attributes are required to deal with Set Difference in the Target Domain Expression of an Access Rule. The Access Rule may grant access to all target objects which are direct or indirect members of TdomE* but not direct or indirect members of TDomF (TdomE* - TDomF*), see figure 6.2. Consider an operation request to access ObjH which is a member of TDomG . TDomG is a member of both TdomE and TDomF , so the Access Rule does not grant access to ObjH . However, if TDomG were removed from T D o m F , access should now be granted. We need to represent the fact that access is granted by inheritance from TdomE unless this is overridden by the negative inheritance from T d o m F . This is done by attaching two sets of ‘generating domains’ to each ACE. The Plus Generating Domains is a list of domains from which provisional positive access has been obtained, while the Minus Generating Domains is a list of domains from which overriding negation of the positive access has been obtained. The ACE will only have effect in giving access if there is no entry in the Minus Generating Domains list. Positive access or its negation is obtained from one of two sources: either directly because the domain is explicitly referred to in a Target Domain Expression; or indirectly by inheritance from a parent domain. Entries are put onto the Generating Domains lists as described in ‘ACE Generation’, below. In the above example the ACE for access rule R678 held by TDomG will contain a reference to TDomE in its Plus Generating Domains list and TDomF in its Minus Generating Domains list. Any access request will not be granted by R678 because it has a non-empty Minus Generating Domains list, its Plus Generating Domains list will be ignored. If TDomG is subsequently removed from TDomF then the TDomF entry will be removed from the Minus Generating 129

Chapter 6

DOME Services

Domains list which in this example will become empty. Access would now be granted via this ACE as its Plus Generating Domains list can now be used. The Propagation Attribute specifies how the ACE is to be propagated down the domain hierarchy from the original target domain. The Source Access Rule may have a target domain expression which refers to the domain itself, the direct members of the domain or all members both direct and indirect. The corresponding propagation attribute is: Self , Direct or All . These are further explained below. An ACE at a domain may apply to operations on managed objects which are direct members of the domain and also to the domain itself. The reason for deciding that it should apply to the domain itself is so that additional domains do not have to be created solely in order to get adequate control over operations on domains. ACE Generation An access rule is compiled into one or more ACEs which will be held in the domain(s) specified by the access rule’s target domain expression. The following tables and explanatory text describe the different access rule domain expression types and the ACEs that are generated. Plus & Minus Generating Domains Lists A new ACE is created in a domain following: a)

The creation or alteration of an access rule; or

b)

By propagation downwards from the ACE of a parent domain.

The new ACE is initialised using the corresponding fields from its originating source access rule, and the Generating Domains Lists are initialised empty. In case a), above, the domains directly referenced by the access rule’s target domain expression will receive the ACEs as a result of the access rule being compiled. The generating domain (which may be positive or negative) is, in this case, the directly referenced domain itself. For example in figure 6.2 for TDomE , the positive generating domain for the ACE is TDomE , the negative generating domain is empty, and for TDomF the positive generating domain is empty and the negative generating domain for the ACE is TDomF.

130

Chapter 6

DOME Services

In case b), above, the generating domain is the parent that passes down the ACE. It is positive if it derives from the positive part of a domain expression (the normal situation), and then its generating domain’s OID is added to the (empty) ACE’s Plus Generating Domains List. It is negative if it derives from the negative part of a Set Difference Domain Expression, and its generating domain is added to the (empty) ACE’s Minus Generating Domains List. For example in figure 6.2 for TDomG the positive generating domain for the ACE is TDomE, and the negative generating domain is TDomF. ACE propagation from a parent may “arrive at” a domain in which an ACE for the same source access rule already exists. In this case the parent’s OID is added to the appropriate Generating Domains List of the existing ACE. Downwards propagation of the ACE is carried out as necessary - see below. When an Access Rule is destroyed, a “remove ACE” event is sent to the domain(s) referred to in its target domain expression. The ACE is removed from the domain and the event propagated as described below. Removal of a domain from one of its parents causes that parent’s OID to be removed from all the Generating Domains Lists of the domain’s ACEs. If both the Plus and Minus Generating Domains Lists of any one ACE are empty then the ACE is deleted. The event is propagated downwards as necessary. Propagation Table 6.12 shows, for the target domain expression in the Access Rule, what Propagation type is generated in the domain which was specified. The Propagation type affects both what access is allowed and how the ACE is propagated downwards, as also shown in the table. Domain Expression Type

Propagation Type

Propagation Effect

Access Affect

domain@

Self

None.

Domain object only

domain

Direct

Self is propagated to its

domain*

All

All is propagated to its

Domain object and its direct non-domain members Domain object and its direct non-domain members

direct domain members direct domain members.

Table 6.12 - Access Rule Propagation Categories

131

Chapter 6

DOME Services

If the propagation type is Self there is no downwards propagation. If the Propagation type is Direct then Self is propagated to the domain's direct members. This has the effect of halting the propagation so that it does not go beyond the direct members. If the Propagation type is All then All is propagated to the domain's direct members and propagation will continue all the way down the hierarchy. The access affect differs depending on the propagation type in the ACE, as shown in the table. If the propagation type is Self, operations granted by the ACE are granted only for the domain itself. If the propagation type is Direct the operations are granted to the domain itself and the domain’s direct nondomain members. Since the access is Direct it can be seen from the table that the ACE propagation type is changed to Self and propagated to every domain member object where the ACE will affect only those domain member objects; these two steps give the effect of granting access to the original domain and to all of its members. If the propagation type is All, propagation continues in a similar manner all the way down the hierarchy. In addition, the access affect differs depending on whether the propagation derives from a ‘normal’ positive component of a domain expression, or from the negative component of a set difference domain expression: •

If it is positive, the generating domain is added to the Plus Generating Domains List for this ACE. This has the effect that access is authorised for the Subject Domain and Operations of this ACE unless there is a member of the Minus Generating Domains List for this ACE.

•

If it is negative, the generating domain is added to the Minus Generating Domains List for this ACE. This has the effect that of negating any access authorised through the Plus Generating Domains List for this ACE.

Note that Direct is described as affecting only its non-domain members. This is because when operation requests on domain objects are evaluated, the evaluation starts as the target domain object itself, which will have inherited the Self Propagation value.

132

Chapter 6

DOME Services

Cyclic Hierarchies When the ACEs are propagated down the domain hierarchy they will stop when reaching any ACE already generated from the same version of the source access rule if the current domain finds that it is already on the appropriate Generating Domains List. In this way a cyclic domain structure is handled correctly. Example For the example in figure 6.3, the domain’s ACLs will contain the following ACEs (we assume that TDomD is currently empty), as shown in table 6.13. Domain TDomB " " TDomC " " TDomD " "

Access Rule Id R123 R345 R123 R345 R123 R345

Subject Domain SDom1 SDom2 SDom1 SDom2 SDom1 SDom2

Operation Set Read Read, Write Read Read, Write Read Read, Write

Propag Type All All All All All All

Plus Gen List TDomB TDomB TDomB TDomB TDomB TDomB

Minus Gen List

TDomC

Table 6.13 - Access Control Entries for Example

Rule R123 allows members of SDom1 to Read ObjB and all members (both direct and indirect) below it in the hierarchy. Rule R345 allows members of SDom1 to Read ObjB and all members (both direct and indirect) below it in the hierarchy excluding members of TDomC. The positive access inherited from TDomB is overridden by its negation by TDomC.

133

Chapter 6

DOME Services

We will now show a change to the domain structure: Source

SDom1

Target

TDomB*

Permissions

TDomB

Read

Access Rule R123 Source

SDom2

Target

TDomB* - TDomC*

Permissions

Read, Write

ObjB

TDomC

TDomD

ObjC

Before Access Rule R345 TDomB ObjB

TDomC

TDomE TDomF

TDomD

ObjC

After Figure 6.3 - Include and Remove on Domains

Figure 6.3 shows the situation before and after the removal of TDomD and inclusion of TDomE (which has TDomF as a member) in TDomB. TDomF is also included in TDomC. After the alterations, although the access rules have not changed, the ACEs must be altered. There will be access for members of SDom1 to (direct and indirect members of) TDomE and TDomF. Members of SDom2 will have access to TDomE, but not to TDomF, because of its membership of TDomC. There will be no access at all to TDomD.

134

Chapter 6

DOME Services

The results are shown in table 6.14. TDomB and TDomC are omitted as they are unchanged. Domain TDomD TDomE " " TDomF " "

Access Rule Id

Subject Domain

Operation Set

Propag Type

Plus Gen List

Minus Gen List

R123 R345 R123 R345

SDom1 SDom2 SDom1 SDom2

Read Read, Write Read Read, Write

All All All All

TDomB TDomB TDomE TDomE

TDomC

Table 6.14 - Access Control Entries after Change

6.4.3

ACEs and Domain Structure Changes

Holding ACEs in the manner described above, with Plus and Minus Generating Domains, considerably reduces the overhead of changing the domain structure whilst keeping the access rule information consistent.

a ! TDomB

b

!

TDomB

!

!

!

TDomC

TDomD

TDomC

TDomD

c ! TDomB !

!

TDomC

TDomE

!

TDomF

!

Figure 6.4 - Rule R345 and its ACEs

Figure 6.4 shows access rule R345 from figure 6.3 with successive changes in the domain structure. The figure shows where the rule grants (+) or does not grant (-) access. Each “+” or “-” is an ACE generated from R345 with its Plus or Minus generating domain. Where the “+” or “-” cuts the domain, the generating domain is itself, where the symbol is next to the domain its generating domain is the parent above it. In figure 6.4b the removal of TDomD from TDomB removes any ACEs from TDomD with TDomB as its generating domain. In this case the only ACE from R345 is removed meaning that R345 no longer influences the access permissions on TDomD. 135

Chapter 6

DOME Services

In figure 6.4c TDomE has been added to TDomB, it inherits the “+” from TDomB. TDomF, when added to TDomC and TDomE will inherit two “+” ACEs and one “-” meaning that R345 does not grant access to TDomF. Note that if TDomF had a sub-domain that sub-domain would only hold a single “+” and “-” ACE because TDomF would not hand the second “+” ACE down. although two “+” ACEs would be handed to it they would both have the same generating domain (TDomF). If TDomF was removed from TDomC, the ACEs with TDomC as the generating domain would be deleted leaving access granted to TDomF by virtue of its remaining “+” ACE. Note that this action only affects the local domains and does not require the access rule to be regenerated. 6.4.4

Access Rule Operations - User Interface

Operations on the Access Rule Server The Access Rule Server is responsible for checking that a new or modified Access Rule conforms to the restrictions of a valid Management Role Object. Operation Access_Rule_ Create


Parameters Conditions (C) Subject Domain (A) Subject & Target Domains are within originator's Subject & Target Scopes in (C) Target Domain MRO (see fixed policy above) (C) Operation Set (R) The new object has the attributes (C) MRO defined by the parameters

Table 6.15 - Access Rule Server Operations

136

Chapter 6

DOME Services

Operations on Access Rule Objects The Access Rule objects can be listed, altered and destroyed. The alter and destroy operations must be within the restrictions of a valid Management Role Object. Operation Access_Rule_ Destroy

Inherits from (Destroy)

Access_Rule_ Alter

(Any_Operation)

List_ Access_Rule

(Any_Operation)

Parameters (C) MRO

Conditions (A) Subject & Target Domains are within originator's Subject & Target Scopes in MRO (see fixed policy above) (C) New Subject (A) Both old and new Subject Domains Domain(optional) and Target Domains are within originator's Target Scope in MRO (see (C) New Target fixed policy above) Domain(optional) (C) New Operation (R) The object has the new Subject Domain, Target Domain and/or Set (optional) Operation Set attribute (whichever are (C) MRO specified) (R) Contents of attributes

Table 6.16 - Access Rule Operations

6.5 USM Operations The User State Manager (USM) is introduced in section 4.5. The USM functions are also described in section 4.5 but are shown more formally here with the actual arguments expected and the results returned. These virtual operations are defined here to capture the general elements which most USM operations have in common: Operation (Current_Domain) (Initialised)

Inherits from

Parameters

(Current_Domain)

Conditions (F) The Current Domain is set (F) The User Personal Domain is set

Table 6.17 - Virtual Operations for the User State Manager

137

Chapter 6

DOME Services

The following operations are described in section 4.5.2 and act on the USM internal state: Operation USM_Set_ Representation_ Domain

Inherits from

Parameters (C) DPE8

USM_Set_ Personal_ Domain

(C) DPE

USM_Set_ Current_ Domain

(C) DPE

Conditions (F) DPE refers to an existing Domain (P) The User Representation Domain is set to DPE and the manager includes itself in that domain. (F) DPE refers to an existing Domain (P) The User Personal Domain is set to DPE (F) DPE refers to an existing Domain or is null (P) The user’s Current Domain is set to DPE or UPD

Table 6.18 - User State Manager State Change Operations

The following operations are described in section 4.5.3 and are passed onto the Domain Service: Operation USM_Make_ Domain

Inherits from (Initialised)

Parameters (C) DPE

USM_Destroy_ Domain USM_Include_ Object

(Initialised)

(C) DPE

(Initialised)

(C) (C)

USM_include_ Context_Link

(Initialised)

(C) (C)

USM_remove_ Object

(Initialised)

(C)

USM_Destroy_ Object

(Initialised)

(C)

USM_List

(C) (C) (R)

Conditions (O)9 Create a new Domain

(F) Valid Domain Service request (O) Destroy an existing Domain (F) Valid Domain Service request DPE1 (O) If DPE2 is a Domain DPE2 Include object DPE1 in DPE2 else Include object DPE1 as DPE2 (F) Valid Domain Service request DPE1 (O) If DPE2 is a Domain DPE2 Include link to DPE1 in DPE2 else Include link to DPE1 as DPE2 (F) Valid Domain Service request DPE (O) Remove object DPE from parent domain (F) Valid Domain Service request DPE (O) Remove object DPE from the Domain System (F) Valid Domain Service request DPE (O) If null argument, list objects in Current Domain else list objects in List Type DPE List of strings (F) Valid Domain Service request

Table 6.19 - User State Manager Domain Service Operations

8

Domain Path Expression

9

(O) indicates a brief description of the operation

138

Chapter 6

DOME Services

Access Control Operations: Operation USM_Add_ Access_Rule

Inherits from

Parameters (C) DPE (C) Access Rule

USM_Remove_ Access_Rule

(C) DPE (C) Access Rule

USM_List_ Access_Rules

(C) DPE (R) List of strings

Conditions (O) Add the Access Rule to the Domain DPE (if null then the Current Domain) (F) Valid Domain Service Request (O) Remove the Access Rule from the Domain DPE (if null then the Current Domain) (F) Valid Domain Service Request (O) Return the Access Rules applying to the DPE (if null then the Current Domain)

Table 6.20 - User State Manager Domain Service Operations

6.6 Chapter Summary This chapter has introduced the services that support the DOME architecture: the domain service, the access rule server and the user state manager used by the user’s interface. The domain service acts as a domain factory, it creates, maintains and destroys the domain managed objects themselves. The operations available at the domain service, both factory operations and domain operations have been fully described; these operations are offered to managers which may be a human user’s interface or other manager objects. The domain’s attributes comprising: policy set, context set and access control list have also been outlined. The access control mechanisms have been described using access control entries which are created from access rules. Access control entries have been shown to provide an efficient method of maintaining the information contained in an access rule in a distributed manner, by propagating the ACEs to the domains referenced in that access rule. This is especially efficient when the domain structure is altered, the access control entries are updated in domains affected by the structure change with no recourse necessary to the original source access rule(s). Examples have shown the exact steps when creating and updating ACEs.

139

Chapter 6

DOME Services

A basic user interface manager has been described. It allows a user to navigate around the domain hierarchy and to perform domain and access rule related operations. Other applications will require specialised interfaces, which may be incorporated into the basic user interface or may be used alongside it.

140

Chapter 7


So far we have just described the DOME architecture giving the service interfaces as seen by the user, we have not specified how the operations are actually implemented. In fact, as this is a distributed system, the operations are messages sent to Domain Service objects. The basic Domain Service components are node managers, domain servers and access rule servers. A node manager is the local interface to the domain service for most operations eg. the domain path name to OID lookup operation. The domain servers act as a factory and distributed database creating and storing the domains themselves. Access rule servers perform a similar function for access rules. This chapter refines some previous definitions and splits up the interface showing the components (also DOME managed objects) that provide the support for the different operations. It also describes the access control mechanisms and exactly how objects are created and included in the domain structure.

7.1 Objects 7.1.1

Object References

An object reference contains an object address and a unique identifier. Objects may be located by their address. The unique identifier is used to check that the correct object is referenced; objects may migrate leaving their addresses free to be used by another object. Object Addresses Objects will also have a temporal address consisting of two fields - the current network address and a generation number. The latter is an integer that is

141

Chapter 7


incremented every time an object changes its network address enabling two addresses for the same object to be compared to find the most recent one. The network address is simply something that allows the system to locate an object, it consists of a type and a value. It may be an Internet address, an X25 address, an X500 address or even a name requiring a name server lookup to actually locate it - figure 7.1. Address Type

Address Value

Generation Number

X25

2343876621201

2

IP

146.169.14.8:5068

1

DNS

andspencer.doc.ic.ac.uk

1

X500

ORG=IC COUNTRY=UK ...

3

Figure 7.1 - Object Address Contents and Examples

OIDs We define an Object Identification Descriptor (OID) as a structure consisting of: •

A Unique Identifier

•

An Object Address, which may change if the object migrates. This may also be a distinguished name that can be resolved using a name server.

The most up-to-date of two different OIDs with the same Unique Identifier can be resolved by using the OID with the latest (highest) generation number in the address field. 7.1.2

Parent Set

Every managed object has a parent set associated with it, which is a set of OIDs of the parent domains of which it is a member. The names of the parents are not included in the parent set as naming can only be done downwards through domain membership. Although the parent set could be seen as an attribute of the object, to keep objects as simple as possible and to reduce

142

Chapter 7


domain overheads on application objects the parent sets are not actually kept by the objects themselves. The parent sets are maintained by the Node Manager (see below); this also has the added advantage of not having to trust application objects to maintain their parent sets correctly.

7.2 Domain Service Although the user sees the Domain Service operations as one group of operations they are, in fact, separated into several different groups that are applied to the different components comprising the Domain Service (figure 7.2). This section describes the interfaces of the individual component types that together form the Domain Service. These comprise a Domain, a Domain Server that holds the Domain objects in its database and a Node Manager which provides services for the objects running on its node. Domain Service Interface

User View of Domain Service Operations

Domain Server Interface

Domain Server

Domain Interface

Domains

Node Manager Interface

Node Manager

Figure 7.2 - System View of the Domain Service

The Node Manager provides support for both local objects (objects on the same host computer as the Node Manager) and remote objects, such as a Domain Manager, requesting information about local objects e.g. parent lists, migrated object’s new addresses etc. The Node Manager is a persistent object at a well known address on each object’s host and is thus accessible by using an object’s OID. The Node Manager also provides some more complex services, like path name to OID mapping, which involve operations upon many different domains; the advantage of this approach is that information can be cached and made use of in later requests by other objects.

143

Chapter 7

7.2.1


Domain Servers

Although Domains are seen across the Domain Service Interface as objects in their own right it would be too expensive in terms of CPU time and other resources to implement them as separate objects. The Conic/Rex implementation platform only supports active large-grain objects (essentially lightweight processes). Domains are implemented as data objects within a Domain Server. The Domain Server can also act as a Domain Factory to create Domains. A domain server usually holds the domain objects corresponding to a subtree in the domain hierarchy. If it does not hold the information relating to a particular part of the subtree, it will have the address of the server responsible. S1 D1

D2

D5 D6 D7 S4

D3

D8

D4 D9 D10

D11

S2

D12

S3

Figure 7.3 - A Distributed Partitioned Domain Service

Figure 7.3 shows a distributed service in which domains D1, D2 and D3 are on server S1; D4, D11 and D12 on S2; D8, D9, D10 on S3 and D5, D6, D7 on S4. The configuration of Domain Servers can be tailored to suit the actual domain load (number of objects, activity etc.) on different parts of the domain tree and even take physical location into account. Domain Servers can be dynamically added to or removed from the Domain Service and take over or relinquish control of a sub-domain hierarchy. This is a matter of personal judgement and is a task for the local system administrator to perform by telling one domain server to pass a domain managed object to another domain server.

144

Chapter 7


The top level Domain Server at any organisation will hold some domains corresponding to other organisations. These domains can only be altered by the local administrator who will typically add entries in the form of contexts to servers at other organisations. Domains are objects in their own right, they therefore have an OID which, of course includes an Object Address. Since domain information, and hence the domain representation, is maintained by a Domain Server the domain’s Object Address will actually be that of the Domain Server that maintains its information. Many domains will therefore have the same Object Address but of course a different Unique Identifier. The Domain Server will maintain three interfaces: an Object interface (as do all objects), a Domain interface and a Domain Server interface. All messages contain the OID of the object being addressed so that the message can be routed to the correct domain within the Domain Server. In this way a domain’s OID can be used in the same way as any other OID because the Domain Server presents a domain interface and appears to be the domain being addressed. This means that the user does not have to distinguish between encapsulated and encapsulating objects. Domain Server Operations The Domain Server presents, in addition to the general object interface, two interfaces: the Domain interface on behalf of the objects held within its database and its own interface for operations like “Domain Create”. We now refine table 6.11 and show these interfaces in tables 7.1 and 7.2.

145

Chapter 7


Operation Domain_ Include


Parameters (C) OID and local name of the member to be included

Domain_ Remove

(Any_Operation)

Domain_ Add_Link

(Any_Operation)

(C) OID and local name of the member to be removed (C) OID and local name for linked object

Domain_ Remove_Link

(Any_Operation)

Domain_List

(Any_Operation)

Object_ Lookup_OID

(Any_Operation)

(C) OID and local name of object to be unlinked (R) Policy Set as (Local Name, OID) pairs (C) OID & pathname relative to that OID (R) OID of first component of input pathname and unresolved part of input pathname

Conditions (A) There is an Access Rule (AR) with originator in its User Domain, member object in its Target Domain, and Domain_Include_Source in its Operation Set. (F) Member object exists. (F) Local name is not in Policy Set. (P) (OID, Local name) entry is in the Policy Set (F) Member object OID and local name are in the Policy Set. (P) (OID, Local Name) entry is removed from Policy Set. (F) Name has not been used in Policy Set or Context Set (P) Link (OID , Name) is added to the Context Set (F) OID is in Context Set (P) Link is removed from the Context Set

(F) Target object is a domain and first component of pathname is a member of the domain's policy set.

Table 7.1 - Domain Object Operations

146

Chapter 7


Operation Domain_Create


Object_ Lookup_OID

(Any_Operation)

Domain_Server_ (Any_Operation) Export_ Domain Domain_Server_ Import_ Domain

(Any_Operation)

Parameters (C) Type Set (permitted types of objects in the domain) (C) OID & Pathname (to be interpreted relative to that OID) (R) OID of input pathname and null pathname or OID and unresolvable part of input pathname (C) Domain OID & Domain Server OID (C) Domain persistent information

Conditions (P) The Policy Set attribute is empty (P) The Type Set attribute is set to the parameter value (F) Target object OID refers to a domain or is null (F) Input OID is a member of the domain's Policy Set. or null.

(P) The Domain is held only in new Domain Server (P) The local Node Manager is informed of migration (P) The Domain is held in Domain Server

Table 7.2 - Domain Server Operations

Current Restrictions on Domain Expressions In the current implementation, only a part of the syntax for domain expressions, defined in section 2.2.2, is implemented. Set union and set intersection are not implemented, and set difference cannot refer recursively to another set difference expression. 7.2.2

Node Managers

There is a Node Manager on every host computer that supports managed objects. The Node Manager acts as a local agent for interaction with the Domain Servers and provides a Domain Path Name to OID mapping service, caching any information that it gleans. An advantage of having a permanent server running on a host is that the cached information is made available to local objects which may be dynamic and short lived. Parent Sets As an implementation optimisation a parent set is maintained for every object in the domain system. The members of the parent set are the OIDs of the parents of the object (the domains of which the object is a member of the policy set of the domain). The parent set is required when applying access 147

Chapter 7


controls because the access control information for the object is held with its parent domain(s). It would be a simple matter to maintain the parent set of an object as an attribute of that object; however there are two main problems with this approach. First and foremost, the object may not be a trusted object (i.e. most users’ objects), there would be nothing to stop an object from saying that it was in domains other than its true parent domain(s). The parent information could be checked, but this would require each parent to be verified by asking the given parent domain(s) if the information is true, every time the parent set was requested; this is an unacceptable overhead. Secondly, we have already mentioned that objects are dynamic and may be short lived in which case they will not want the extra work of maintaining the parent set and will not want to slow down their destruction by ensuring that they have been removed from all their parent domains; indeed, if an object “crashes” or fails in some way there is no guarantee that it will be able to inform each of its parent domains that it is to be removed. The Node Manager overcomes these problems by maintaining the parent sets for all the objects on its host computer by keeping track of the domain membership of all the objects on its host. This enables domain membership to be verified reliably without having to check with each domain. The Node Manager also handles initial inclusion and tidy up removal of local objects into and from the domain structure. These requests are generated by the objects that are started in its host computer; the object only has to make one request, and it is then up to the Node Manager to communicate with the Domain Service to include the object. When a local object is destroyed the Node Manager will remove the object from its parent domain(s) using the parent set that the node manager maintains. The Node Manager itself can be trusted because it will always use a well known privileged port which can only be started by the local Unix superuser. Thus, when an object makes a request to do something, gaining its privileges by being in a certain domain, the object’s local Node Manager can be called upon to verify the claim and the domain can also be checked to check access permissions. The reference monitor (used for security) can therefore rely on the information that it requests regarding domain membership and can then

148

Chapter 7


apply the appropriate access rules for the requested operation. This assumes that the Unix machine itself is trusted, if not, the node manager may have to run in a trusted node elsewhere. Node Manager Operations The Node Manager will inherit all the general object operations and will have the following additional ones: Operation Object_ Lookup_OID


Object_Lookup_ Pathname

(Any_Operation)

Object_ Deregistration

(Any_Operation)

Object_ Add_Parent Object_ Remove_ Parent Object_ Migration

Object_Lookup

(Any_Operation)

Parameters Conditions (C) OID & Pathname (F) Target object OID refers to a (to be interpreted domain or is null if the pathname relative to that OID) begins from the root. (R) OID of input (F) Input OID is ignored if the pathname and null pathname begins from the root. pathname or OID and unresolvable part of input pathname (C) OID whose pathname is to be looked up (R) Pathname of input OID relative to the target OID (F) OID is in Local Object Set (P) OID is removed from all its parent domains (P) OID is not in the Local Object Set (C) OID (F) OID is in Local Object Set (C) New Parent OID (P) Parent OID is in the parent set (C) OID (F) OID is in Local Object Set (C) Parent OID (F) Parent OID is in the parent set (P) Parent OID is not the parent set (F) OID is in Local Object Set or Migration Set (P) old OID is not in Local Object Set (P) new OID is in Migration Set (C) OID (F) OID is in Local Object Set or Migration Set (R) Latest OID (P) Latest OID is in Local Object Set or Migration Set

Table 7.3 - Node Manager Operations

7.3 Implementation of Access Control Operations There are two servers, in addition to the basic domain service, required for access control: an Access Rule Server (AR server) which maintains access rule

149

Chapter 7


objects and a Management Role Server (MR server) which maintains management role objects. One or more AR servers maintain a database containing the access rule objects in a similar manner to the way the domain server maintains domain information. Normal access control will be applied to subjects requesting access to access rules (Object Access Control) and the AR server will use the supplied MRO to determine the validity of the created rule (Application Access Control). The AR server will only accept MROs if they are members of domains that the server already knows may hold MROs10 , this prevents subjects just creating an MRO and giving themselves privileges to create arbitrary access rules. Although subjects actually address the access rule object it will, however, be the AR server itself, using the access rule privileges of its parent domain, that will send the new ACEs to the domains for updating. One or more MR servers maintain a database of MROs. Normal access control will be applied to subjects requesting access to MROs (Object Access Control) and the MR server will use the supplied MRO to determine the validity of the new information (Application Access Control). As with the access rule server, above, the management role server will only accept the supplied MRO if it is a member of a known/trusted domain. Access rules are compiled by the AR server to generate one or more Access Control Entries (ACE), the ACEs are given to the relevant domains which update their own Access Control List (ACL) and, if necessary, pass the ACEs to their child domains. The passing of ACEs from one domain to another will be done by domain server to domain server interaction so access rules must exist allowing this. Because of the twofold representation of access rules, operations on them have two phases: •

Creation, alteration or destruction of the source access rule

1 0 The access rule server is given this information by a manager that is allowed to perform the

relevant update operation

150

Chapter 7

•

7.3.1


Compiling the source rule into one or more ACEs and sending the new ACEs to the relevant domains which will perform the removal of the ACEs representing the old version of the access rule (for alteration and destruction) and creation of the ACEs representing the new version of the access rule (for creation and alteration). Alteration will be regarded as destruction followed by creation, to simplify the task. Access Rule Operations (Mechanism View)

Updating Access Rules When an authorised subject creates an access rule its version number is set to one and is incremented whenever the access rule is updated. ACEs are generated as described in section 6.4.2. Including and Removing Domain Objects ACEs may need to be added or removed as a result of altered domain membership. We note that this task could be very heavy, but certain properties of the ACEs and the domain hierarchy will reduce this overhead. The effect on ACEs is also described in section 6.4.2. 7.3.2

Management Role Operations (Mechanism View)

Management roles are implemented as managed objects and there is no need to distinguish between source and mechanism versions. MROs are referred to by the access rule server when creating or updating access rules and by management role servers when creating or updating management role objects. 7.3.3

Domain Server Interface to support Access Control

Operation Access_ Control_ Entry_Update Access_ Control_ Entry_Delete

Inherits from (Any_Operation) (Any_Operation)

Parameters (C) Access Control Entry (C) Access Control Entry

Conditions (R) The ACL is updated (R) The ACE is removed from the ACL

Table 7.4 - Domain Server ACE operations

151

Chapter 7


The ACE update operation causes all old ACEs created by a previous access rule version to be removed from the ACL. The ACE is added to the ACL and, if necessary, the ACE is passed to the child domains using the same operation. The delete operation is used when an access rule is removed or the domain has been moved from one domain to another and the relevant access rule no longer applies.

7.4 Consistency Issues 7.4.1

Consistency between Source and Mechanism Versions

Although the likelihood of inconsistency between source and mechanism versions of an access rule is minimised by insisting that the ACEs must be completely regenerated when altering an access rule, it is possible that, because of some error, or partitioning of the network, inconsistency arises. Two kinds of consistency check are required: •

Generation of the ACEs expected from each access rule, to ensure that they are all present and correct;

•

Checking that for every ACE in each ACL there is an access rule which correctly generates the ACE.

7.5 Implementation of the Reference monitor All operation messages which are subject to reference monitor checking will carry the following information:

7.5.1

•

OID of the originator;

•

Expanded parent set of the originator, distinguishing between direct and indirect membership. Search for an Authorising ACE

The reference monitor will carry out an authorisation check by performing the search described below on every domain of which the target object is a direct member. However, if the target object is itself a domain, it will first perform the search on that domain.

152

Chapter 7


The reference monitor will search the ACL of the domain for an ACE which satisfies these criteria: •

The originator matches the Subject Domain Expression field of the ACE (see below).

•

The operation is a member of the Operation Set in the ACE; and

•

The Minus Generating Domains List of the ACE is empty.

The authorisation check terminates successfully and allows the operation if any search is successful. The authorisation check terminates unsuccessfully if all the searches fail. The operation is then refused. 7.5.2

Matching the Originator

The originator matches the Subject Domain Expression (SDE) if: •

Any of the originator’s parent domains matches the domain in the positive part of the SDE and

•

None of the originator’s parent domains matches the domain in the negative part (if it exists) of the SDE.

Matching is done according to the following table (table 7.5). ‘Yes’ means that there is a potential match. If the SDE specifies @ (Self only), then the OID in the SDE may be matched only by the Originator itself. If the SDE specifies Direct, then the OID in the SDE may be matched by any of the Originator’s Parents or Self. If the SDE specifies * (All), then the OID in the SDE is matched if it is any of the Originator’s Ancestors, Parents or Self. Subject Domain Expression (+ve or -ve) Domain@ (Self only)

Domain (Direct)

Domain* (All)

Ancestors Originator

Yes

Parents Self

Yes

Yes

Yes

Yes

Yes

Table 7.5 - Scope of Subject Domain Expressions

153

Chapter 7

7.5.3


ADF & AEF

The Reference Monitor is divided into an Access Decision Facility (ADF) and Access Enforcement Facility (AEF), as in the ISO Access Control Framework [ISO 1991]. The ADF is an object which receives requests from objects which wish to perform operations, and issues capabilities to permit this. The AEF is implemented by the objects themselves which only permit selected operations if they are presented with the appropriate capability; since there are communications costs in this approach, the only operations controlled by this mechanism are Bind type operations. The different interfaces which can be bound represent the operations which can be performed. Once an object is bound no checking of the contents of the message will be performed by the Reference Monitor. There may be in addition a need to perform access control which is dependent on the contents of the message and target object eg. in the case of operations on Access Rule and Management Role objects which have to ensure compliance with a given MRO. Since these must in any case be trusted objects, we propose to entrust the enforcement of the additional fixed policies to the objects themselves.

7.6 Creating New Managed Objects Any message to create an object must specify the domain into which it is to be included, with an optional local name. Section 4.3 stated that there are two different methods by which a managed object can be created, either: a)

spontaneously. e.g. it pops into existence as a direct result of a Unix exec call

b)

a message to a factory object initiates its creation.

or

In case a) the new object sends a message to the Node Manager on its host, requesting registration with the Node Manager. The Node Manager then sends a message to the Domain Manager requesting it to include the new object into the user’s default domain and to give it its specified local name. The steps are illustrated in figure 7.4.

154

Chapter 7


User’s Manager Create

Unix

New Object

Create (run program)

Register

Node Manager

Include

Domain Service

Time

(perform include)

Lookup Object

(return OID)

Move to Required Domain

(perform include/remove)

Figure 7.4 - Steps in creating a new object using Unix

In case b) the object manager returns the new object’s OID to the user’s manager. See figure 7.5. In either case the user’s manager includes the new object in the required domain using the user’s access rights. User’s Manager Create

Factory

Domain Service

Time

(Create Object Return OID)

Move to Required Domain

(Perform Include)

Figure 7.5 - Steps in creating a new object using a factory

7.7 Chapter Summary This chapter has described the components necessary for a distributed implementation of the DOME environment. It has introduced the domain server and the node manager which together form the domain service. The domain server maintains the actual domain managed objects themselves as a database in a transparent and efficient manner. Domains may be kept at any domain server regardless of their positions in the domain hierarchy; the deciding factor being efficiency, keeping the domains as close as possible to their member objects.

155

Chapter 7


The node manager provides the local interface to the domain service. There is one node manager for each host computer. The node manager maintains the parent set for every managed object on its host. This keeps the objects simple and allows the object to be removed from its parent domains if the object unexpectedly disappears. The node manager also provides a caching service for its local objects and allow objects that have migrated to be found quickly by maintaining forwarding addresses. Access rules are propagated in the form of access control entries by passing them from one domain server to another. The domain server passes the ACE internally to the relevant domains. A reference monitor checks for the correct access rule before allowing an operation to go ahead. Managed objects can be created in one of two ways: as a result of a factory operation or “spontaneously.” If created as a result of a factory operation, the manager requesting the operation can place the object in the correct domain. If created “spontaneously” the node manager is responsible for ensuring that the object is placed in the appropriate default domain.

156

Chapter 8

Conclusions

The work described in this thesis has been motivated by the difficulties encountered when many users deal with objects within large distributed systems. Although the domain model has been recognised as a suitable approach to distributed systems management by the International Standards Organisation, it was still a model and far from complete. References have been made to the work of Robinson, Sloman and Moffett who have provided the basic model of domains and access rules. We have made the domain model more applicable to the real world. Federation of independent domain systems has been made possible by the use of non-policy references. Non-policy references also do away with any requirement for a separate naming structure for managed objects, flexible naming can now be achieved solely within the confines of the domain hierarchy. We have identified all the necessary elements to support such a domain structure in a large distributed environment. Using the Conic distributed system we have shown how a distributed application can be managed using domains. The Mobile Telephone example has shown how easily an existing application can be managed using domain hierarchies, with very little impact on the application itself. We have shown how access rules can be used in a distributed environment by compiling them into access control entries and distributing them amongst the domain themselves. This distribution minimises the work to be done, maintaining the access control structure when the domain structure changes.

8.1 Revisiting the Requirements The DOME architecture has attempted to address all the requirements for network management identified in chapter one. Principal among these was the need to cope with namespace management required by having a large 157

Chapter 8

Conclusions

number of objects and at the same time provide an hierarchical management architecture giving flexible authority to managers to manage their objects. 8.1.1

Management Hierarchy

Management hierarchies may be created by giving appropriate access permissions from one manager domain to another. In this fashion layers of management can be built. A manager can give a lower-level manager instructions leaving the lower-level manager to perform the actions; this manager can then pass on newer actions to yet another lower-level manager. In this manner a management hierarchy is built up. Note that this management hierarchy is completely independent of the domain hierarchy. 8.1.2

Namespace Management

The hierarchical nature of domains allows the user to split and distribute named objects into orderly groups in the same manner as files in a file system. However, unlike a file system, including named objects in domains has policy implications allowing access to those objects. Context links have been introduced to allow the name space to be arbitrarily manipulated giving the grouping required without affecting policy and access to the objects in the name space. 8.1.3

Scalability and Single Model

The hierarchical aspects of DOME are inherently scalable, as can be seen in the Internet Domain Name Service [RFC1035], which encompasses well over a million hosts, uses generally only five or six hierarchical levels to name them. In the terms of the implementation of DOME, each host has a local node manager which looks after the objects on its host. So every new host added to the pool of object supporting environments comes complete with its own infrastructure support. The other possible overhead is the creation of domains which could cause bottlenecks at the domain servers. More domain servers can be added as necessary and domains moved to the new domain servers allowing them to share the load. Domain objects can be maintained in domain servers local to

158

Chapter 8

Conclusions

the managers and objects associated with them; this aids in keeping the network traffic local and network loading to a minimum. The single model is well supported by the architecture as there need be only as few or as many servers as are required by the number of objects to be supported by the environment. This will range from one node manager and one domain server upwards. 8.1.4

Partitioned Management

It has been shown that independent management structures can easily be created; new policies can be described completely independently of any existing policy. For example, one manager may be given access to a particular domain and another manager may be given access to a completely unrelated domain. 8.1.5

Multiple Management of Common Resources

Managers can be given different responsibilities for the same object(s) by creating appropriate access rules for the separate managers and a common domain. This will allow one manager, for example, to alter the configuration of some objects and another manager to start and stop the same objects but not to alter their configuration. 8.1.6

Decentralised Management

The DOME architecture is fully decentralised using a local node manager as the access point to the domain services. Operations use as small a part of the overall system as is necessary; i.e. a manager managing an object within the same domain will probably not involve any other domains when access rights are checked. The “compilation” of access rules into access control entries aids the decentralisation of DOME. Access does not have to be checked against the original access rule. Changes to the domain structure have a minimal impact on other domains by the use of the “generating domain” field of the ACEs; this ensures that the relevant access rights are propagated affecting only the domains below the domain that was moved.

159

Chapter 8

Conclusions

Different organisations can maintain their own DOME environment keeping their management local but can still allow other organisations access using context links. Thus each organisation can maintain it own root domain, optionally using a common naming scheme to give a uniform appearance. No one organisation has to rely on another for their DOME environment to work correctly. 8.1.7

Adaptability

The domain structure is readily adaptable and the domain service itself is also flexible. The runtime support in the form of domain servers can be added and removed as can hosts with their node managers. At the user level, domains can be created and deleted; managers and managed object may similarly be manipulated. 8.1.8

Security

The access rules allow managers to specify security in the form of access permissions. These specify the operations that may be performed by one or more managers on one or more managed objects. It is up to the underlying object support system to enforce the security but the “security database” used by the underlying system is maintained by the access control entries held in the domains. 8.1.9

Fault Tolerance

This thesis hasn't really addressed itself to the issues of fault tolerance because a lot of work has already been done in this area and it is quite well understood [Cheriton 1989]. The information that is most important to DOME is the data held by the domain objects which needs to be kept constantly on-line; domains need to be replicated and kept up to date whilst maintaining consistency. Replication has not been made part of the DOME architecture as it is hoped to make use of fault tolerance aspects of existing object support systems. Domains themselves could be replicated but it might be more efficient to replicate the domain servers, therefore dealing with fewer replicated objects.

160

Chapter 8

Conclusions

The SysMan project (see section 8.2.8 below) will be using DAIS or ANSA for its basic operating system support; DAIS is a C++ extension of ANSA 4.1. ANSA 4.1 offers replication transparency of objects using the group execution protocol (GEX). The current release supports active replica groups in which all the members are deterministically equal, all execute all requests and all reply to the client; a more flexible technique will be produced in the next release [ANSA 1993]. This facility can be used to replicate domain managed objects or domain servers providing a fault tolerant domain service.

8.2 Critical Evaluation and Future Work 8.2.1

Access Rules

DOME only deals with simple domain expressions; it does not handle intersection, union or more complex combinations containing set difference. With the current implementation the “minus generating domain” part of the ACE has to be propagated before the “plus generating domain” part. If they are both propagated together there may be cases where the plus part reaches a domain before the minus part, in which case there will be a short time when access could be incorrectly granted. Set intersection and union will require further investigation. Domain expressions could also be extended to include any managed object rather than just domains. This would require ACE information to be held with or on behalf of the object. 8.2.2

Capabilities versus Access Control Entries

Access control entries have been chosen instead of capabilities because of the ability to allow the inheritance of ACEs as the domain structure is changed. If capabilities were used, they could be held with the manager’s domains and given to the members of the domains when required. However, it is harder to take the capability away from the manager if the manager is moved from that domain. The access control described in this thesis is only performed on the “bind” operation when binding to an interface, the contents of the messages/operation parameters not being monitored by DOME. Greater 161

Chapter 8

Conclusions

security can be achieved by obtaining a capability at bind time after performing DOME’s standard access control; this capability can then be used and checked on a per message basis by the managed object. 8.2.3

Concurrent Access and Domain Locking

DOME domains do not have any locking; it is assumed that if two managers are performing concurrent updates to a domain they will be working cooperatively. Locking is not required because domains are not updated by obtaining all their information, changing it and rewriting it; they are updated by operations to add or remove entries. It is therefore not possible for a manager to change the membership of a domain only to find another manager writing the original list back a second or so later. 8.2.4

Constraints

Constraints are rules governing the permitted membership of objects in a domain. They are normally based upon the properties of objects and are evaluated when an object is included in a domain. If constraints are permitted, e.g. “only printers that have A4 paper loaded may be members of the domain,” there is a problem if the printer is a member of that domain and later has a different paper size put into it. Should the members of the domain be actively checked, eager evaluation, or should they only be checked when they are to be accessed, lazy evaluation? Should the domain service be responsible for the surveillance or should it be left to a manager to perform these checks? We believe that the domain service should be kept as simple as possible and that although the domain could do an initial check when an object is included, a manager should be responsible for the continuing observance of the constraints by the member objects. 8.2.5

Cyclic Hierarchies

The concept of a cyclic domain hierarchy structure e.g. domain C is a member of domain B which is a member of domain C, is either not mentioned or explicitly denied in all the reviewed systems. In our opinion it can be very difficult to stop a cyclic hierarchy from being created. The Unix file system makes cycles impossible by restricting directories to be a member of one and

162

Chapter 8

Conclusions

only one parent directory11, other file types may have as many entries as one wishes. We would like a flexible system allowing any object to be placed in any domain. To try to detect a possible cycle in a large distributed system will involve a lot of work tracking up (or down) remote domains until a cycle is or is not found. If a cycle is forbidden it might surprise a user who tries to include one domain in another having no knowledge of other parts of the hierarchy. It is therefore much simpler to make operations and programs aware that cycles might exist in the hierarchy and deal with them if detected. This is not difficult to do and involves very little overhead, because the operation must be traversing the hierarchy anyway or else it would not be affected by the cycle. 8.2.6

Inheritance Blocking

It may be desirable in some cases to specify that domains should not inherit access control policy from their parents. If the domain does not inherit any policy from its parent this would be equivalent to a context link to that domain. It may be more flexible however, to restrict chosen policies from propagation. 8.2.7

Trading

Domains can be used to perform a limited trading function. A server can have its interface published by being included in a particular domain and a client can therefore locate it [Twidle 1992]. ANSA traders, however, can be used to find services of a particular type. Using domains, a similar function could be performed by listing the domain members and asking for each of their attributes in turn, until a suitable service is found. Obviously this is time consuming, so some kind of trading manager is required. The manager would have to know about the attributes of all the objects in a “trading domain,” allowing the client to ask the manager for a particular type of service. Should the manager actively inspect the domain for changes in its

1 1 Superuser may override this rule but when we tried this, many commands failed to work

properly and the file system was corrupted when trying to remove the linked directory.

163

Chapter 8

Conclusions

name set or should the domain be asked to inform the manager of any changes to its state? If a domain could do this it would be very useful for monitoring. 8.2.8

Man Machine Interface

A great deal of work has to be done in the area of displaying domain information to the user. Although all the information can be gained using text based commands, they are not suitable for achieving an overall feel for the structure. In addition, it has been shown by GUIs such as the Apple Macintosh [Apple 1985] that a graphical interface with a mouse makes it much easier to perform simple actions. However, in our experience there is often too much information to display a domain structure in an hierarchical graphical format neatly. The diagrams of domain structures shown in this thesis have all been very simple layouts. Once there is even a small number of domains which are members of more than one domain a straight forward hierarchical structure display becomes hopelessly tangled, with lines crisscrossing the screen from one domain to another. Another problem arises when objects are members of more than one domain and they have different local names in those domains. How are the multiple names to be presented? One such method is to name the arcs as in figure 3.6. It may be better to have a master name built into the object itself; in DOME an object is only named by the domain(s) of which it is a member. We have difficulties with a master name because it might not be used as a local name in any of its parent domains. Which is the user to be presented with? We have looked at current designs of graphical user interface, including MS Windows file manager [Microsoft 1990] and Sun’s Open Look file manager [Sun-Microsystems 1990] which both allow partial displays of hierarchical structures. We have also supervised several projects to design a GUI suitable for domains and have made suggestions for multiple partial hierarchical displays and simple “current domain” displays. No firm conclusions have yet been reached.

164

Chapter 8

8.2.9

Conclusions

Future work

This work forms the basis of two major Esprit projects: SysMan (Systems Management) Project Number 7026 and IDSM (Integrated Distributed Systems Management) Project Number: 6311. SysMan is going to use the DAIS/ANSA workbench as its object support architecture and IDSM is going to use DME. They are both going to use the architecture described in this thesis and intend to address the issues of different types of policy and the way that policy can be expressed and carried out by managers.

165

References

[ANSA 1991] ANSA. ANSAware 3.0 Implementation Manual, APM Ltd., Poseidon House, Castle Park, Cambridge CM3 0RD, UK, [ANSA 1993] ANSA. GEX Implementation Notes. APM Ltd., Poseidon House, Castle Park, Cambridge CM3 0RD, UK. 1993 [Apple 1985] Apple. Inside Macintosh Volume I, II and III, Addison Wesley, 1985 [Bannister 1990] D.K. Bannister, Simulation of a Cellular Radio Network, MSc Thesis, Imperial College of Science, Technology and Medicine 1990 [Cheriton 1989] D.R. Cheriton and T.P. Mann. Decentralizing a Global Naming Service for Improved Performance and Fault Tolerance, ACM Transactions on Computer Systems vol. 7 (2), 1989, pp 147-183. [Cole 1985] C.T. Cole, P.B. Flinn and A.B. Atlas. An Implementation of an Extended File System for UNIX, Proceedings of the USENIX Conference vol. Summer 1985 , 1985, pp 131-149. [DEC 1991] DEC, HP, HyperDesk, NCR, Object-Design, et. al. The Common Object Request Broker: Architecture and Specification. Object Management Group. 1991

166

References

[Digital 1989] Digital. Enterprise Management Architecture - General Description, Digital Equipment Corporation, Customer Information Report EKDEMAR-GD-001, March 1989 [Digital 1991] Digital. DNA Naming Service Functional Specification. Digital Equipment Corporation. 1991 [DOMAINS 1992] DOMAINS. DOMAINS Management Architecture, Esprit Project 5165, Report May 1992 [Dulay 1987] N. Dulay, J. Kramer, J.N. Magee, M.S. Sloman and K.P. Twidle. Distributed System Construction: Experience with the Conic Toolkit. Experiences with Distributed Systems. , Springer-Verlag, 1987. , ed. J. Nehmer. pp 189-212. [Goldberg 1989] A. Goldberg and D. Robson. Smalltalk-80, Addison-Wesley, 1989 [Gribbin 1985] J. Gribbin. In search of Schrödinger’s cat, Corgi Books, 1985 [ISO 1988a] ISO. Management Information Service Definition, Part 2: Common Management Information Protocol, International Organisation for Standardisation, Draft International Standard Report ISO 9596-2, May 1988 [ISO 1988b] ISO. Management Information Service Definition, Part 2: Common Management Information Service, International Organisation for Standardisation, Draft International Standard Report ISO 9595-2, May 1988 [ISO 1991] ISO. Security Framework III: Access Control Framework, ISO/IEC JTC1/SC21, May 1991 167

References

[ISO 1992a] ISO. Management Domain Management Function, ISO/IEC, Second Working Draft Report ISO/IEC JTC1/SC21 N7119, June 1992 [ISO 1992b] ISO. Management Domains Architecture, ISO/IEC, Third Working Draft Report ISO/IEC JTC1/SC21 N7118, June 1992 [ISO/IEC 1989] ISO/IEC. Information Processing Systems - Open Systems Interconnection - Basic Reference Model - Part 4: Management Framework, International Organisation for Standardisation, Report ISO/IEC 7498-4, May 1988 [ISO/IEC 1992] ISO/IEC. Information Processing Technology - Open Systems Interconnection - Structure of Management Information: Management Information Model, ISO/IEC, Report ISO/IEC 10165-1, 1992 [Klemba 1989] K.S. Klemba. Openview’s Architecture Models. Integrated Network Management. , North Holland, 1989. , ed. B. Meandzija and I. Westcott. pp 565-572. [Klerer 1988] S.M. Klerer. The OSI Management Architecture: an Overview, IEEE Network vol. 2 (March 1988) (2), 1988, pp 20-29. [Kramer 1989] J. Kramer, J. Magee and K. Ng. Graphical Configuration Programming, IEEE Computer vol. 22 (10), 1989, pp 53-65. [Kramer 1991] J. Kramer, J. Magee, M. Sloman, N. Dulay, S. Cheung, et. al. (1991). An Introduction to Distributed Programming in REX. ESPIRIT ‘91, Brussels,

168

References

[Kramer 1983] J. Kramer, J.N. Magee, M.S. Sloman and A. Lister. CONIC: An integrated approach to distributed computer control systems, IEE Proceedings vol. 130 (Part E, No 1), 1983, pp 1-10. [Lehman 1982] M.M. Lehman (1982). Program Evolution. Symposium on Empirical foundations of Information and Software Science, Atlanta, Georgia, [Magee 1993] J. Magee, N. Dulay and J. Kramer. Structuring Parallel and Distributed Programs, Software Engineering Journal vol. Vol 8 No 2 (Special Issue on Configurable Distributed Systems), 1993, pp 73-82. [Microsoft 1990] Microsoft. Microsoft Windows User’s Guide, Microsoft Corporation, 1990 [Moffett 1990] J.D. Moffett, Delegation of Authority using Domain Based Access Rules, Ph.D. Thesis, University of London 1990 [Moffett 1992] J.D. Moffett and M.S. Sloman. Policy Hierarchies for Distributed Systems Management, Imperial College of Science, Technology and Medicine, Domino Report Report Arch/IC/6, June 1992 [Moffett 1990] J.D. Moffett, M.S. Sloman and K.P. Twidle. Specifying Discretionary Access Control Policy for Distributed Systems, C o m p u t e r Communications vol. 13 (9), 1990, pp 571-580. [Nyre 1988] A. Nyre. X Window System User’s Guide, O’Reilly & Associates, Inc., 1988 [OSF 1992] OSF. OSF Distributed Management Environment Architecture, Open Software Foundation, Report for OSF Member Review

169

References

[OXFORD] OXFORD. The Pocket Oxford Dictionary of Current English, Oxford University Press, [Raeder 1991] G. Raeder. OSFA: An Object Oriented Distributed Approach to Network Management. Integrated Network Management. , North Holland, 1991. , ed. I. Krishnan and W. Zimmer. pp 135-146. [RFC1034] RFC1034. Domain Names - Concepts and Facilities. P. Mokapetris. SRI Network Information Center. [RFC1035] RFC1035. Domain Names - Implementation and Specification. P. Mokapetris. SRI Network Information Center. [RFC1157 1990] RFC1157. A Simple Network Management Protocol. J. Case, M. Fedor, M. Schoffstall and J. Davin. SRI Network Information Center. 1990 [RFC822] RFC822. Simple Mail Transfer Specification. SRI Network Information Center. [Richie 1978] D.M. Richie and K. Thompson. The UNIX Time-Sharing System, Bell Systems Technical Journal vol. 57 (6 part 2), 1978, pp 1905-1929. [Robinson 1988] D. Robinson, Domains. A Uniform Approach to Distributed System Management, Ph.D. Thesis, University of London 1988 [Sandberg 1985] R. Sandberg, D. Goldberg, S. Kleiman, D. Walsh and B. Lyon. Design and Implementation of the Sun Network File System, USENIX Association Conference Proceedings vol. June 1985 , 1985, pp 119-130.

170

References

[Satyanarayanan 1989] M. Satyanarayanan. Integrating Security in a Large Distributed System, ACM Transactions on Computer Systems vol. 7 (3 August 1989), 1989, pp 247-280. [Scheifler 1986] R.W. Scheifler and J. Gettys. The X Window System, ACM Transactions on Graphics vol. 2 (5), 1986, pp 79-109. [Sloman 1986] M.S. Sloman, J. Kramer, J.N. Magee and K.P. Twidle. F l e x i b l e communication structure for distributed embedded systems, IEE Proceedings vol. 133 (Pt. E, No. 4), 1986, pp 201-211. [Sloman 1989] M.S. Sloman and J.D. Moffett. Domain Management for Distributed Systems. Integrated Network Management. , North Holland, 1989. , ed. B. Meandzija and I. Westcott. pp 505-516. [Sloman 1992] M.S. Sloman, B.J. Varley, J.D. Moffett and K.P. Twidle. D o m a i n management and Accounting in an International Cellular Network, Imperial College of Science, Technology and Medicine, Domino Report Report D2/IC/1, August 1992 [Strutt 1991] C. Strutt. Dealing with Scale in an Enterprise Management Director. Integrated Network Management. , North Holland, 1991. , ed. I. Krishnan and W. Zimmer. pp 577-593. [Sun-Microsystems 1990] Sun-Microsystems. Open Look: Graphical User Interface Application Style Guidelines, Addison-Wesley, 1990 [Twidle 1986] K. Twidle. Iman - The Conic Interactive Configuration Manager. 1986

171

References

[Twidle 1988] K.P. Twidle and M.S. Sloman (1988). Domain Based Configuration and Name Management for Distributed Systems. Workshop on Future Trends of Distributed Computing Systems in 1990s, Hong Kong, IEEE Computer Society. [Twidle 1992] K.P. Twidle, M.S. Sloman, J.N. Magee, J. Kramer, N. Dulay, et. al. (1992). Configuring Heterogeneous Open Systems. 1st International Conference on Enterprise Integration Modelling Technology, Hilton Head, South Carolina, MIT Press.

172

Appendix A DOME Information Interchange

In addition to the values returned by DOME operations, if any, there is a status reply giving details about the success or failure of the operation (see table 6.1). Each status reply comprises a numeric part which can be interpreted by a program and a text string that can be displayed, if necessary, to the user.

A.1 Details of Domain Service status messages This error message structure and description is based on and borrowed freely from the Simple Mail Transfer Protocol described in [RFC822]. Status messages consist of a four digit code for a program to understand and a message string that may be shown to a user. The four digits of the reply each have a special significance. The first digit denotes whether the response is good, bad or incomplete. An unsophisticated program will be able to determine its next action (proceed, redo, fail) by simply examining the first digit. A program that wants to know approximately what kind of error occurred (e.g. bad authorisation, non-existent object) may examine the second digit, reserving the third and fourth digits for the finest graduation of information. There are five values for the first digit of the reply code: 1yzz

Positive Preliminary reply The operation has been accepted, but the requested action is being held in abeyance, pending confirmation of the information in this reply. The sender of the operation should send another command specifying whether to continue or abort the action. SMTP does not use this reply.

2yzz

Positive Completion reply The requested operation has been successfully completed.

173

Appendix A

DOME Information Interchange

3yzz

Positive Intermediate reply The operation has been accepted, but the requested action is being held in abeyance, pending receipt of further information. This reply is used in an operation that requires a sequence of messages.

4yzz

Transient Negative Completion reply The operation was not successful. However, the error condition is temporary and the action may be requested again.

5yzz

Permanent Negative Completion reply The operation was not accepted and the requested action did not occur.

The second digit encodes responses in specific categories: x0zz

Syntax The operation is unimplemented eg Domain_List sent to a non-domain object.

x1zz

Information These are replies to requests for information, such as status or help.

x2zz

Connections These are replies referring to the underlying messaging system.

x3zz

Access Control These are replies referring to the access control mechanism

x4zz

General Operations These are replies referring to application specific operations

Status replies that take up more than one line have a ‘-’ character instead of the space separating the number from the message string; this indicates that another line is following. The last line of a sequence of lines will have a space. This system allows as small a set as possible of status codes to be defined; programs that interpret them are simplified and new applications can use them without having to reprogram everything. Some error numbers and strings are:

174

Appendix A


2100 OK 2101-Create object arguments are: 2101-String - new name 2101-Integer - data buffer size 2101 Integer - printer number 4200 Cannot talk to object 4201 Cannot talk to domain service 4201 Cannot talk to node manager 4201 Cannot talk to domain server 5000 Operation not supported 5001 Parameters to operation not supported 5300 Access denied 5301 Access to source object denied 5301 Access to target object denied

A.2 Object Type Strings Object type strings consist of super-types and type of an object separated by full-stop characters. Multiple super-types will be shown using a comma separated list of type strings enclosed in parentheses. eg: a.b.c (a,f,h.i).l == a.l f.l h.i.l (a.b,a.c).d == a.(b,c).d

-- c is a subtype of a.b -- l is a subtype of a,f and h.i -- d is a subtype of a.b and a.c

An extended BNF description of the type string is: type ::= [ ‘.’ ]* type field ::= | ‘(‘ [ ‘,’ ]* ‘)’ type name ::= [A-Za-z0-9_]+ key:

* = zero or more + = one or more

175

Appendix A


A.3 General Object Attributes for all objects Field OID CreationTime Creator Host ObjectType ObjectCreationComment ObjectComment

Example 321436235 [email protected] gummo.doc.ic.ac.uk conic.dserver This is an object Last updated at PM

176

Appendix B Conic DOME Service Interface

This section describes the interface to the various parts of the Domain Service for the Conic user. All Conic nodes are considered objects and have an object interface; particular objects that comprise the Domain Service are: Domain Servers, Domains and Node Managers. In addition there is a Domain Manager which allows a user to interact with the Domain Service.

B.1 Object Interface Every object has an OID (Object Identifier) containing a unique identification string, a basic object type, an address (which may possibly be out of date) and the address of its node manager. OIDt = record Id : ObjType : Addr : NodeMan : end;

ObjectId; ObjectType; ObjectAddress; ObjectAddress;

{ { { {

A unique identifier } Basic types } Temporal Address } Object's Nodemanager}

The Domain Service and Domain Manager need to distinguish whether the object is a domain or another object. At present only two basic object types are defined. Knowledge of the basic object type is useful in a distributed environment as it can save unnecessary messages being sent. eg. there is no point in asking anything other than a domain object for a list of its domain attributes or contents. ObjectType = ( domain_object, conic_object );

The object’s address is a temporal address with an age field allowing two addresses to be compared and the most up-to-date to be determined.

177

Appendix B

Conic Domain Service Interface

ObjectAddress = record age : integer; { Incremented when address changes } addr : RealAddress; { Address type (IP, X.25) and address} end;

All replies from objects contain a status return string that consists of a three digit number followed by a text string. The digits are for use by the receiving program and the text string can be displayed to the use if necessary. statusT = packed array [1..MAXSTATUS] of char;

All objects can return their basic details when asked. This information is held in a registration record (so called because a Conic Object sends this record to its local node manager to register its presence). register_msg = record id : OID; user_name : namebuf; stat_rec : status_rec; end;

All objects have the following basic interface: entryport object_info

: OID reply register_msg;

Where: object_info

Returns information about the object. The OID in the request must be correct when sent to an object that is behind another object. i.e. domains are objects but are actually held in a database by a factory object (the Domain Server). The OID is ignored by other objects; to get the OID of a Node Manager (which exists at a well known address) this message can be sent to that address without a valid OID, a valid OID will be returned in the register_msg.

178

Appendix B


B.2 Domain Interface All messages to domains contain the OID of the domain being addressed. The basic types used are: type namebuf = packed array [1..NAMEBUFLEN] of char; pathbuf = packed array [1..PATHBUFLEN] of char;

The following three message types can hold all the combinations of parameters that are required for the Domain messages: ds_name_oid_msg = record domain : OIDt; { Receiving domain’s OID } name : namebuf; { Name of an entry in the domain } id : OIDt; { OID of an object } end; ds_path_msg domain path status end;

= : : :

record OIDt; { Receiving domain’s OID pathbuf; { Path name of an object statusT;

} }

entry_type = (object_entry, context_entry12, link_entry); object_message = record name : namebuf; entypr : entry_type; id : OIDt; path : pathbuf end; otableT = record count : integer; { Receiving domain’s OID object : array [1..MAXOTABLE] of object_message; { List of name, OID pairs status : statusT; end;

1 2 Not used

179

} }

Appendix B


The possible error returns when performing a Domain operation are: domERRT = ( domERRdnf, domERRnap, domERRoap, domERRonf, domERRpaf, domERRprf, domERRsys, domOK, domWRNpaf, domWRNprf, domWRNzzz );

{ { { { { { { { { { {

Domain Not Found Name Already Present Object Already Present Object Not Found Parent Add Failed Parent Remove Failed Internal System Error OK nothing wrong Parent Add Failed Parent Remove Failed Dummy last error

} } } } } } } } } } }

The interface consists of the generic object interface plus entryport dom_include dom_remove

: ds_name_oid_msg reply domERRT; : ds_name_oid_msg reply domERRT;

dom_add_link dom_remove_link

: ds_name_oid_msg reply signaltype; : ds_name_oid_msg reply signaltype;

dom_list

: OIDt reply otableT;

obj_lookup_oid13 obj_lookup_path

: ds_path_msg reply ds_path_msg; : ds_name_oid_msg reply ds_name_oid_msg;

Where: dom_include

Include (name, OID) in domain. Update the parent list of OID dom_remove

Remove (name, OID) from domain. Update the parent list of OID dom_add_link

Add a link from name to OID in domain. Do not update the parent list of OID dom_remove_link

Remove the link from name to OID in domain. Do not update the parent list of OID

1 3 This is called path_lookup in the current implementation

180

Appendix B


dom_list

Return the Name Set of the domain as a list of name, OID pairs. obj_lookup_oid

Given a path name the domain will take the first component (delimited by the ‘/’ character), match it with a name in its Name Set and return the OID of that component and the rest of the path name. Obviously the simple case of a path name containing just one component can be viewed as a name to OID lookup. obj_lookup_path

Given an OID returns a pathname to the object with the OID.

B.3 Domain Server The Domain Server acts as a Domain factory and holds a database containing the domains that it has created. Domains are objects in their own right and can be sent messages. They share the same physical address with their Domain server so the messages are actually sent to the Domain interface of the domain server and handed on to the domains themselves within the database. B.3.1

Domain Server Interface

The interface comprises the Domain interface plus entryport dom_create dom_destroy path_lookup

: signaltype : OIDt : ds_path_msg

reply OIDt; reply signaltype; reply ds_path_msg;

Where: dom_create

Creates a new domain in the domain database and returns its OID dom_destroy

Destroys a domain that is contained within the domain database

181

Appendix B


path_lookup

This is similar to the path_lookup described in the domain interface above. However, as much as possible of the path name will be resolved (converted to an OID) as long as the Domain Server holds the domains being matched within its own database. If the path name is empty then the OID is the desired result, if not the returned message should be sent to the OID in the reply (it will be the OID of a domain held in another domain server). This service will normally only be used by the Node Manager when resolving whole pathnames for applications (see below).

B.4 Node Manager The Node Manager acts as an interface to the Domain Service for objects on the host that it manages. Objects that start on the Node Manager’s host are registered with the Node Manager using the registration message. If necessary, the Node Manager ensures that the object is included into the correct (default) domain for that object. Objects inform the Node Manager of any changes in their parent set. When the object terminates it sends a deregister message to the Node Manager which ensures that it is removed from the domain system. It is necessary for the Node Manager to do this as objects may not have the time to complete their removal from the domain system. Objects may terminate unexpectedly in which case the Node Manager can spot this and using its information about the node can either restart it or remove it from the domain service. The Node Manager holds a set of parent OIDs for each local object. They are changed using the following message type: parent_req = record obj : OIDt; id : OIDt; end;

{ The addressed object } { The parent }

182

Appendix B


Parent lists are returned as: ptableT = record count : integer; table : array [1..MAXPARENTS] of OIDt; end;

The interface comprises the Object interface plus entryport register deregister add_parent del_parent parent_list ancestor_list path_lookup object_lookup_path

: : : : : : : :

register_msg reply signaltype; register_msg reply signaltype; parent_req reply domERRT; parent_req reply domERRT; OIDt reply ptableT; parent_req reply ptableT; ds_path_msg reply ds_path_msg; OIDt reply ds_path_msg;

Where: register

Accepts a registration message from an object or its factory. The object is included into the domain service into a default domain. deregister

Accepts a de-registration message from an object or its factory. The object is removed from the domain service. This may require removal from more than one domain depending on the parent list held for that object. add_parent

Adds a parent to the parent list held for an object. del_parent

Removes a parent from the parent list held for an object. parent_list

Returns the list of the object’s parent’s OIDs ancestor_list

Returns the list of the object’s ancestor’s OIDs path_lookup

Similar to the Domain Server’s path_lookup service but will ask many Servers if necessary to fully resolve the path. This allows an application object to resolve a path using just one message.

183

Appendix B


obj_lookup_path

Given an OID the Node Manager will trace the parents back to the root and return one (of the possible many) pathname identifying the object.

184

Appendix C Smalltalk DOME Service Interface

As a first attempt at a graphical user interface for DOME we have implemented a complete set of asynchronous communication classes for Smalltalk [Goldberg 1989]. These classes enable Smalltalk to appear as a Conic node to the network responding normally to information and operation messages from other Conic nodes. Indeed, externally there is no difference between the Smalltalk “Conic” node and any other Conic node. From the Smalltalk “side” the user has the normal Smalltalk environment but can easily create Conic tasks to send and receive Conic messages. This appendix describes the use of the domain classes that have been built on top of the Conic classes.

C.1 Description The Smalltalk Domain Service Interface is based on the Conic record specifications in Appendix A. All operations are accessed through the “DomainServiceOp” class. All domain/object related Conic types will have equivalent Smalltalk classes with each field as an instance variable and methods to set and retrieve them. eg. for the OID message type: OIDt = record Id : ObjType : Addr : NodeMan : end;

ObjectId; ObjectType; ObjectAddress; ObjectAddress;

{ { { {

A unique identifier } Basic types } Temporal Address } Object's Nodemanager}

Smalltalk has the class “OID” with methods: and nodeMan The first three methods, each taking an argument of the appropriate type, will set the value of the named field. The last

id:, objType:, addr:, id, objType, addr

185

Appendix C

Smalltalk Domain Service Interface

four methods take no arguments but simply return the value of the named field. As a special case ObjectAddress, in addition to these “standard” methods, will be a class that understands >,