Controlling Access in Multiuser Interfaces - Dan R. Olsen Jr

Controlling Access in Multiuser Interfaces PRASUN DEWAN University of North Carolina at Chapel Hill and HONGHAI SHEN IBM Santa Teresa Lab

Traditionally, access control has been studied in the areas of operating systems and database management systems. With the advent of multiuser interfaces, there is a need to provide access control in the user interface. We have developed a general framework for supporting access control in multiuser interfaces. It is based on the classical notion of an access matrix, a generalized editing-based model of user-application interaction, and a flexible model of user-user coupling. It has been designed to support flexible control of all significant shared operations, high-level specification of access control policies, and automatic and efficient implementation of access control in a multiuser interface. It supports several new kinds of protected objects including sessions, windows, and hierarchical active variables; a large set of rights including not only the traditional semantic rights but also interaction and coupling rights; a set of inference rules for deriving default permissions; and a programming interface for implementing access control in multiuser interfaces. We have implemented the framework as part of a system called Suite. This article describes and motivates the framework using the concrete example of Suite, identifies some of the difficult issues we faced in its design, describes our preliminary experience with it, and suggests directions for future work. Categories and Subject Descriptors: C.2.4 [Computer-Communication Networks]: Distributed Systems—distributed applications; distributed databases; D.2.2 [Software Engineering]: Tools and Techniques—user interfaces; D.2.6 [Software Engineering]: Programming Environments—interactive; D.3.3 [Programming Languages]: Language Constructs—input/output; H.1.2 [Models and Principles]: User/Machine Systems—human factors; H.4.1 [Information Systems Applications]: Office Automation; I.7.2 [Text Processing]: Text Editing General Terms: Design, Human Factors, Languages Additional Key Words and Phrases: Access control, collaboration, computer-supported cooperative work, groupware, privacy, security, structure editors, user interface management systems

This research was supported in part by IBM, a Purdue Research Foundation Fellowship, by National Science Foundation grants IR-9408708, IRI-9508514, IRI-9627619, and CDA-9624662, and by DARPA/ONR grant N-66001-96-C-8507. Authors’ addresses: P. Dewan, Department of Computer Science, University of North Carolina, Chapel Hill, NC 27599; email: [email protected]; H. Shen, IBM Santa Teresa Laboratory, 555 Bailey Avenue, San Jose, CA 95141; email: [email protected]. Permission to make digital / hard copy of part or all of this work for personal or classroom use is granted without fee provided that the copies are not made or distributed for profit or commercial advantage, the copyright notice, the title of the publication, and its date appear, and notice is given that copying is by permission of the ACM, Inc. To copy otherwise, to republish, to post on servers, or to redistribute to lists, requires prior specific permission and / or a fee. © 1998 ACM 1073-0516/98/0300 –0034 $5.00 ACM Transactions on Computer-Human Interaction, Vol. 5, No. 1, March 1998, Pages 34 –62.

Controlling Access in Multiuser Interfaces

•

35

1. INTRODUCTION There are three reasons why a multiuser interface might provide access control. First, it may wish to prevent a user from making mistakes that are difficult or expensive to reverse. For instance, a document editor may wish to prevent a user interested in making a private change from accidentally coupling with other users and sharing the change with them. Second, it may wish to prevent violation of security constraints. For instance, an exam management application might wish to prevent the test-taking students from communicating with each other. Third, it may wish to prevent actions that use scarce shared resources even if these actions do not violate security constraints. For instance, an application broadcasting public information may wish to prevent a user from joining the session if the overhead of transmitting the information to the user would degrade the response times of other users. So far, the thrust of the work in multiuser interfaces has been on computer support for enabling collaboration rather than controlling it. Most multiuser applications give all users the same rights to all objects and expect access to be controlled by social protocol. Social protocol, however, is not sufficient to prevent mistakes or malicious actions. Access control has been addressed in the areas of multiuser operating systems and database systems. These systems provide access control in the “back-end” of an application, i.e., in the persistent store. An interactive program can use these solutions to indirectly control actions of its users. Part of the state displayed in a user interface must be retrieved from or saved to persistent store. If this state is protected, then an interactive program that tries to load/store this state for an unauthorized user would be prevented from doing so by the persistent store manager (operating system/database system). For instance, a text editor can indirectly prevent an unauthorized user from loading a protected file, since the operating system would disallow the operation. However, it is not sufficient to provide access control in the back-end of an interactive program, for several reasons: —Late feedback: Users receive feedback regarding validity of their changes to the user interface state when the interactive program tries to save it on persistent store, not when they make these changes. For instance, a user of a text editor who makes a series of changes to the editing buffer receives feedback about the validity of these changes when the editor tries to write the buffer to a protected file rather than when the changes were made. Late feedback can lead to a considerable amount of wasted work. —Session-independent binding: All user interface sessions manipulating the same persistent object provide the same access control. For instance, all instances of a text editor that try to load/save the same file provide the same access control. Sometimes, it is useful to do session-specific ACM Transactions on Computer-Human Interaction, Vol. 5, No. 1, March 1998.

36

•

Prasun Dewan and Honghai Shen

binding of access rights, as illustrated by the design of the Unix “vi” editor, which allows a user to invoke the editor in the read-only mode even if the file being edited is writeable. —Physical protection units: User interface objects such as windows, drawings, and paragraphs are often very different from persistent objects such as database records and operating system files. Interactive programs must, therefore, map the semantic or “logical” structures defined by the user interface to representation or “physical” structures defined by the persistent store. Requiring access specifications to be associated with persistent objects forces users to be aware of this mapping and work in terms of physical rather than logical units. This problem is reduced in a persistent programming language [Atkinson and Buneman 1987], which provides a persistent store that understands all data structures defined by the language. However, such a language is still a matter of research. Moreover, an interactive application may use the language abstractions to build higher-level abstractions such as windows and widgets that are not understood by the language. —Physical rights: Similarly, the rights supported by an operating system/ database system are defined in terms of operations on persistent objects. These include mainly the traditional read and write rights. However, an interactive program often defines higher-level logical operations such as the move and resize operations, which need to be associated with higher-level logical rights. Thus, users are forced to map logical rights to physical rights. —Partial protection: Only part of the user interface state is transferred to and from persistent store. Ephemeral objects such as scrollbar and window positions are not retrieved from or saved to persistent store. In most multiuser interfaces, these objects also can be shared by multiple users, and thus need to be protected. An access control solution provided by the back-end does not apply to these objects. These problems can be overcome if access control is provided at the “front-end” of an interactive program by its user interface. This idea has been used in the design of a few interactive applications. For instance, some text editors keep track of the (OS-managed) access rights of the files loaded in their buffers and give error messages when user operations on these buffers are not consistent with these rights. A more important example is the Grove [Ellis et al. 1989] multiuser outline editor, which manages all aspects of access control in the user interface. It allows users to define access rights in terms of fine-grained logical units such as outline items rather than coarse-grained physical units such as files. Within a shared view, an item is associated with an authorization form, which a user can fill interactively to enter access definitions. GROVE also supports structure inheritance of protection information: a child item in a hierarchical outline inherits the access definitions from its parent. ACM Transactions on Computer-Human Interaction, Vol. 5, No. 1, March 1998.


•

37

