Access Control Model for Groupware Applications - Semantic Scholar

Submitted to HCI’95: People and Computer Huddersfield University − UK 30 August 1995

Access Control Model for Groupware Applications Rushed Kanawati*, Michel Riveill** *Bull−IMAG Systèmes − 2 Rue de Vignate F−38610 Gières ** Université de Savoie − L.G.I.S F−73376 Le bourget du Lac E−mail: {Rushed.Kanawati,Michel.Riveill}@imag.fr

Abstract: Groupware applications introduce new requirements in terms of access control that are not adequately handled by access control models developed for non collaborative applications. The central presence of humans in the context of collaborative applications adds additional constraints on the access model and data protection mechanism to be used. In this paper, we propose a hierarchy−based general data access model that we believe answers the needs of collaboration.

1 Introduction Users of groupware application share a common information space, the collaboration space, in which they share also the results of their actions. This space is divided into two sub−spaces: • The production space: This is the set of shared artifacts that form the subject of the collaboration process (e.g. the set of shared documents in a co−authoring system). •

The communication space: This is the set of available communication channels (i.e audio/video links) which enable users to comment on their actions undertaken in the production space. Different users should have different access rights that suit their current status and their current tasks. Two levels of access right evaluation are distinguished: the role level (or social access rights) and the system level (Figure 1). In order to access an object in the collaboration space the user should first have a role that allows him to

2

Access Control Model for Groupware Applications

do so, secondly, the effective access is controlled by the system itself in function of the resource availability and the concurrency management protocols.

Customize Communication Space

Roles

Concurency Control

Actions

Awareness

Users

Role Level

System Level

Production Space

Collaboration Space

Fig. 1: Shared data access cycle In this study, we address the question of specifying users roles over the production space. Many works have studied the problem of groupware access requirements, however few of them have addressed the problem of readily expressing these rights. We seek to provide a flexible, dynamic fine−grained and easy to user role attribution mechanism. This goal lead us to define several hierarchical schemes over the three dimensions of an access control rule: the subject, the object and the requested rights. Rights not explicitly declared can be inferred by applying an evaluation function that exploits the defined hierarchies. The reminder of this paper is organized as follows: next in section 2 we list the identified groupware access requirements. In Section 3, we describe the proposed access model as well as the access evaluation function. In section 4, we make a quick glance at some related works. Finally, we conclude in section 4.

2 Groupware access requirements Analyzing the requirements of different collaborative applications, and consulting the scientific literature [2][5][9], the following requirements are identified: 1. A user’s access rights should be defined as a function of the users social role. A user may have different roles and he should be allowed to act as the sum of these roles. 2. Users roles evolve dynamically. Users acquire roles as the work progresses.

3

3. A related point is the introduction of the task concept [3]. A task is a group of objects and users. Users are provided with access rights that are inferred from their roles and the task requirements. 4. Users should be able to delegate and withdraw rights they have to and from other people according to the progress of the work and according to their trust in these people. 5. Because people will be frequently need to change their and others access rights, the system should provide a set of comprehensible and easy to use set of primitives which help them to do so. 6. Collaboration activities introduce a new kinds of access rights that are not required in classical systems. These are the access rights that describe the degree of collaboration or the view coupling between the different users [1].

3 A Hierarchy−based access control model 3.1 Definitions The basic entity in our model is the role object. A role object is composed of a set of access rules which have the following form: ri = ({+/−}, O, A). The leading sign in an access rule determines whether the right A granted over O is positive or negative. Negative rights are introduced in order to ease access right specification [9]. O can be an individual object or a group of objects. An access right A is expressed in terms of generic operations allowed on the shared objects [4]. Generic operations allow to specify access rights independently of the used applications. A matching function should, however, provided in order to match generic operations to specific operations defined on the objects. Three basic groups of generic access rights are required: • • •

Manipulation rights such as write, read, modify rights. Collaboration rights such as view coupling rights. Administration rights such as the right to specify others access rights on the object. Two types of role objects are distinguished: • Abstract role: which describes the set of access rights associated with a given position in the community, without considering the human user that

4


occupies this position. Student and teacher roles are examples of abstract roles in an university community. • User role: which specifies the set of access rights granted to a given human user. The set of abstract roles form what we call the organization model, while the set of user roles form the user model. A hierarchical structure is defined over the organization model. This gives the organization model a structure of a direct acyclic graph (DAG). The user model has a flat structure. Each user role object is linked to one or more abstract roles by an extension of the hierarchy defined over the organization model. Figure 2 illustrates an example of both models. Access rights can be expressed for individual objects or object groups. Several grouping criteria can be used. The choice of these criteria is application dependent. The set of object groups that are based on the same grouping criterion forms a family. A hierarchical structure is defined over each family. Obviously, an object may belong to several families simultaneously. Organization Model All IS-A

Teacher

Student

PhD

Auxiliary

Ms

Main

Class1

General Examination Board CourseX Teachers

Class1 CourseX Ex. Board

Rushed

Roland

Course X Examination Board

Michel

User Model

Fig. 2: An example of the organization and the user models

3.2 Access control mechanism construction First, the organization model needs to be constructed. The groupware programmer is responsible for providing a first version of this model which can be updated later by a special user: the groupware administrator. Constructing the organization model requires the identification of the different required abstract roles as well

5

as their hierarchical structures and the definition of the different families of shared objects. When a new human user is introduced, the administrator creates for him a new user role object. This new role should be connected to at least one abstract role. Three basic operations can be used by a user in order to alter other rights on objects he administrates (particularly on objects he creates). These operations are: • Delegate (RRs,RRr,O,+A): This enables the user RRs to delegate the right A on the object or the object group O to the user role RRr. Only positive rights can be delegated. Administration rights can not be delegated. Consequently, the delegate can not delegate further delegated rights. Furthermore, if the delegator loose rights he delegated, delegates will automatically loose these rights also. • Withdraw (RRs,RRr,O,A):This allow to withdraw delegated rights. • Grant (RRs,RRr,O,[+/−]A): The granted right A can be positive or negative. The RRr role can be an abstract or a user role. In the later case all the user roles connected directly or not to the involved abstract role will be updated but not the abstract role itself. Updating abstract roles can only be done by the administrator. A user should have the suitable administration right in order to perform the grant operation.

3.3 Access rules evaluation Each user is associated with one user role. A user role is defined by the access rules it contains and by the set of adjacent abstract roles. A DAG, that we call the access−right DAG (AC/DAG) is constructed by climbing up the links that relate the user role to the organization model. Figure 3, illustrates the AC/DAG of the user Roland from the organization illustrated in figure 2. 3 Class1 CourseX Ex. Board

4

5

6

Class1 Teacher

Main Teacher

Teacher

2 CourseX Examination Board Roland

1 General Examination Board

Fig. 3: The AC/DAG of the user Roland The general idea of the evaluation algorithm is to evaluate a requested right in terms of the rules contained in the user role. If the requested right can not be

6


explicitly confirmed or rejected the evaluation function searches the answer by exploring the user AC/DAG. A complete description of the evaluation procedure needs to specify two things: • How rules inside a role are evaluated. • How the AC/DAG is explored. In order to avoid rules conflicts inside a role we use the following conflict resolution rules: the rule defined for the most specific group (in terms of the defined hierarchy) overcomes the others. A depth first exploration scheme is applied when exploring the AC/DAG. This sorts the roles attributed to a user in decreasing priority from left to right. For the example the AC/DAG illustrated in figure 3 is searched in the following order (1,5,6,2,4,3). Two cases are to be distinguished: the user is working alone on the collaboration space, or he makes part of a task. In the first case, an optimistic strategy explores the whole AC/DAG until finding a positive answer while a pessimistic one stops on the first negative answer. Within a task the context is different. Participating in a task requires having certain abstract role. For example, only members of a university examination board can participate in an examination board meeting. The order of the user roles is then changed in a way that gives the highest priority to the participation role.

4 Related Work Almost all available groupware applications provide all users with the same access rights. However, it is obvious that collaborative tasks require different users to have different access control rights. Few works have addressed this question. Some specific applications, particularly co−authoring systems, supports specific role attribution mechanisms [8]. The Suite collaboration toolkit [9] provides a generic access control model that share a lot of features presented by our model. However it lacks the task concept and the abstract role one. Besides, it implements access roles in the form of access control lists rather than capabilities which we propose. We believe that the use of capabilities is more natural in the context of groupware applications where the human user is at the center of the application and where the access rights should be driven from his status rather than the object one. A task centered approach is adopted in [4]. Roles are task related. Objects manipulated in the context of a task are grouped according to the identity of the role that created the object. Each task is associated with security templet which is a sort of an access matrix that specify, in terms of generic operations, what operations a role R can performs on objects created

7

by other roles. This model supports user initiated tasks but not data initiated ones. We believe that both approaches for task creation are required.

5 Conclusion This paper addresses the problem of defining a generic role attribution mechanism for groupware applications. Such a mechanism should be flexible, dynamic, fine−grained and easy to use. In order to answer these objectives, we propose a model that is based on defining hierarchical schemes over the three dimensions involved in an access control rule: the subject, the object and the requested rights. Positive and negative rights can be specified. An inference function is provided in order to deduce rights not explicitly declared. Until now, we have considered a centralized implementation of this model. However, the examination of a full replicated implementation is planned. Another interesting problem is the identification of the nature of relationship that may exist between the role model and the concurrency management module. Acknowledgements We would like thank Jean Dollimore and George Coulouris at Queen Mary and Westfield College for their valuable comments on the structure and the ideas discussed in this paper.

Bibliography

[1]

R. Bentely, T. Rodden, P. Sawyer, I. Sommerville, Architectural Support for Cooperative Multi−User Interfaces, CSCW’90, 1990.

[2]

G. Coulouris, J. Dollimore, A Security Model for Cooperative Work, ACM SIGOPS Workshop, ACM, Dagstuhl, September 1994.

[3]

G. Coulouris, J. Dollimore, Requirements for Security in Cooperative Work: Two Case Studies, (TR 671), Queen Mary & Westfield College, University of London, Mile End Road London E1 4NS, May 1994.

[4]

G. Coulouris, J. Dollimore, Protection of Shared Objects for Cooperative Work, (internal note), Queen Mary & Westfield college, Mile End Road London E1 4NS, Janurary 1995.

[5]

P. Dewan, R. Choudhary, Flexible User Interface Coupling in a Collaborative System, Proceedings of CHI’92 conference on human factors in computing systems, ACM, CA, 1992.

[6]

S. Greenberg, D. Marwood, Real Time Groupware as a Distributed System: Concurrency Control and its Effect on the Interface, CSCW’94, ACM, Chapel Hill, NC, October 1994.

[7]

B. W. Lampson, Protection, ACM Operating System Review, 8(1), pp. 18, 1974.

[8]

D. Nastos, A Structured Environment for Collaborative Writing, Master of science thesis, University of Toronto, 1992.

[9]

H. Shen, P. Dewan, Access Control for Collaborative Environments, CSCW’92, pp. 51, ACM, Toronto Canada, November 1992.


1 Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1

2 Groupware access requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 A Hierarchy−based access control model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1 Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2 Access control mechanism construction . . . . . . . . . . . . . . . . . . . . . . . . . 3.3 Access rules evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2 3 3 4 5

4 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6 7

i