It would be useful to extend this idea by developing a general framework for defining access control in single-user and multiuser user interfaces.1 Ideally, such a framework should meet the following requirements: —Automation: It should automate the implementation of access control in a multiuser application. —Generality: It should support arbitrary applications. —Total mediation [Saltzer 1974]: Every access to every object should be checked for current authority. —Least privilege [Saltzer 1974]/flexibility: Every application and every user should operate using the least amount of privilege necessary to complete the job. This is also called the “need to know” principle. This principle implies that the framework should be flexible, i.e., it should support arbitrary access control policies. —Ease of use/high-level: It should be easy to specify these policies. This principle implies that the framework should be high level, i.e., it should require few specifications to specify the desired policy. —Efficiency: The cost of storing, modifying, and checking access specifications should be low. Some of the above requirements conflict with each other. It is difficult to achieve ease of use without sacrificing flexibility, since understanding and configuring the parameters introduced for flexibility adds complexity to the model, which can conflict with the ease-of-use requirement. It is also difficult to meet the flexibility and efficiency requirements at the same time. Flexibility can add many run-time parameters to the model, which can affect the efficiency. Efficient storage and evaluation can conflict with each other because of the traditional time-space trade-off. Finally, the addition of abstractions to ease the access specification effort increases the complexity of implementing access control. Thus, a framework that attempts to meet all of these requirements must make trade-offs when it has to choose among conflicting requirements. General frameworks for meeting these requirements have been developed as part of the research in operating systems and database management systems. Part of this research can be used directly in the development of an access control framework for user interfaces. For instance, the Unix notion of dividing the users of a protected object into the sets “owner,” “group,” and “others” and associating with the object rights for each of these sets can be used to protect not only persistent objects but also user interface objects. However, there are at least three new related questions that must be answered in the design of such a framework: —Nature of protected objects and rights: What are the protected objects in a user interface, and what are the rights to these objects? As mentioned 1

In the rest of this article, we shall use the term multiuser interface for user interfaces that interact with both single and multiple users, since a single user interface can be considered a special case of a multiuser interface. ACM Transactions on Computer-Human Interaction, Vol. 5, No. 1, March 1998.

38

•


above, the protected objects and rights defined by persistent store managers are not always appropriate for multiuser interfaces. —Management of large object and right sets: In comparison to a persistent store, a user interface offers a much richer interface to manipulate objects. As a result, the sizes of the sets of protected objects and rights are much larger, which in turn substantially increases the space of access policies. How can the framework reduce the impact this large space has on the ease of use, automation, and efficiency requirements, which become more difficult to satisfy? —Access-control abstractions: What kind of abstractions are provided to incorporate access control in a user interface? These issues have been partly addressed by some of the recent groupware systems. GroupKit [Roseman and Greenberg 1996] defines a distributed architecture for implementing session control wherein replicated session managers (1) provide users with an interface to create, delete, locate, join, leave, and save conferences and (2) discover awareness information, i.e., information about other users in a session. Using GroupKit primitives, programmers can build different session manager policies by controlling access to these operations. GroupKit includes three different session managers as examples of how particular policies can be implemented. The “open registration” policy does not protect any of these operations; anyone can create, join, and leave conferences at any time. The “single facilitator” policy implements a mediated conference, where only a single, distinguished user, called the facilitator, can invoke these operations. The “rooms” policy is a place-based policy, where access to groups of groupware tools is granted to people who enter a “virtual room,” which is itself a cluster of current participants and tools. Intermezzo [Edwards 1995] is another framework for controlling session management and awareness. It provides fine-grained control of awareness information, allowing the name, phone, location, activities, and other attributes of users to be protected independently. It also offers a powerful interpretive language for controlling access based on dynamic information about users kept in its awareness objects. For instance, it allows users to share their workspaces with colocated users. COLA [Trevor et al. 1994] provides a generic abstraction, called an access control adapter, for guarding the operations of an object. When a client makes an object invocation, it supplies the access control adapter with context information containing its name, role, and activity. The adapter uses this information and a set of access rules to determine if the method should be applied. The operations of an object are arranged in hierarchical access levels within a “ladder,” and an access rule defines the client’s access level and associated ladder. While these systems are good examples of how access control may be incorporated in a multiuser framework, they have not been designed to address all of the requirements and issues presented above. In particular, GroupKit and Intermezzo do not protect operations to manipulate applicaACM Transactions on Computer-Human Interaction, Vol. 5, No. 1, March 1998.


•

39

tion state such as a Grove outline, while Cola’s low-level adapters do not support automation of access control. We have developed a new access control framework (which was created independently and at approximately the same time as these systems) explicitly designed to address these requirements and issues. It is based on the classical notion of an access matrix, a generalized editing-based model of user-application interaction, and a flexible model of user-user coupling. It supports several new kinds of protected objects including windows and hierarchical active variables; a large set of rights including not only the traditional semantic rights but also interaction and coupling rights; a set of inference rules for deriving default permissions; and a programming interface for implementing access control in multiuser interfaces. We have implemented the framework as part of a system called Suite [Dewan and Choudhary 1992]. A previous conference paper [Shen and Dewan 1992] briefly discusses a preliminary version of this framework. More detailed presentations of some of these concepts are given in Shen’s dissertation [Shen 1994]. The rest of the article is organized as follows. Section 2 describes the previous work on which our framework is based. Section 3 presents an example of a multiuser application, which serves as a running example in the article, motivating and illustrating the framework. Section 4 is the main part of the article, describing the various components of the framework. Finally, Section 5 gives conclusions and discusses potential directions for future work. 2. BASES Our framework is based on previous work in both access control and user interfaces. In particular, it is based on the classical notion of an access matrix, a generalized editing-based interaction model, and a flexible coupling model. In this section, we outline the aspects of these works used in the design of our framework. The classical matrix model provides a framework for defining protection systems. It was proposed by Lampson [1971] and refined by Graham and Denning [1972] for protection in operating systems. Conceptually, the model describes what a protection state is and how state transitions occur. Assume a set of protected objects, which are the entities to which access must be controlled; and a set of subjects, whose access to objects must be controlled. The protection state of the system is represented by an access matrix, A. The rows of the matrix represent the subjects; the columns represent the objects; and an entry, A[s,o], denotes the access rights a subject s has over an object o. The access-checking rule of the model states that a request by subject s for accessing object o is granted only if A[s,o] contains the requisite right. The model also contains a set of rules (commands) governing changes to the subjects, objects, and rights in an access matrix. In particular, the model supports the notion of ownership and defines rules allowing the owner of an object to grant rights to others. ACM Transactions on Computer-Human Interaction, Vol. 5, No. 1, March 1998.

40

•


The above model does not specify the exact nature of the subjects, objects, or access rights supported by the system. As a result, it offers users complete flexibility in specifying access control policies. However, it is not sufficient for meeting the other requirements. It requires that all granted rights be explicitly specified by users and stored by the system, which makes it difficult to use and inefficient. Moreover, since the model does not define the nature of subjects, objects, or rights, it cannot be automated by an infrastructure. These requirements can be met by focusing on some large domain requiring access control, using the domain semantics to make assumptions about the protected objects, subjects, and rights, and using these assumptions in the design of the access control framework. The key to this approach is to identify assumptions that, in practice, do not significantly reduce the flexibility of the framework but allow large gains in ease of use, automation, and efficiency. This approach has been used both in the domain of operating systems and database management systems. For instance, in the operating system domain, Unix-based systems assume that all protected objects support file operations such as the open, read, and write operations; and they provide an automatic, easy-to-use, and efficient framework for protecting these objects. This framework applies not only to a variety of files such as text, graphics, and object files but also other types of objects such as directories, devices, and communication channels that offer the file operations. In order to use this approach in the domain of multiuser interfaces, it is necessary to similarly identify a set of abstract objects to which a large variety of specific shared user interface objects can be mapped. As part of our work on the Suite multiuser framework, we have identified a generic model, called the Suite collaboration model, that defines such objects. This model has two components: an interaction model, which describes the semantics of user-program communication; and a coupling model, which describes the semantics of user-user communication. The Suite interaction model is based on the notion of generalized editing [Dewan and Solomon 1990]. It offers the abstraction of an active variable [Dewan and Choudhary 1992], which is a program data structure of arbitrary type that can be edited to trigger actions in the program. The model also creates, for each user of the program, a set of interaction objects, which defines the user interface provided to edit the active variables of the program. These objects include interaction variables, value groups, and object windows [Dewan and Choudhary 1992]. An interaction variable is the local buffer for an active variable in which the user composes changes to the variable. The user can commit the value of the interaction variable to update the corresponding active variable and trigger application-defined computations. An interaction variable is associated with a set of attributes, which stores the interaction properties of the variable such as the color of its display. A value group is a set of related interaction variables that share some attributes. An object window is a window that displays the values of interaction variables. ACM Transactions on Computer-Human Interaction, Vol. 5, No. 1, March 1998.


•

41

The model also supports the abstraction of a session, which captures the notion of a conference. When a session is first started with an interactive application, the active variables of the application are created. As each user is added to the session, a new set of interaction objects (interaction variables, value groups, windows) is created for that user, which is deleted when the user is removed from the session. A session also maintains other information such as the list of participants in the session, which allows users to be aware of other users in the session. A session is persistent in that it can save itself on persistent storage when there are no active users. A persistent session is implicitly activated when a user next tries to join it and may be destroyed by explicitly deleting it. The Suite coupling model [Dewan and Choudhary 1995] allows interaction objects created for different users to share properties. The shareable properties of an interaction object are divided into several coupling sets. Each coupling set of an interaction object is associated with a Boolean sharing attribute, which determines if the properties in the set are to be shared with corresponding interaction objects created for other users. For instance, the ValueCoupled and FormatCoupled attributes of an interaction variable determine if the value and formatting attributes, respectively, of the variable are to be shared with other users. An interaction object is also associated with several communication attributes, which determine when changes made to its shared properties are communicated to other users. For instance, the TransmitEvent attribute of an interaction variable determines the events that trigger transmission of changes to the variable to other users. The changes can be sent incrementally (as they are made), when all changes to the variable are completed, after a specified period or time, or when the user explicitly executes transmission. Similarly, the TransmitCorrectness attribute of an interaction variable determines how correct the value of the variable must be before it can be shared with other users: raw (no correctness guarantee), parsed (syntactically correct), validated (semantically correct), or committed. Figure 1 illustrates the nature of the Suite collaboration model. We have chosen the Suite interaction model as a basis because it is a general model of interaction offering several contemporary interaction features such as direct manipulation, multithread dialogues, structure-based commands, and continuous update of presentations [Dewan and Solomon 1990]. Most interactive applications known to us, such as program editors and spreadsheets, support this model of interaction. We have chosen the Suite coupling model as a basis because it is the most general coupling model known to us. It covers the couplings defined by all collaborative applications known to us, including both synchronous and asynchronous applications. 3. RUNNING EXAMPLE We shall illustrate our access control framework using the example of a software engineering application we have developed as part of a collaboraACM Transactions on Computer-Human Interaction, Vol. 5, No. 1, March 1998.

42

•


Fig. 1. The Suite editing-based collaboration model. The dials represent flexible sharing among corresponding object windows and interaction variables.

tive environment called FLECSE (FLexible Environment for Collaborative Software Engineering) [Dewan and Riedl 1993]. The application allows multiple users to edit C functions simultaneously and examine the coverage results of selected functions, as shown in Figure 2. Figure 3 describes the active variables displayed in the editing windows of the users. These include the program_name and funcs variables, which store the name of the program being edited/tested, and the sequence of functions in the program, respectively. (A sequence in Suite is an array of variable length consisting of two parts: a number specifying the length and an array holding the contents.) Each function is a structure consisting of a function name and a textual body. For each user, the system creates a separate set of interaction variables, which are displayed in the editing window of the user, as shown in Figure 2. We shall use this application for motivating and describing our access control framework. We will present other examples later to illustrate the range of applications our framework can support. However, this application will serve as the primary running example in our description given in the next section. 4. FRAMEWORK We describe the design of the framework at three levels of abstraction. First, in Section 4.1, we describe some of the main principles followed in the design of the framework. Then, in Section 4.2, we discuss the basic idea of an extended access matrix used to meet these principles. Finally, in the remaining sections, we detail how this concept is realized in the framework. 4.1 Design Principles Based on past work and scenarios of multiuser interaction, we have identified several principles for meeting the requirements of flexibility, ACM Transactions on Computer-Human Interaction, Vol. 5, No. 1, March 1998.


•

43

Fig. 2. Two users in a collaborative software development session. The users, hhs (left windows) and rxc (right windows), work on separate workstations to examine the coverage result of a C function, insert. User hhs first selects the function insert in his editing window (middle left window) and invokes an appropriate action in his menu window (upper left window). The coverage results of the selected function(s) are then shown in the testing windows of both users (lower windows). The statements that are not covered by the test data are underlined in the testing windows. In the scenario shown, the scrollbars of the editing windows are coupled while the scrollbars of the testing windows are being manipulated independently.

ease of use, total mediation, automation, and efficiency. These include both high-level, general principles and lower-level, more specific principles derived from the former. —Permission rather than Exclusion [Saltzer 1974]: The protection mechanism should be based on permission rather than exclusion. The default situation should be lack of access, and the protection scheme should identify conditions under which access is permitted. This is safer than giving permission by default. —Predefined Generic Rights: The framework must support as many predefined rights as possible to save programmers the task of implementing them. —Extensibility: Since it is impossible to anticipate the access rights of all potential applications, the framework should allow application programmers to add new rights and change the semantics of predefined rights. ACM Transactions on Computer-Human Interaction, Vol. 5, No. 1, March 1998.

44

•


Fig. 3.

Declaration of active variables.

—Semantic, coupling, and interaction control: Traditional systems such as database systems and operating systems support only semantic operations such as the read and write operations. Multiuser programs, in addition, support coupling and interaction operations, which complicate the design of a general framework for protecting these programs. Coupling operations allow users of a multiuser program to couple interaction objects created by their user interfaces. The system should control invocation of operations on coupled interaction objects. For instance, only the chairperson could be allowed to scroll or move a window to prevent “window wars” and “scroll wars” [Stefik et al. 1987] among users sharing the windows’ position and scrollbar. In addition, it must control the coupling operations themselves to prevent undesirable couplings. For instance, it should prevent students interacting with an exam management application from communicating with each other. Thus, the framework should control not only semantic operations but also coupling and interaction operations. This principle can be derived from the principle of total mediation. —Fine-grained rights: The system should define a separate right for each independent operation on an object. This principle follows from the principle of least privilege and predefined rights. The principle of least privilege implies that users should be given rights to only those operations on objects that they need to invoke in order to perform their jobs. A generic framework does not know which sets of privileges need to be given to the users of an application, and thus does not know which sets of operations need to be associated with predefined rights. Therefore, it must take the conservative approach of assuming that each operation ACM Transactions on Computer-Human Interaction, Vol. 5, No. 1, March 1998.


•

45

may need to be controlled separately, and associate each operation with its own right. —Fine-grained objects: For similar reasons, the system should allow users to associate each autonomous object with its own set of rights. —Exception-based general specification: If the framework supported only fine-grained objects and rights, the cost of specifying access control would make it unusable. Therefore, the system must also allow users to (1) make general access specifications applying to multiple objects and operations and (2) give more specific exceptions to them. This principle is consistent with Saltzer’s comment that the key to meeting the high-level and ease-of-use requirements “lies in better understanding the nature of the typical user’s mental description of protection intent, and then devising interfaces which permit more direct specification of that protection intent” [Saltzer 1974]. Exception-based specification is one specific method for realizing the goal of ease of use, since general settings with exceptions is how, we believe, users typically formulate their intentions. —Negative rights [Rabitti et al. 1991]: In the basic access matrix model, only positive rights are given explicitly, and the default is lack of access. In a system supporting exception-based general specifications, users should also be allowed to explicitly give negative rights to explicitly take away, in a specific case, the positive rights given by a general specification covering the case. —Right implication: The right to perform an operation should automatically imply the right to perform a weaker operation. For instance, the right to perform the modify operation on an object should imply the right to perform the insert operation on it, since the former can be used to achieve the effect of the latter. Right implication reduces the burden of specifying access rights, since after a user has granted a right to an object, he or she does not have to explicitly grant weaker rights to it. —Pessimistic and optimistic access control: This principle addresses protection of local interaction buffers created for the different users sharing an object. Concurrency control is classified into pessimistic and optimistic concurrency control based on whether it checks operations on local buffers for concurrency violations when the operations are invoked or when the local objects are committed. It is possible to similarly classify access control. Pessimistic access control prevents any changes to a buffer that cannot be later committed to the shared object, thereby preventing wasted work. In some situations, however, it is too restrictive. Sometimes it is useful to support optimistic access control, which checks the local buffer for access control violations when it is committed. Under optimistic access control, users are allowed to change their local buffers even if they do not have the rights to change the corresponding global data. It is useful because allowing users to edit their local buffers makes it possible for them to communicate these changes to other users or save these changes locally, even if they do not have the privileges to change the global data. ACM Transactions on Computer-Human Interaction, Vol. 5, No. 1, March 1998.

46

•


To further motivate and distinguish among the related concepts of optimistic and pessimistic access control, consider again our running example and assume that user rxc can change a procedure that user hhs cannot. Under pessimistic control, hhs would not be able to modify the local buffer for the procedure, thereby getting early feedback to access violations. Under optimistic control, he would be able to modify the local buffer but would not be able to commit it. The user can, however, send the buffer to rxc (via coupling), who can then commit it if he approves of the changes. Some of these principles such as permission rather than exclusion and predefined rights are traditional access control principles (originating in database and operating systems research), which we assume also apply to groupware; while others, such as coupling and interaction control, and pessimistic and optimistic control are new principles we have identified based on our experience and that of others with multiuser interfaces. In the next sections, we describe how our framework attempts to meet these principles and resolve conflicts among them. 4.2 Extended Access Matrix Our framework is an extension to the classic matrix model. Although the simple matrix model is not sufficient for meeting the principles given above, it supports the most primitive functionality of an access control framework: with appropriate configuration of an access matrix, the access needs of any system can be defined. Therefore we have chosen it as our extension base. As mentioned in Section 2, one of the disadvantages of the matrix model is that it requires users to enter access definitions explicitly for all the granted rights in the matrix. To reduce the specification effort, our model extends the matrix model by allowing only part of the matrix to be specified explicitly and inferring the rest of the rights automatically. Thus, the protection state of our framework is the four-tuple (S,O,A,F), where S is the set of subjects; O is the set of protected objects; A is an extended access matrix storing explicitly specified rights; and F is a function used to infer rights that have not been explicitly specified. An entry in our extended matrix takes three forms: positive, negative, or inferred. Positive and negative rights are explicitly specified. Inferred is the default setting of the matrix and is represented by a blank entry. It designates inference from function F. The access-checking rule of our model is defined as follows: Access Checking Rule. and only if

A subject s has access privilege r over object o if

(1) A[s,o] contains a positive right r or (2) A[s,o] does not contain a negative right r, and F(s,o,r, A) evaluates to true.

ACM Transactions on Computer-Human Interaction, Vol. 5, No. 1, March 1998.


•

47

While our rule makes inference the default setting, it is possible to define other rules that make denial or granting of rights as the default. Granting the right by default would be inconsistent with the principle of permission rather than exclusion. If the majority of permissions are inferred, then our rule is preferable to making denial the default, since it does not require users to explicitly ask the framework to infer these permissions. Our assumption is that it is possible to define an inference function that makes a specific overriding of a general access specification a truly exceptional event. The other two rules can be supported in our framework by simply giving/denying all users the right group AllR (discussed later) to the generic value group (discussed later). We have described here the basic idea behind the design of our access control framework. We present, in the rest of this section, some of the specific components of the framework that realize the extended access matrix and associated access-checking rule. In particular, we discuss the exact sets of protected objects, rights, and inference rules supported by our framework. We do not, however, discuss the exact set of subjects supported by the framework. While the sets of protected objects, rights, and inference rules are dependent on our domain of multiuser interfaces (defined by the Suite collaboration model), the set of subjects is domain independent. In this article, we are focusing only on the ways traditional access control needs to be adapted when it is applied to the domain of multiuser interfaces. We shall make no assumptions about the domain of subjects and, in our examples, assume that they can be specific users such as hhs, user groups such as faculty, and temporary roles such as chairperson. We shall also assume each object is associated with one or more owners, who are allowed to distribute rights to the object. We shall not discuss how subjects are bound to users, user groups, roles, and other agents that can manipulate objects. Similarly, we will not discuss how objects are associated with owners. Shen’s dissertation [Shen 1994] discusses the specific schemes used in Suite for binding subjects and owners. 4.3 Protected Object Accesses An access control framework may not protect all operations on all objects at all times, violating the total mediation principle for “insignificant” accesses to objects. As mentioned in Section 1, access control is necessary for preventing (1) mistakes that are difficult or expensive to reverse, (2) violation of security constraints, and (3) usage of scarce shared resources. For some object accesses none of these reasons may apply. Consider the operation to scroll a private window. The second and third reasons do not apply, since it is a private operation, and the first reason does not apply, since scrolling is inexpensive and can be easily undone. Thus, there are no practical benefits of protecting such object accesses. On the other hand, there are good practical reasons for not protecting these accesses, since protecting a user command can increase both the user overhead required to understand and use the system and the system overhead required to store ACM Transactions on Computer-Human Interaction, Vol. 5, No. 1, March 1998.

48

•


access specifications and mediate object accesses. For instance, protecting scrolling would increase the time required to implement scrolling. Therefore, a practical access control framework must identify such “insignificant” object accesses and not protect them. Such a system violates the total mediation principle but not its spirit. We have applied this relaxed form of the total mediation principle to the Suite collaboration domain. We protect an object access only if we can find at least one of the three reasons given above for protecting objects. We describe and motivate below the kind of mediation provided by the access control system for the different types of Suite objects described in Section 2: —Active variables: Active variables are variable-grained program data structures that multiple users can modify to trigger actions. Since an active variable is a shared object, the system protects the operation to read and write its value. —Interaction variables: Interaction variables are local buffers for manipulating active variables that are associated with editable attributes and can be coupled with remote interaction variables. Operations that manipulate their coupling attributes are always protected to support coupling control (motivated in Section 4.1). Operations that manipulate values and noncoupling attributes of interaction variables are protected if (1) the interaction variables are coupled with other interaction variables, thereby protecting local actions that can trigger changes in the displays of other users, or (2) the user has explicitly asked for interaction variables to be protected, thereby allowing pessimistic control. Otherwise these operations are not protected, thereby allowing optimistic control, decreasing the overhead of access control mediation, and giving users complete autonomy over their local buffers if their actions to these buffers are localized. —Other interaction objects: Besides interaction variables, other interaction objects (windows and value groups) can also be coupled. Therefore, these objects are also protected, and the criteria used for controlling access to them are identical to the ones used for protecting interaction variables. —Sessions: A session represents a conference among users. Users may perform operations to join, leave, and delete sessions, activate passive sessions, read session information, and remove participants from the conference. The operations to read session information and delete sessions are protected, since they allow users to access and destroy, respectively, shared information. The join operation does not, by itself, allow users to read or write shared information, since they must have additional rights to this information in order to access it. However, it is protected, since it consumes shared resources and since users can be easily denied access to all conference information by simply taking away from them the right to join the conference. (Thus, the reasons for protecting the join operation are similar to the ones used to protect the open operation on Unix files.) Users are always allowed to leave sessions they joined, but need special rights to remove arbitrary users from the ACM Transactions on Computer-Human Interaction, Vol. 5, No. 1, March 1998.


•

49

session. Finally, the activate operation is protected, since it consumes shared resources. Thus, in comparison to traditional database and operating systems, a multiuser user interface must protect a large variety of object accesses. We support the principle of fine-grained rights by associating each protected operation on an object with its own right. Moreover, we support the principle of fine-grained objects by associating each protected object with its own set of rights. This principle, when applied to our domain, raises two questions. Are the interaction variables of an active variable considered separate autonomous objects or one object from the protection point of view? Are the components of an active variable considered separate autonomous objects or a single object from the protection point of view? We discuss these issues below. 4.4 Active Variable and Its Interaction Variables Consider first protection of an active variable and its interaction variables. These objects are closely related to each other in that the interaction variables are local buffers for the active variable. Therefore, we treat them as a single autonomous object associated with a single set of rights. We refer to this autonomous object as a protected variable collection and the active and interaction variables it protects as members of the collection. The rights associated with a protected variable collection protect the union of the operations supported by an active variable and an interaction variable. Both kinds of variables support a common set of semantic operations while the interaction variables, in addition, support interaction and coupling operations. Thus, a protected variable collection is associated with semantic, interaction, and coupling rights. The coupling and interaction rights protect the corresponding operations on the interaction variables. The interpretation of the semantic rights is more complicated. The straightforward interpretation is to make these rights protect both the active variable and the interaction variables. However, this approach does not allow us to support optimistic access control, which allows users to manipulate interaction variables with rights that are different from the ones they have to the associated active variables. Therefore, we use the following, more flexible, interpretation. The rights to the semantic operations protect the interaction variables and not the active variable. A special right, UpdateR, protects the active variable. It determines if the value of an interaction variable can be copied into the corresponding active variable when the variable is committed. Finally, our predefined implication rules, described later, ensure that positive UpdateR to an active variable implies positive WriteR to the interaction variables. This scheme is sufficient to support optimistic and pessimistic access control. If pessimistic access control is desired, then no access specification is made for WriteR. As a result, when users attempt to make changes to their interaction variables, they succeed only if they have been given ACM Transactions on Computer-Human Interaction, Vol. 5, No. 1, March 1998.

50

•


UpdateR because positive WriteR is automatically inferred from positive UpdateR. If optimistic access control is desired, then a positive access specification is explicitly defined for WriteR, thereby allowing users to change their buffers even if they do not have UpdateR. A more flexible approach would be to consider each interaction variable and active variable as a separate protection object with an independent set of rights and owners. This approach, however, has three related problems. First, a scheme must be devised to name both active variables and interaction variables. Second, a larger number of access specifications must be made to protect these objects. Third, we expect that, typically, the same access specifications would be made for an active variable and its interaction variables. In these situations, users would be responsible for ensuring consistency among the access rights associated with these objects. The second and third problems could be eliminated by defining an inheritance relationship that allows interaction variables to inherit rights from active variables. However, this relationship would add to the already difficult problem of multiple inheritance conflicts faced by our framework. Our approach provides consistency among these access specifications by default and allows them to diverge in a limited way, without compounding the multiple-inheritance problem. Our scheme identifies a protected variable collection by the name of the active variable in it. In the rest of the article, we will not distinguish between an active variable and the protected variable collection containing it or between an active variable and its interaction variables. Thus, if we say that a user has the interaction right, ElideR, to an active variable, we really mean that he or she has this right to the collection containing the active variable. Similarly, if we say that a user elides an active variable, we really mean he or she elides the local buffer for the active variable, which, depending on the coupling settings, may cause other interaction variables in its protected variable group to also elide. 4.5 Structure Variable and Its Components Now consider the protection of a structured variable and its components. We associate each of these objects with its own independent set of rights, since in many situations a user must be given different rights to the same operation on these objects. For instance, a user might be allowed to read selected functions in a program. Associating a single read right with the program and all of its components would violate the principle of least privilege. There are situations, of course, when a user must be given the same right to an operation on an object and all of its descendents. As described later, our inheritance schemes allow users to define a single access specification in these situations. This approach raises questions regarding the semantics of certain operations on structured variables. Some operations on a structured variable manipulate not only the variable but also its components. For instance, deleting/hiding/eliding a structure variable also deletes/hides/elides its ACM Transactions on Computer-Human Interaction, Vol. 5, No. 1, March 1998.


•

51

components. We refer to these operations as structure operations. What should be the semantics of a structure operation on a structure variable if a user has the right to perform this operation on the variable but not on one or more of its components? To illustrate why such a situation may arise, consider again our running example. Assume that user rxc inserts comments in a procedure written by user hhs, who has all rights to the procedure. To prevent the comments from being erased accidentally by others, rxc has specified that all users be granted a negative delete right to these comments. Therefore, even though hhs has the delete right to the function, he does not have the delete right to the comments. Our approach to resolving this issue synthesizes the right to perform a structure operation on a variable from the rights to perform the operation on its components. A structure operation is performed in two steps. The first step does the operation on each element of the variable, with access rights checked each time the operation takes place. If the first step succeeds completely, i.e., all operations on the children are successful, then the second step is taken to execute the operation on the whole structure, with the access right checked again. These semantics are inspired by the rmdir command in Unix (a directory cannot be removed unless it is empty, i.e., all the files within it are removed). It is possible to define both (1) a more optimistic approach wherein an operation is performed on a whole tree of nodes if the user has the right to perform it on the root of the tree and (2) a more pessimistic approach wherein the operation is not performed on any node in the tree if the users do not have the right to perform it on all nodes in the tree. We have adopted a compromise between these two extreme approaches. 4.6 Inference in the Object Dimension The principle of fine-grained protection objects requires users to specify and the system to store an access specification for each active variable, which is tedious and inefficient for most applications. For instance, it requires an access specification for each line of the program of Figure 2. This problem is similar to the problem we have encountered in fine-grained specification of display formats of active variables [Dewan 1991]. It is to address this problem that we developed the abstraction of a value group. A value group is a group of active variables associated with its own set of attributes, which are inherited by the members of the group. This abstraction reduces the fine-grained format specification problem, since it requires a user to specify only those format attributes of an individual active variable that are not to be inherited from the value groups to which it belongs. We group active variables based on several criteria. While these groupings were initially chosen to allow easy specification of format attributes of active variables, we have found that several of them are also appropriate for specifying access attributes. We identify below such groups and give example scenarios to illustrate their usefulness from an access control point of view: ACM Transactions on Computer-Human Interaction, Vol. 5, No. 1, March 1998.

52

•


—Generic group: The generic group includes all active variables of the application. The access definitions associated with this group are shared by all active variables. Continuing with the software development example, if we deny “by-standers” the write right to the generic group, then they can change neither the program name nor any functions in the application. —Type groups: A type group is associated with each (predefined and user-defined) type and contains all values of the associated type. For instance, the type group Func groups all instances of the type Func. To illustrate the advantage of making type groups protected objects, assume that a formatter is allowed to change the fonts of all the functions in a program. This specification can be achieved by giving the formatter the right, FontR, to the type group, Func. —Instance groups: Instance groups are defined for individual values. A simple value is associated with a simple instance group. It can be used by rxc to associate a specification with a specific comment line that denies hhs the read right to it. A structure value is associated with a structure instance group, which includes the value and its descendents. It can be used by rxc to associate a single specification with a function that denies hhs the delete right to the function, and all the lines within the function. —Record-field groups: A record-field group contains all objects appearing as a particular field of a particular record type. For instance, the record-field group Func.text contains the text field of all variables of type Func. If we want to deny rxc the right to read the bodies of all functions but not their names, we have to simply give him or her the negative read right to Func.text. —Child groups: They are associated with the children of structure variables: both fields of records and elements of sequences and arrays. An instance-child group is associated with a structure value and groups all descendents of that structure. A structure-child group is associated with a structure-type group and groups all children of structures of that type. Assume that rxc is to be granted the right to elide the name and text fields of a function but not the complete function itself. This access intention can be specified by giving rxc the elide right over the type child associated with the structure-type Func. A particular value can belong to more than one of these value groups and thus inherit access rights from more than one source. For instance, the value funcs[1].text can inherit access rights from the structure group funcs [1] and the record-field group Func.text. In Dewan [1991], we give an approach for resolving this multiple inheritance problem for display attributes. It is based on the fact that a value group has at most two parents: one its IS-PART-OF and another its IS-A kind of. An inheritance directive determines from which of these parents an attribute is inherited and the order in which they are searched. The directive can be none, in which case inheritance is not used, structure-only, in which case the ACM Transactions on Computer-Human Interaction, Vol. 5, No. 1, March 1998.


•

53

IS-PART-OF link is used, type-only, in which case IS-A is used, structure-first, in which case IS-PART-OF is given preference, and type-first, in which case IS-A is given preference. This solution is also used in our access model, since it provides a general and flexible way to resolve the multiple-inheritance problem. We summarize the above discussions by defining the following inheritance rule for inferencing definition in the object dimension: Object Inheritance and Conflict Resolution Rule. A right r of subject s on object o is inherited from the value groups containing o that are chosen by the inheritance directive, i.e., F(s, V(o, r), r, A) 3 F(s, o, r, A) and F(s, V(o, r), 2r, A) 3 F(s, o, 2r, A) where V(o, r) is the set of value groups specified by the inheritance directive associated with o and r; r is either a positive or a negative right; and 3 denotes “imply.” In case of conflicts, the access definition in the first value group chosen by the inheritance directive is used. An alternative approach to resolve the conflict problem, supported in Rabitti et al. [1991], is to check the consistency of all the access definitions and disallow any conflicts. This approach, though simpler, is inappropriate in an environment in which the set of access objects can be very large and dynamic. Whenever a new access definition is entered, potential conflicts could arise. Checking all these conflicts is costly and sometimes even unnecessary when a particular user may need to access only a small portion of a large set of objects. More important, it is less flexible than our approach of tolerating conflicts. For instance, it does not allow the text field of a function to inherit access rights from its record-field group and the name field to inherit them from the function. The above argument also applies to the resolution of conflicts in the access dimension discussed below. 4.7 Inference in the Access Dimension The principle of fine-grained rights results in a large number of access rights. For instance, in the current version of Suite, it results in more than 50 rights because of the large variety of user commands supported by the system. Supporting a large set of rights aggravates the problem of specification and storage of rights. To ease this problem in the access dimension, we support the notion of right groups. They are defined by classifying the individual rights into several logical categories. Each category consists of rights that users are likely to give or deny as a group. For example, TransmitRawR, TransmitParsedR, TransmitValidatedR, and TransmitCommittedR are all rights that control the setting of transmission correctness levels; therefore we put them in the right group TransmitCorrectR. The rights ReadR, WriteR, InsertR, and DeleteR are all included in the DataR right group, because they control the manipulation of the value or semantics of a variable. Similarly, the rights ElideR, HideR, and ACM Transactions on Computer-Human Interaction, Vol. 5, No. 1, March 1998.

54

•


Fig. 4.

Some include relationships and access rights.

SelectR all protect operations that change the view of an object; therefore they are included in the right group ViewR. Because of the number and variety of the rights involved, it is not sufficient to group rights within one level of hierarchy. Therefore, right groups can contain other right groups, as illustrated by Figure 4, which shows some of the predefined right groups and include relationships supported by Suite. Note that unlike an individual right, a right group does not correspond to any specific operation on an object. To allow the rights to be granted or denied as a group, we define the transitive include inheritance relationship among rights and right groups. This relationship is used in the following rule: Right Inheritance Rule. A positive or negative right r of subject s on object o is inherited from the right groups to which it belongs, i.e, F(s, o, R, A) 3 F(s, o, r, A) and F(s, o, 2R, A) 3 F(s, o, 2r, A) where R includes r. To illustrate the use of the above inheritance rule, consider the following scenarios in a classroom examination application. Assume that students hhs and rxc are to be allowed to couple with the teacher, pd, but not with each other. To prevent unauthorized coupling between user hhs and rxc, it is only necessary for user pd to grant rxc and hhs a negative TransmitR to each other. Without right groups, it would be necessary to grant the negative right for each individual transmission right shown in Figure 4. The notion of a right group can be used in combination with negative rights to further simplify the specification task. To illustrate, assume that ACM Transactions on Computer-Human Interaction, Vol. 5, No. 1, March 1998.


•

55

user rxc would like to grant all the data rights to user hhs, except the delete right. This user can achieve this by giving hhs a positive DataR and a negative DeleteR. Without these notions, it would be necessary to grant the read, insert, and write rights to hhs individually. We also support an imply relationship between rights to ease the specification effort. This relationship was first proposed in Fernandez et al. [1975] for protection of read, write, insert, and delete rights in a traditional database system. It models the fact that the right to perform a more powerful operation should guarantee the right to perform a less powerful one. For instance, the right to invoke the write operation should guarantee the right to invoke the insert operation, since the write operation is more powerful than the insert operation. This relationship is used in the following rule: Right Inference Rule. A right r of subject s on object o, if undecided, is inferred from the rights that imply r, i.e., F(s, o, rx, A) 3 F(s, o, r, A) and F(s, o, 2r, A) 3 F(s, o, 2rx, A) where rx implies r. Though originally defined for database systems, the notion of right implication is crucial for the more complex collaborative systems, for two reasons. First, it reduces the problem of specifying a large number of rights necessary in a collaborative system. Second, in a complex system, it is more likely that users may specify conflicting access definitions because they have to specify, often dynamically, a large number of access rights. The imply relationship can be used by the system to detect some of these conflicts automatically. For example, if a write right is to be granted to a user who has been previously denied the read right explicitly, the system can detect the conflict because the negative read right implies the negative write right. We have identified several useful imply relationships among the access rights we support. Previous work has defined imply relationships among ReadR, WriteR, InsertR, and DeleteR as follows: WriteR implies InsertR; InsertR implies ReadR; and DeleteR implies ReadR. We have identified several additional relationships: —UpdateR implies WriteR because a user cannot update an active variable without writing to the associated interaction variable. —HideR, ElideR implies SelectR because users have to select an object before they can elide or hide it. —Modify SessionR implies CreateSessionR, DeleteSessionR, RemoveParticipantR because the modify operation allows all of the implied operations. —CreateSessionR, DeleteSessionR, JoinSessionR, RemoveParticipantR implies ReadSessionR because we allow users to look at the session information before they invoke the above operations. —TransmitIncrementR implies TransmitCompleteR, TransmitPeriodR, TransmitTimeR, TransmitTransmitR: The right to transmit ACM Transactions on Computer-Human Interaction, Vol. 5, No. 1, March 1998.

56

•


Fig. 5.

Conflict of imply and include.

incremental changes implies the right to send changes on completion, periodically, after a certain time, or on explicit invocation of a special transmit command, since the set of incremental changes includes all the other kinds of changes. At a more abstract level, the right to collaborate synchronously implies the right to collaborate asynchronously. —TransmitRawR implies TransmitParsedR implies TransmitValidateR implies TransmitCommittedR because if users can transmit arbitrary raw changes to a variable, they can certainly transmit changes that are syntactically correct. Likewise, if they can transmit syntactically correct changes, they can certainly transmit the semantically correct changes, which must be syntactically correct. Finally, if they can transmit semantically correct changes, they can transmit the committed changes, which must be semantically correct.2 At a more abstract level, the right to transmit information that has not been checked according to some correctness criterion implies the right to send information that has been checked. Shen’s dissertation [Shen 1994] lists all the imply relationships supported in our model. Conflict Resolution. Supporting both the include and imply relationships allows an access right to be inferred from multiple sources. To illustrate, assume that a new user, abc, joins the software development session and is not familiar with the application. To ensure security, hhs gives abc the right to insert lines (positive InsertR) into a function just created, but denies the data rights (negative DataR) on the function so that abc cannot delete or modify the existing text of the function. We have a conflict, since the negative ReadR can be inferred from the first definition while the positive ReadR from the latter (Figure 5). In such situa2 The observations on these operations are borrowed from the work on flexible coupling [Dewan and Choudhary 1995].



•

57

tions, the imply relationship is given precedence. This is because imply relationships are defined over the individual rights and exist even if right groups are not defined. From another perspective, right groups can be regarded as mere macro conventions. Moreover, the imply relationship is supported for both easy specification and right consistency, while the include relationship is supported only for easy specification. Thus, rights are more tightly related by the imply relationship than the include relationship. Therefore, in the scenario above, the imply relation is used to grant abc the read right. The following conflict resolution rule summarizes the above discussion: Right Conflict Resolution Rule. The imply relationship is used in preference to the include relationship in case of conflicts. 4.8 Two-Dimensional Inheritance In the sections above, we have described multiple inheritances in the object and access right dimensions, which raises the question: in what order are the inheritances in the two dimensions used when resolving a right? Conceptually, we can reduce two-dimensional inheritance to a singledimensional inheritance by treating one dimension as a subdimension of nodes in the other dimension. This is analogous to reducing a twodimensional array to a single-dimensional array of single-dimensional arrays. For example, we can view two-dimensional inheritance within the framework of object inheritance. To decide the value of (s,o,r), we first find o and check whether it is possible to infer the value of (s,o,r) from the access control list associated with o, by using inheritance in the right dimension if necessary. If not, we proceed by using inheritance in the object dimension. Thus, we regard the object dimension as the prime dimension and the right dimension as a subdimension. 4.9 Programming Interface and Extensibility In previous sections, we have discussed the semantics and specification of access control from the end-user’s point of view. In this section, we discuss the specification from the programmer’s point of view by describing how programmers of a particular application can implement various aspects of our access control model. We have extended the Suite framework with primitives for granting, removing, and checking a right to a protected object and for adding and deleting new rights; and we have extended it with the include and imply relationships. These primitives allow application programmers to tailor the access control model, to various degrees, according to the access needs of individual applications. The simplest approach, which we also expect to be the most common one, is for a programmer to set the predefined access rights for an application using the Suite calls Dm_GrantRight and Dm_RemoveRight. These calls can be used to program any of the access control scenarios described so far. ACM Transactions on Computer-Human Interaction, Vol. 5, No. 1, March 1998.

58

•


Programmers can also define new, application-specific, rights. To illustrate, consider the software development application. Assume that we want to add a new right, CheckSpellingR, for an application-defined spellingcheck operation. The application can use Dm_AddRight to create this right, Dm_AddInclude to add the rule “DataR includes CheckSpellingR,” Dm_AddImply to add the rules “WriteR implies CheckSpellingR,” and “CheckSpellingR implies ReadR,” and invoke Dm_ CheckRight to ensure that a subject invoking the spelling-check operation has the appropriate authority. The CheckSpellingR right, thus, becomes an integral part of the right inference space. Therefore, when the right is checked at the beginning of the spelling-check operation, the system will automatically use the inference function to derive its value. However, there are situations when the access needs of applications cannot be met by the mechanism described so far. To illustrate, let us assume that a code-reviewing process cannot begin until the chairman and the author put their signatures in the signature fields; and the author can sign only after the chairman has signed. These requirements cannot be represented by our model directly, since the input parameters deciding the access rights contain elements not considered by our model such as the contents of the object being accessed. As another example, consider situations in which controlling of access is related to the real time. Assume that users can access an object only during a certain time period, say, working hours in weekdays. This requirement also cannot be directly specified by the specification model we have described. To meet such access needs, we support the notion of access guards. If the access requirement of a right R of an object O cannot be completely represented by the access model directly, the programmer can use the Dm_SetCallback primitive to indicate that an access guard is associated with the right R of the object. The guard, written in some conventional programming languages such as C, is a callback that defines applicationspecific access requirements of right R of object O. When the access right R for object O needs to be checked, the system first determines if a positive right can be inferred using its built-in inference function. If it cannot be inferred, then it denies access. Otherwise, it calls the associated callback and uses the return value as the access right. To illustrate its use, consider again the software inspection scenario given above. Assume that Signature1 and Signature2 are the objects on which the chairman and author put their signatures respectively; the chairman is granted a positive WriteR to Signature1; and the author is granted a positive WriteR to Signature2. To represent the requirement that the author can sign only after the chairman signs, the programmer associates an access callback, check_signature2, with WriteR of Signature2, which is called whenever the write right of this object is checked. The callback returns a positive right only if the Signature1 object is signed. We have defined access callbacks as first-class attributes of protected objects that can be themselves inherited. A callback will be invoked ACM Transactions on Computer-Human Interaction, Vol. 5, No. 1, March 1998.


•

59

whenever the associated value is needed by the inheritance algorithm. Thus, although the above callback is defined only for WriteR, it will be invoked whenever an imply relationship needs to access its value. As a result, the performance of the model can suffer because of frequent invocations of a callback, specially if these invocations are from remote workstations. To address this problem, we use the following “cache and hint” approach. Caches are maintained for return values of access callbacks and are associated with “hints” that indicate whether these values should, in fact, be cached. An application can use the Dm_SetHint and Dm_ResetHint primitives to manipulate these hints. These primitives indicate whether a specific value for a triple (Subj, Obj, Right) evaluated by a callback should be cached in the local workstation. If the value is cached in the local workstation, then the callback does not need to be invoked when the value of the triple is needed. Dm_SetHint turns caching on for a specific triple while Dm_ResetHint turns it off and discards the cached value. By default, caching is turned off, since the system does not know a priori when caching is safe.

5. DISCUSSION In this article, we have given several scenarios to illustrate the usefulness of supporting access control in multiuser interfaces, identified accesscontrol principles to be used in the design of such interfaces, and presented a framework based on these principles. The framework has several novel components including a set of protected user interface objects, a generic set of interaction and coupling rights, inheritance in the right dimension based on the include and imply relationships, inheritance in the object dimension based on both type and structural information, methods of resolving inheritance conflicts, and a set of programming primitives that allow application programmers to develop their own protection subsystems. While our access control framework was designed for the Suite collaboration environment, several aspects of it can be applied to other environments. Active and interaction variables correspond to models and views, respectively, in Smalltalk MVC [Krasner and Pope 1988]. Hence the idea of protecting these objects can be applied to the numerous user interface tools based on MVC. Protected structured variables and structural inheritance can be supported in editors of structured data such as programs, outlines, documents, and forms, while type inheritance can be applied to any application displaying multiple classes of objects. Include and imply relationships are useful in any user interface offering a large number of commands; but some of the specific relationships we have identified, especially the ones among coupling operations, are very Suite specific in that other systems tend to be either purely synchronous or purely asynchronous and thus do not support these operations. Finally, our programming primitives can be applied to callback-based systems. The exact details ACM Transactions on Computer-Human Interaction, Vol. 5, No. 1, March 1998.

60

•

Prasun Dewan and Honghai Shen Table I.

Lines of Access Control Code (comments excluded) size of access code

Grove-like outline editor Two-person talk Mail Programming contest Forensics library

1 7 3 7 27

of how these concepts can be worked into other user interface tools is a subject of future research. Our experience with our framework is that it is extremely flexible: it has been used to simulate most of the existing access control models and has proved sufficient to meet the access control requirements of the multiuser applications we have developed. Moreover, it is high level in that few access specifications were needed to express the policies we implemented and the models we simulated. Table I gives the number of lines of access control code in some of the applications we developed. The forensics library application is outlined in Dewan et al. [1995], while the exact code in the other applications and the simulations of other models are given in Shen’s dissertation [Shen 1994]. However, we have found that it is easy to make mistakes, especially when multiple access specifications are inherited by an object. This problem would have been reduced had we developed a graphical tool for viewing the current set of access specifications, discovering conflicts among them, and identifying the paths along which a specification may be inherited. In the absence of such a tool, we have found that it is more productive to use fewer inheritance dimensions even though that typically results in more access specifications. The exact dimensions to be used depends on the application, e.g., for objects with deep structures, structure inheritance is typically more useful, while for applications that create a diverse set of objects, type inheritance is usually more effective. We have found the ability to use any of several inheritance dimensions very useful. Another important usability criterion is the performance of the system. In an inheritance-based system, performance of access control depends on the speed of the workstation that evaluates the access rights and the complexity of access requests. Table II gives the performance data when we varied the above factors to evaluate the model. As the table shows, computing access definitions from multiple inheritances is not a CPUbound operation. The increase of time in the worst case, in our experiments, is about six milliseconds, which is not perceptible to end-users [MacKenzie and Ware 1993]. Further applications need to be developed to test the usability and performance of the model. Distributed software architectures for access control is another area that needs further research. Because collaborators are distributed, access checking can be replicated or centralized. This issue is related to the overall system architecture for collaboration, which can be ACM Transactions on Computer-Human Interaction, Vol. 5, No. 1, March 1998.

Controlling Access in Multiuser Interfaces Table II.

•

61

The Time Needed (in milliseconds) to Evaluate an Access Right

Without inheritance simple right inheritance simple object inheritance 2 dimensional inheritance

AIX/IBM-RS6000

SunOS/Sun-Sparc4

0.6 0.6 0.7 4.1

1.0 1.0 1.4 5.6

centralized, replicated, or hybrid [Dewan 1995]. It would also be useful to integrate access control with transaction management. For instance, as one of the reviewers pointed out, users with authority to cut but not paste may be disappointed if they were able to cut an object but not paste it. While it may be satisfactory, in this particular case, to make the cut right imply the paste right, in general transaction management would be required to ensure atomicity of arbitrary sequences of actions. It would also be useful if the security of our model were proved formally. Finally, access control addresses only one aspect of a secure system. It would be useful to combine our work with advances in other related areas such as cryptographic control and user authentication. It is not until then that we can provide a general solution for a secure collaborative environment.

ACKNOWLEDGMENTS

Bill Gorman, Tim Korb, Michal Young, and the referees helped improve the presentation of these ideas. REFERENCES ATKINSON, M. P. AND BUNEMAN, O. P. 1987. Types and persistence in database programming languages. ACM Comput. Surv. 19, 2 (June). DEWAN, P. 1991. An inheritance model for supporting flexible displays of data structures. Soft. Pract. Exper. 21, 7 (July), 719 –738. DEWAN, P. 1995. Multiuser architectures. In Proceedings of IFIP WG2.7 Working Conference on Engineering for Human-Computer Communication. 43–70. DEWAN, P. AND CHOUDHARY, R. 1992. A high-level and flexible framework for implementing multiuser user interfaces. ACM Trans. Inf. Syst. 10, 4 (Oct.), 345–380. DEWAN, P. AND CHOUDHARY, R. 1995. Coupling the user interfaces of a multiuser program. ACM Trans. Comput. Hum. Interact. 2, 1 (Mar.), 1–39. DEWAN, P. AND RIEDL, J. 1993. Toward computer-supported concurrent software engineering. IEEE Comput. 26, 1 (Jan.), 17–27. DEWAN, P. AND SOLOMON, M. 1990. An approach to support automatic generation of user interfaces. ACM Trans. Program. Lang. Syst. 12, 4 (Oct.), 566 – 609. DEWAN, P., JEFFAY, K., SMITH, F. D., SMITH, J. B., STOTTS, D., AND OLIVER, W. 1995. Early prototypes of the repository for patterned injury data. In Proceedings of Digital Libraries ’95. 123–130. EDWARDS, K. 1995. Coordination infrastructure in collaborative systems. Ph.D. thesis, Dept. of Computer Science, Georgia Technical Univ., Atlanta, Ga. ELLIS, C. A., GIBBS, S. J., AND REIN, G. L. 1989. Design and use of a group editor. In Proceedings of IFIP WG 2.7 Working Conference on Engineering for Human-Computer Interaction. 13–28. ACM Transactions on Computer-Human Interaction, Vol. 5, No. 1, March 1998.

62

•


FERNANDEZ, E. B., SUMMERS, R. C., AND LANG, T. 1975. Definition and evaluation of access rules in data management systems. In Proceedings of the 1st International Conference on VLDB. VLDB Endowment Press. 268 –285. GRAHAM, G. AND DENNING, P. 1972. Protection—Principles and practice. In Proceedings of the Spring Joint Computer Conference. Vol. 40. 417– 429. KRASNER, G. E. AND POPE, S. T. 1988. A cookbook for using the model-view-controller user interface paradigm in Smalltalk-80. J. Obj. Oriented Program, 1, 3, 26 – 49. LAMPSON, B. 1971. Protection, In Proceedings of the 5th Princeton Symposium of Information, Science and Systems. 437– 443. Reprinted in ACM Oper. Syst. Rev. 8, 1, 18 –24. MACKENZIE, I. S. AND WARE, C. 1993. Lag as a determinant of human performance in interactive systems. In Human Factors in Computing Systems, INTERCHI’93 Conference Proceedings. 488 – 493. RABITTI, F., BERTINO, E., KIM, W., AND WOELK, D. 1991. A model of authorization for next-generation database systems. ACM TODS Trans. Database Syst. 1, 16 (Mar.), 88 –131. ROSEMAN, M. AND GREENBERG, S. 1996. Building real-time groupware with groupkit, groupware toolkit. ACM Trans. Comput. Hum. Interact. 3, 1, 66 –106. SALTZER, J. 1974. Protection and the control of information sharing in multics. Commun. ACM 17, 7 (July), 388 – 402. SHEN, H. 1994. Access control for collaborative environments. Ph.D. thesis, Dept. of Computer Science, Purdue Univ., W. Lafayette, Ind. SHEN, H. AND DEWAN, P. 1992. Access control for collaborative systems. In Proceedings of the ACM Conference on CSCW. ACM, New York, 51–58. STEFIK, M., FOSTER, G., BOBROW, D. G., KAHN, K., LANNING, S., AND SUCHMAN, L. 1987. Beyond the chalkboard: Computer support for collaboration and problem solving in meetings. Commun. ACM 30, 1 (Jan.), 32– 47. TREVOR, J., RODDEN, T., AND MARIANI, J. 1994. The use of adapters to support cooperative sharing. In Proceedings of the ACM Conference on Computer-Supported Cooperative Work. ACM, New York, 219 –230. Received June 1996; accepted January 1998


Controlling Access in Multiuser Interfaces - Dan R. Olsen Jr

Controlling Access in Multiuser Interfaces - Dan R. Olsen Jr

Suggest Documents

Time Warp Football - Dan R. Olsen Jr.

Light Widgets: Interacting in Every day Spaces - Dan R. Olsen Jr.

Issues in Building Multiuser Interfaces - CiteSeerX

Walter S. Judd James Dan Skean, Jr. Eldis R ...

Walter S. Judd James Dan Skean, Jr. Eldis R ... - MAFIADOC.COM

WYSIWIS Revised: Early Experiences with Multiuser Interfaces

Neural machine interfaces for controlling

Olsen-Falch Access Pricing Denmark - CiteSeerX

Olsen-Falch Access Pricing Denmark - CiteSeerX

JR Lucey." R. GuzmÃ¡n,"

JUssI aDler-OlseN JUssI aDler-OlseN JUssI aDler-OlseN JUssI ...

Sen. Ferdinand R. Marcos, Jr.

NOVEL INTERFACES FOR CONTROLLING SOUND ... - CiteSeerX

Neural machine interfaces for controlling ... - Semantic Scholar

Weintek interfaces for controlling the position

Lance Olsen

Monitoring and Controlling Content Access in KAD

Coupling the User Interfaces of a Multiuser Program - CiteSeerX

Coupling the User Interfaces of a Multiuser Program - CiteSeerX

Multiuser Transmission in Code Division Multiple Access ... - Qucosa

On the Multiuser Diversity in SIMO Interfering Multiple Access Channels

Stable Multiuser Channel Allocations in Opportunistic Spectrum Access

Uplink Spectral Efficiency Analysis of Decoupled Access in Multiuser

David R. Hawkins - Robert JR Graham