<%BANNER%>

Access control model for distributed conferencing system

University of Florida Institutional Repository

PAGE 1

A CCESS CONTR OL MODEL F OR DISTRIBUTED CONFERENCING SYSTEM By VIJA Y MANIAN A THESIS PRESENTED TO THE GRADUA TE SCHOOL OF THE UNIVERSITY OF FLORID A IN P AR TIAL FULFILLMENT OF THE REQUIREMENTS F OR THE DEGREE OF MASTER OF SCIENCE UNIVERSITY OF FLORID A 2002

PAGE 2

A CKNO WLEDGMENTS I w ould lik e to thank Dr.Newman for getting me started on this pro ject. I w ould lik e to express m y gratitude to Dr.Thebaut for his willingness to help me whenev er I had a problem. I w ould also lik e to thank all the DCS group mem b ers, past and presen t, for their in v aluable con tributions without whic h I w ould not ha v e b een able to complete this thesis. Sp ecial thanks are due to m y paren ts and m y friends for their supp ort and encouragemen t. ii

PAGE 3

T ABLE OF CONTENTS page A CKNO WLEDGMENTS . . . . . . . . . . . . . . ii ABSTRA CT . . . . . . . . . . . . . . . . . . vi CHAPTERS 1 INTR ODUCTION . . . . . . . . . . . . . . . 1 1.1 Ov erview . . . . . . . . . . . . . . . . 1 1.2 Defnitions . . . . . . . . . . . . . . . 1 1.3 Problem Statemen t . . . . . . . . . . . . . 3 1.4 The Distributed Conferencing System . . . . . . . . 4 1.5 Thesis Organization . . . . . . . . . . . . . 7 2 SUR VEY OF RELEV ANT W ORK . . . . . . . . . . 9 2.1 In tro duction . . . . . . . . . . . . . . . 9 2.2 Access Matrix Mo del . . . . . . . . . . . . 10 2.2.1 Description . . . . . . . . . . . . . 10 2.2.2 Harrison-Ruzzo-Ullman Result . . . . . . . . 11 2.2.3 T yp ed Access Matrix . . . . . . . . . . 12 2.2.4 Mo difcations on A CM . . . . . . . . . . 13 2.2.5 Commen ts . . . . . . . . . . . . . 13 2.3 ADMIRAL Mo del . . . . . . . . . . . . . 14 2.3.1 In tro duction . . . . . . . . . . . . . 14 2.3.2 Description . . . . . . . . . . . . . 14 2.3.3 Commen ts . . . . . . . . . . . . . 15 2.4 OSF Distributed Computing En vironmen t . . . . . . 16 2.4.1 In tro duction . . . . . . . . . . . . . 16 2.4.2 Description . . . . . . . . . . . . . 16 2.4.3 Commen ts . . . . . . . . . . . . . 18 2.5 Role-Based Access Con trol . . . . . . . . . . . 18 2.5.1 In tro duction . . . . . . . . . . . . . 18 2.5.2 Description . . . . . . . . . . . . . 19 2.5.3 Commen ts . . . . . . . . . . . . . 20 2.6 Access Con trol in UNIX Op erating System . . . . . . 20 2.6.1 In tro duction . . . . . . . . . . . . . 20 2.6.2 Description . . . . . . . . . . . . . 20 iii

PAGE 4

2.6.3 Commen ts . . . . . . . . . . . . . 22 2.7 Distributed Compartmen t Mo del . . . . . . . . . 22 2.7.1 In tro duction . . . . . . . . . . . . . 22 2.7.2 Description . . . . . . . . . . . . . 23 2.7.3 Commen ts . . . . . . . . . . . . . 24 3 REQUIREMENTS . . . . . . . . . . . . . . . 26 3.1 In tro duction . . . . . . . . . . . . . . . 26 3.2 The Pro cess . . . . . . . . . . . . . . . 26 3.3 A Sample Scenario . . . . . . . . . . . . . 27 3.4 Requiremen ts of the A CS . . . . . . . . . . . 29 3.5 In teractions with other DCS services . . . . . . . . 31 3.5.1 Database Services . . . . . . . . . . . 31 3.5.2 Conference Con trol Services . . . . . . . . 32 3.5.3 Decision Supp ort Services . . . . . . . . . 32 3.6 In teresting Issues . . . . . . . . . . . . . 33 3.6.1 Admin role . . . . . . . . . . . . . 33 3.6.2 Mo difying the A CT . . . . . . . . . . . 33 3.6.3 Separation of Dut y . . . . . . . . . . . 33 3.7 Summary . . . . . . . . . . . . . . . 34 4 DESIGN . . . . . . . . . . . . . . . . . . 35 4.1 In tro duction . . . . . . . . . . . . . . . 35 4.2 F ormal Sp ecifcation of A CS Mo del . . . . . . . . 35 4.3 Database T able Sc hema . . . . . . . . . . . . 37 4.3.1 Access Con trol T able . . . . . . . . . . 37 4.3.2 Other T ables . . . . . . . . . . . . . 39 4.4 DCS-defned Ob ject t yp es and Access t yp es . . . . . . 40 4.5 Chec k-Access F unction . . . . . . . . . . . . 40 4.6 In teractions with other Mo dules . . . . . . . . . 41 4.6.1 Conference Con trol Services . . . . . . . . 41 4.6.2 Database Services . . . . . . . . . . . 42 4.6.3 Decision Supp ort Services . . . . . . . . . 42 4.7 Alternate Design . . . . . . . . . . . . . 42 4.7.1 Views . . . . . . . . . . . . . . . 43 5 IMPLEMENT A TION AND TESTING . . . . . . . . . 45 5.1 Implemen tation of A CS . . . . . . . . . . . . 46 5.1.1 Conference Con trol Services . . . . . . . . 48 5.1.2 Database Services . . . . . . . . . . . 48 5.1.3 Decision Supp ort Services . . . . . . . . . 49 5.2 T esting . . . . . . . . . . . . . . . . 49 5.2.1 Unit T esting . . . . . . . . . . . . . 50 5.2.2 In tegration T esting . . . . . . . . . . . 51 iv

PAGE 5

6 CONCLUSION . . . . . . . . . . . . . . . . 53 REFERENCES . . . . . . . . . . . . . . . . . 55 BIOGRAPHICAL SKETCH . . . . . . . . . . . . . . 57 v

PAGE 6

Abstract of Thesis Presen ted to the Graduate Sc ho ol of the Univ ersit y of Florida in P artial F ulfllmen t of the Requiremen ts for the Degree of Master of Science A CCESS CONTR OL MODEL F OR DISTRIBUTED CONFERENCING SYSTEM By Vija y Manian Decem b er 2002 Chair: Ric hard E. Newman Ma jor Departmen t: Computer and Information Science and Engineering In to da y's w orld, high-sp eed net w orks ha v e made geographical distances meaningless and Small Oce Home Oce (SOHO) is more than the latest buzzw ord. The Distributed Conferencing System (DCS) is designed to supp ort distributed co op erativ e w ork b y pro viding an infrastructure that allo ws the users to share ob jects, run common applications, exc hange v oice and video and view eac h other's screens. Running collab oration-a w are applications on suc h a system pro vides the users with b etter to ols for collab orativ e w ork. In suc h a system, access con trol using the traditional mo dels is ineectiv e. A p opular mo del is the Access Con trol Matrix (A CM), whic h uses a t w o-dimensional matrix with the activ e sub jects corresp onding to the ro ws and the passiv e ob jects corresp onding to the columns. Eac h cell indicates the t yp es of access p ermissible for that sub ject on that ob ject. Usually the answ er to an access request is an immediate y es or no. The A CM is often v ery large to main tain and is compressed b y grouping sub jects in to domains or roles and ob jects in to ob ject t yp es. P opular vi

PAGE 7

op erating systems lik e UNIX restrict the set of p ossible accesses and allo w only read, write and execute accesses. Using this mo del in a distributed en vironmen t imp oses sev eral limitations on the system. The scop e of this w ork is to extend this mo del to b etter suit the requiremen ts of DCS. First, eac h en try in the A CM also includes a de cision p ointer whic h p oin ts to a decision making template that has to b e pro cessed to arriv e at a decision. This mo dels real-life scenarios more closely in whic h some accesses are p ermissible if certain conditions are met. These templates are main tained b y the Decision Supp ort Service (DSS) of DCS. Ev en tually this system can supp ort pro cess w ork ro w mo del and separation of dut y Secondly w e group users in to r oles and ob jects in to obje ct typ es to compress the matrix. W e also use a distributed database in the bac k-end to store the A CM, resulting in a truly distributed system. Another mo difcation is the notion of sp e cial p ermissions whic h enable us to capture one-to-one relationships b et w een users and ob jects, lik e o wnerships. This thesis is a part of the DCS pro ject and the access con trol mec hanism describ ed is used in DCS v ersion 2.0. The adv an tage here is that it supp orts traditional A CM while pro viding additional decision-making templates. It is hop ed that this extended A CM is used in other systems that require a more demo cratic v oting pro cess. vii

PAGE 8

CHAPTER 1 INTR ODUCTION 1.1 Ov erview Distributed computing is to da y's solution to the need to share data. No one can doubt the need for safe, reliable and ecien t comm unication. Individuals comm unicate to ac hiev e their da y-to-da y desires and requiremen ts. Organizations comm unicate ab out their business goals [1]. The Distributed Conferencing System (DCS) is a distributed pac k age that pro vides an infrastructure for real-time co op erativ e w ork. The conferences ma y b e long-term or short-term and are dynamic in that their constituency ma y c hange o v er time; they ma y also split or merge. Conference con trol is hierarc hically demo cratic, and DCS's arc hitecture is hierarc hically distributed [2 ]. Access to data, programs, and other resources of the system is a serious concern. The securit y mo del used on most distributed systems is an old one, dating bac k to simpler times when most computer systems w ere cen tralized [3]. In suc h systems, there is a cen tralized authorit y that manages access to all ob jects in the system. In op erating systems lik e UNIX [4], the users ha v e only three t yp es of access on an y ob ject namely r e ad, write and exe cute The access con trol mec hanism in DCS is in tended to pro vide a truly distributed solution that supp orts a m uc h wider range of access t yp es. 1.2 Denitions The follo wing terms are used throughout this w ork and it is imp ortan t to b e clear ab out their meanings. In general, they corresp ond to the standard meanings used in the real w orld. 1

PAGE 9

2 User This is an en tit y in the system that initiates action and (in the con text of access con trol) requests to access ob jects. This term usually refers to a h uman b eing. Subje ct This represen ts an activ e user pro cess that is allo w ed to p erform some action within the system on b ehalf of the user. Obje ct This is a passiv e en tit y in the system. Users can p erform v arious accesses on them. Examples of ob jects are do cumen ts, les and DCS system sp ecic tables. Applic ation This is a program that the user launc hes from within the system to w ork on the ob jects. Col lab or ation-war e These are applications that are designed to supp ort collab orativ e w ork. Therefore these applications will ha v e a b etter access con trol features than the regular o-the-shelf applications. DCS-awar e Applic ations These are applications that are sp ecically designed to w ork within the DCS. These applications can use the features of DCS lik e ev en t notication or new access t yp e registration. R ole This is a named group of sub jects. Roles can also b e view ed as a collection of job functions. A particular sub ject can bind to an y n um b er of roles but at an y p oin t of time, the sub ject can b e b ound to only one role. It m ust b e noted that r ole as used here is sligh tly dieren t from r ole as used in Role-based access con trol (refer Section 2.5) b ecause there is no notion of a role-hierarc h y in the DCS mo del. Obje ct T yp e This is a named group of ob jects. A particular ob ject can b elong to only one ob ject t yp e. De cision T emplate Pointer This is a p oin ter to some decision making mec hanism lik e v oting that m ust b e initiated in order to get a result. It m ust b e noted that while the user-role relationship is a man y-to-man y relation, i.e., a user can b elong to man y roles and a role can ha v e man y users, the ob jectob ject t yp e relationship is man y to one. While an y n um b er of ob jects can b elong to one ob ject t yp e, an ob ject can b elong to only one ob ject t yp e. The decision template p oin ter can p oin t to an y t yp e of decision template that has b een dened

PAGE 10

3 earlier. This allo ws the users to sp ecify a template that suits their conference p olicy 1.3 Problem Statemen t A p opular mo del to enforce access con trol is the A c c ess Contr ol Matrix (A CM) The access matrix can b e represen ted as a list of triples, ha ving the form < subje ct, obje ct, rights > In general, the access con trol matrix is sparse and/or redundan t. Searc hing a large n um b er of suc h triples in a sparse matrix is inecien t. Therefore an A c c ess Contr ol List (A CL) asso ciated with eac h ob ject, whic h lists ev ery sub ject or domain allo w ed to use that resource, is normally used [5]. The scop e of this w ork is to extend the idea of access con trol matrices to supp ort the distributed arc hitecture of DCS. The dra wbac ks of the traditional approac h are listed b elo w. 1. In a distributed system, the resources are distributed across the net w ork and it is not p ossible b y traditional w a ys to uniformly con trol access to all resources without ha ving a cen tralized serv er. The regular A CM or A CL dep ends on a cen tralized decision making authorit y This is not in tune with the distributed arc hitecture of the DCS. W e m ust nd a w a y to implemen t the A CM in m ultiple sites and k eep them consisten t with one another. 2. In a system with a large n um b er of sub jects and ob jects, it is m uc h more ecien t to group the sub jects and ob jects. T raditional access con trol mec hanisms do not supp ort suc h group con trol and dep end on individual con trol. 3. A user should b e able to log in to the system from an y site and still p erform all his/her duties. This is not p ossible in normal systems without a cen tralized service p oin t. 4. The A CM do es not allo w the conference mem b ers to decide on access requests. I.e., there is no w a y to add p oin ters to decision-making templates that are activ ated whenev er the concerned access requests are made. This mo dels the real w orld situations more closely; for example, Bob can mo dify the group constitution if t w o-thirds of the mem b ers agree to the amendmen t. Suc h scenarios are v ery common and group decision-making should b e a vital part of access con trol.

PAGE 11

4 5. Although w e dene access righ ts with resp ect to groups of sub jects and ob jects (i.e., roles and ob ject t yp es) it ma y b e necessary to dene more direct relationships lik e ob ject o wnerships. The curren t access con trol mec hanisms either allo w only role based denitions or no roles at all. The core requiremen t is a distributed system that is capable of making access con trol decisions at the individual sites without referring to a cen tral database. The system should also supp ort Role-Based Access Con trol (RBA C) and demo cratic decision-making. In addition, it should resp ond to access con trol queries from other DCS services (refer Section 1.4). Similarly it can mak e use of the v arious services pro vided b y the other mo dules. 1.4 The Distributed Conferencing System DCS pro vides a distributed, real-time conferencing facilit y for co op erativ e w ork. The rst v ersion of DCS, referred to as DCS v.1, had a small set of predened roles and only mem b ers who are b ound to the voter role can v ote. While DCS v.1 came with a set of applications for shared editing of do cumen ts, exp orting user's windo w and discussions among the users, it also supp orted stand-alone o-the-shelf applications [2]. The next v ersion of DCS, referred to as DCS v.2, is a ma jor step from the rst v ersion and supp orts a m uc h wider range of v oting mec hanisms, limited RBA C, sync hronous and async hronous notication, and distributed database services. The arc hitecture of DCS v.2 is sho wn in gure 1.1. A brief description of eac h service is giv en b elo w: 1. C onf er ence C ontr ol S er v ices ( C C S ) This is the mo dule resp onsible for conference and application con trol. This mo dule instan tiates the other mo dules and the clien ts in teract with the other services mainly through the CCS. T asks lik e merging t w o instances of DCS or sites or conferences and splitting of the instance or a site or a conference is handled b y this mo dule. It also supp orts applications b y registering them and main taining the relev an t information. The CCS in teracts with the secure messaging and the cryptographic la y ers during user login. User's access con trol requests are

PAGE 12

5 routed through the CCS. The CCS also allo ws the user to imp ort and exp ort ob ject, add new mem b ers and start sub-conferences. 2. N otif ication S er v ices ( N T F ) The NTF pro vides async hronous ev en t notication to registered users. Users can dene new ev en t t yp es and register to b e notied on ev en ts. The v arious services and applications running in the instance raises ev en ts as and when they o ccur and the NTF main tains a global and lo cal database in whic h is stores the users to b e notied on eac h ev en t along with the deliv ery metho d. 3. D atabase S er v ice ( D B S ) The DBS mak es use of a bac k end Database Managemen t System (DBMS) to main tain the tables of all the DCS services and applications. Most tables are stored as partially replicated distributed databases and the DBS uses group m ulticast to ensure ev en tual consistency among all mem b er sites. 4. Access C ontr ol S er v ices ( AC S ) The A CS, as the name suggests, con trols access to all the ob jects in the conference. It mak es use of decision templates of the DSS to pro vide group decision-based access con trol. This results putting the con trol of the conference in the hands of the conference users. The A CS stores its tables in a database through the DBS. The A CS allo ws applications to register new access t yp es. This allo ws more ne-grain access con trol if the application supp orts it. 5. D ecision S uppor t S er v ice ( D S S ) The DSS main tains the decision templates that are dened for that conference. It allo ws users to dene new templates and also mo dify existing templates. It also executes these templates whenev er required, i.e., it initiates and conducts v otes among the mem b ers and returns the result to who ev er requested the v ote. 6. S ecur e C ommunications S er v ices ( S C S ) The SCS handles all the securit y related issues lik e user authen tication, encryption and decryption of messages, storage and retriev al of k eys etc. Lik e all services, this to o mak es extensiv e use of the DBS to k eep the information in the v arious sites up to date. One imp ortan t asp ect of DCS is the notion of vestibule c onfer enc e This is similar to the lounge and users en ter the site through this conference b efore en tering their conferences. The v estibule conference corresp onds to the site as a whole and the adv an tage with this view is that site managemen t is handled in the same w a y as conference managemen t. Therefore, w e do not need a separate access con trol

PAGE 13

6 mo dule for sites. Most distributed systems ha v e cen tralized authorities for all its services. Ho w ev er, DCS distributes authorit y among the sites. There are a few ma jor dierences b et w een traditional sc hemes and the A CS in DCS. T raditional access con trol sc hemes ha v e the follo wing service cycle: 1. Receiv e request 2. V alidate request 3. Carry out request 4. Send reply Ho w ev er, the use of decision templates in A CS adds an additional step to the cycle and the existence of NTF alters the last step of the cycle. The service cycle of the DCS mo del is as follo ws: 1. Receiv e request 2. V alidate request 3. Authorize request via group decision (async hronous) 4. Carry out request 5. Notify in terested parties. This need not just b e the requester but an y one who is registered to b e notied on the ev en t. In traditional systems that use sync hronous comm unication, resp onse time is an issue to b e considered. Ho w ev er, in DCS, on accoun t of the group decision step, the en tire pro cess is essen tially async hronous and therefore the A CS m ust store the information ab out the request somewhere till it gets a result from the DSS. The A CS in teracts with all the other v e mo dules and pro vides v arious services to the users. The DCS arc hitecture requires the A CS to allo w decisions to b e made on access con trol requests at the source site itself. This coupled with the decision templates mak es the A CS an in teresting study in itself. The mo del

PAGE 14

7 used here is not sp ecifc to DCS and can b e used in an y distributed system that supp orts group decision-making mec hanisms. 1.5 Thesis Organization This thesis is organized as follo ws. Chapter 2 is a surv ey of the relev an t w ork in the feld. Chapter 3 is a description of the requiremen ts for the access con trol mo dule in DCS. Chapter 4 is a description of the design satisfying the requiremen ts of c hapter three that w e dev elop ed. Chapter 5 is a discussion of the v arious implemen tation issues, testing pro cedures, and test results. Chapter 6 concludes the thesis.

PAGE 15

8 NTF ACS DSS CCS Applications Local Database Distr. Database Group MulticastSite Messaging Secure Messaging Crypto RMI TCP UDP JDBCDBMS A A Figure 1.1: Arc hitecture of DCS

PAGE 16

CHAPTER 2 SUR VEY OF RELEV ANT W ORK 2.1 In tro duction This c hapter surv eys some of the w ork in access con trol that is relev an t to the Access Con trol Services (A CS) mo dule of DCS. Protection of ob jects is complex b ecause the n um b er of access p oin ts ma y b e large, there ma y b e no cen tral authorit y through whic h all access requests pass, and the kind of access is not simply limited to read, write, or execute. According to Preeger [6], there are sev eral complemen tary goals in suc h a mec hanism. Che ck every ac c ess W e ma y w an t to rev ok e a user's privilege to access an ob ject. If w e ha v e previously authorized the user to access the ob ject, w e do not necessarily mean the user should retain indenite access to the ob ject. A l low le ast privile ge A sub ject should ha v e access to the smallest n um b er of ob jects necessary to p erform some task. Not allo wing access to unnecessary ob jects guards against securit y w eaknesses if a part of the protection mec hanism should fail. V erify ac c eptable usage The nal decision on an access request is a y es-no decision. Of more in terest is c hec king that the activit y to b e p erformed on an ob ject is appropriate. In the follo wing sections w e lo ok at v arious protection mec hanisms. First w e will consider the Access Matrix mo del. W e also describ e certain mo dications lik e Access Con trol Lists and Capabilit y lists along with the Graham-Denning and Harrison-Ruzzo-Ullman mo dels. Next w e will review the access con trol sc heme in ADMIRAL, a distributed computing based serv er system. Next comes OSF Distributed Computing En vironmen t. W e will then examine the UNIX op erating 9

PAGE 17

10 system. Finally w e will consider the Distributed Compartmen t Mo del for resource managemen t and access con trol prop osed b y Stev en Green w ald. 2.2 Access Matrix Mo del The access matrix mo del is based on an op erating system view of securit y It w as originally describ ed b y Lampson [7]. Graham and Denning [8] constructed a mo del ha ving generic protection prop erties. This mo del is simple and is widely used as the basis for man y securit y systems [6]. 2.2.1 Description The access matrix mo del as describ ed b y Graham-Denning has the follo wing three comp onen ts. 1. A set of passiv e ob jects. 2. A set of sub jects that ma y activ ely manipulate the ob jects. Sub jects are themselv es comp osed of t w o things: a pro cess and a domain. A domain is a set of constrain ts determining ho w sub jects ma y access ob jects. Sub jects ma y also b e ob jects at particular times. 3. A set of rules go v erning ho w sub jects ma y activ ely manipulate the passiv e ob jects. The protection state of the system is represen ted as an ac c ess c ontr ol matrix (A CM) The A CM is a table in whic h eac h ro w represen ts a sub ject, eac h column represen ts an ob ject, and eac h en try denes the access righ ts b et w een the sub ject and ob ject. F or eac h ob ject, one sub ject designated as the owner has sp ecial righ ts; for eac h sub ject, another sub ject designated the c ontr ol ler has sp ecial righ ts. In this mo del, there are eigh t primitiv e protection righ ts called commands that can b e issued b y sub jects, with eects on other sub jects or ob jects. T r ansfer ac c ess right allo ws the sub ject to transfer one of its righ ts to another sub ject. Eac h righ t can b e transferable or non-transferable. Only transferable righ ts can b e transferred.

PAGE 18

11 Gr ant ac c ess right allo ws the o wner of the ob ject to gran t an y access righ t for the ob ject to another sub ject. Delete ac c ess right allo ws a sub ject ( S 1 ) to delete a righ t of another sub ject ( S 2 ) for an ob ject ( o ). This is allo w ed only if S 1 is the o wner of o or the con troller of S 2 R e ad ac c ess right allo ws a sub ject ( S 1 ) to determine the curren t access righ ts of another sub ject ( S 2 ) for an ob ject ( o ). This is allo w ed only if S 1 is the o wner of o or the con troller of S 2 Cr e ate obje ct allo ws the commanding sub ject to create a new ob ject. Cr e ate subje ct, delete obje ct and delete subje ct The in terpretations of these commands are what their names imply The ab o v e rules pro vide the basic framew ork required to design a protection system. W e can no w lo ok at a few extensions and mo dications of this mo del that ha v e found widespread use. 2.2.2 Harrison-Ruzzo-Ullman Result Harrison, Ruzzo and Ullman [9] prop osed a v ariation on the Graham-Denning mo del that answ ered sev eral questions concerning what protection systems can determine. The HR U mo del is v ery similar to Graham-Denning mo del and consists of a nite set of generic rights, R and a nite set C of c ommands where eac h command in v olv es c onditions and primitive op er ations The primitiv e op erations are the same as in Graham-Denning mo del. Harrison et al. deriv ed t w o imp ortan t results that ha v e ma jor implications for designers of protection systems. The rst result states that in a system, where commands are restricted to a single op eration eac h, it is p ossible to decide whether a giv en sub ject can ev er obtain a particular righ t to an ob ject. The second result states that if commands are not restricted to one op eration eac h, it is not alw a ys decidable whether a giv en protection system can confer a giv en righ t.

PAGE 19

12 2.2.3 T yp ed Access Matrix Ra vi Sandh u and others ha v e w ork ed on mo difying the HR U mo del to mak e the safet y problem decidable while at the same time maximizing the expressing p o w er [10]. The T yp ed Access Matrix (T AM) [11 ] dened b y Sandh u com bines strong safet y prop erties for propagation of access righ ts of Sc hematic Protection Mo del [12] with the natural expressiv e p o w er of the HR U mo del. T AM is obtained b y incorp orating strong t yping in to the HR U mo del [13]. It is imp ortan t to understand that the t yp es and righ ts are sp ecied as part of the system denition. The system administrator sp ecies the follo wing sets for this purp ose: a nite set of access righ ts denoted b y R and a nite set of ob ject t yp es denoted b y T The pr otection state is a T AM system is giv en b y the four-tuple ( O B J S U B t AM ) in terpreted as follo ws: O B J is the set of ob jects. S U B is the set of sub jects, S U B O B J t : O B J T is the ty pe f unction whic h giv es the t yp e of ev ery ob ject. AM is the access matrix. W e ha v e AM [ S; O ] R where S is a sub ject and O is an ob ject. The protection state of the system is c hanged b y means of T AM commands. Eac h T AM command has the follo wing format: command ( X 1 : t 1 ; X 2 : t 2 ; : : : ; X k : t k ) if r 1 2 [ X s 1 ; X o 1 ] ^ r 2 2 [ X s 2 ; X o 2 ] ^ ^ r m 2 [ X s m ; X o m ] then op 1 ; op 2 ; : : : ; op n end Here is the name of the command; X i are formal parameters whose t yp es are t i ; r i are righ ts. Eac h op i is one of the primitiv e op erations listed b elo w:

PAGE 20

13 en ter r in to [ X s ; X o ] delete r from [ X s ; X o ] create sub ject X s of t yp e t s delete sub ject X s create ob ject X o of t yp e t o delete ob ject X o The righ ts, t yp es and commands dene the system sc heme. The sc heme can b e mo died only b y the system administrator, who is not considered to b e a part of the system. The t yp e of an ob ject is xed and cannot b e c hanged within the system. Sandh u has pro v ed that T AM has considerable expressiv e p o w er. A T AM in whic h none of the commands use an y of the delete op erations is called Monotonic T AM (MT AM). The righ t leak problem in acyclic MT AM is decidable [11]. 2.2.4 Mo dications on A CM The ab o v e mo dels do not sp ecify what the particular access rules are, and are therefore v ery rexible. Ho w ev er, this mak es it v ery dicult to v erify the securit y of the system and according to the HR U result, it ma y ev en b e imp ossible to decide. Moreo v er, the A CM itself is usually a v ery sparse matrix. F or eciency and organizational purp oses, A CMs need to b e partitioned and implemen ted indep enden tly [14]. The mo del is usually implemen ted in one of the follo wing w a ys: 1. Cap ability list where eac h sub ject is giv en a list of ob jects along with the allo w ed accesses for eac h of these ob jects. It is analogous to a tic k et to a mo vie and cannot b e duplicated. 2. A c c ess c ontr ol list where eac h ob ject has a list of all sub jects that ha v e access to the ob ject and the allo w ed access for eac h sub ject. This implemen tation is v ery p opular and is used in man y systems. 2.2.5 Commen ts The simplicit y of the mo del mak es it a p opular c hoice in man y systems. It is usually implemen ted as an A CL. In some distributed systems, Capabilit y lists are used. Eac h sub ject carries a token whic h authen ticates the sub ject and also con tains the access privileges allo w ed for that sub ject.

PAGE 21

14 2.3 ADMIRAL Mo del 2.3.1 In tro duction ADMIRAL is a collab orativ e pro ject carrying out researc h in to the use and managemen t of high p erformance net w orks. Stepney and Lord [15] ha v e prop osed an access con trol mo del for ADMIRAL whic h can b e used in other systems as w ell. This mo del allo ws users to log in to a distributed computing system and mak e requests for services in an y part of the system, without ha ving to pro vide an y more information ab out themselv es. All access con trol decisions are handled automatically and remain in visible to the user unless access is refused. 2.3.2 Description In a m ulti-administration net w ork, sev eral autonomous access con trol systems normally in teract. This leads to frustration for b oth administrators and users. The ADMIRAL mo del allo ws users and services from dieren t administrations to comm unicate with eac h other, while still allo wing administrators to retain con trol of their o wn parts of the net w ork. A system based on this mo del will ha v e the prop erties listed b elo w. 1. Autonomous administrations can w ork with eac h other, but still retain con trol o v er their o wn facilities. 2. Users' access to services can b e con trolled, ev en when the user and the service fall under dieren t administrations. This con trol is in visible to users, unless they try to access services not a v ailable to them. 3. An administrator can mak e use of another's facilities, if they b oth agree. 4. Multiple lev els of securit y are a v ailable to users and administrators. They can insist on a particular lev el for certain op erations. Princip als mak e requests for services. Servers pro vide services. A Client handles requests for a principal and passes it on to a serv er. Principals ha v e access righ ts, p ermissions to mak e certain requests of certain serv ers. A uthorities pro vide

PAGE 22

15 access con trol functions. They store statements ab out principals' access righ ts. Statemen ts sa y things lik e 'JOHN has READ access to FILEx'. Authorities are used b y serv ers to c hec k the access righ ts of principals, and b y clien ts to gain access to serv ers for principals. Authorities can obtain and generate statemen ts for other authorities and for en tities. Eac h clien t and serv er has a lo cal authorit y whic h it trusts to mak e appropriate access con trol decisions. These en tities will not use an y other authorit y directly An en tire clien t-serv er cycle is kno wn as a tr ansaction and tak es place as follo ws (refer Figure 2.1). The principal mak es a request for some service via a clien t (1). The clien t mak es the request on the principal's b ehalf (2). The request go es through the Clien t's Lo cal Authorit y (CLA). The CLA holds cac hed statemen ts ab out the principal and serv er. These are obtained from its o wn store and optionally from other trusted authorities (3). The request is passed on (4) to the Serv er's Lo cal Authorit y (SLA) whic h c hec ks the access righ t, using its cac hed statemen ts. These are obtained from the CLA's cac he, and optionally from its o wn store and from other trusted authorities (5). If the access conditions ha v e b een fullled, the request is passed on to the serv er for pro cessing (6). F urther exc hange of data ma y o ccur after this (7). 2.3.3 Commen ts The ADMIRAL mo del is a relativ ely simple system that mak es use of remote pro cedure calls across the net w orks to comm unicate. There are a few dra wbac ks in the mo del. On accoun t of cac hing of statemen ts, if a particular righ t of a principal is remo v ed, it has to b e deleted from cac hes of all the trusted authorities. This is a ma jor task and ma y increase the net w ork trac. Cac hing ma y violate the che ck every ac c ess goal of access con trol systems. Another imp ortan t issue is trust. The authors sa y that trust is not a transitiv e relation. If this w ere so, then all authorities ma y end up trusting all the others. The issue of trust is not fully

PAGE 23

16 Principal Server'sLocalAuthority Client Client'sLocalAuthority Server Other Authorities 12 3 4 5 6 7 Figure 2.1: Comm unication paths in a T ransaction solv ed. The mo del pro vides a frame w ork in whic h administrations can main tain autonom y while allo wing close in teraction b et w een distributed systems. 2.4 OSF Distributed Computing En vironmen t 2.4.1 In tro duction The Distributed Computing En vironmen t (DCE) from the Op en Soft w are F oundation (OSF) co v ers more platforms and oers more features than most other clien t/serv er tec hnology [1]. The DCE Securit y F ramew ork (or mo del) is simpler than real-life situations and omits implemen tation details. 2.4.2 Description The securit y activit y is cen tralized in a se curity server whic h pro vides the securit y services normally pro vided b y an op erating system o v er the net w ork. All other clien ts and serv ers trust the securit y serv er and what it tells them. The securit y serv er main tains a r e gistry that stores information ab out the principals, privilege attributes, and secret k eys. The DCE securit y registry is accessible only via a Remote Pro cedure Call (RPC) in terface. A user m ust log in to DCE b efore he or she can access DCE services. Then, whenev er the user w an ts to access a

PAGE 24

17 Client SecurityService Server Data Reference Monitor 1 2 Figure 2.2: DCE securit y mo del remote ob ject, he or she m ust rst ask the securit y serv er to issue a c ertic ate that certies the iden tit y of the user (refer Figure 2.2). The certicate, also called a cr e dential is a message issued b y a trusted authorit y in suc h a manner that the serv er can indep enden tly v erify the clien t's authen ticit y The clien t then passes the certicate as part of a RPC call to the serv er. When the serv er receiv es the call, it passes the certicate to the reference monitor for the ob ject. The reference monitor examines the certicate and decides whether the clien t is authorized to mak e the call. If so, the call is accepted, pro cessed, and the results are returned. Otherwise the call is rejected. The DCE Securit y do es not pro vide a reference monitor. Instead, DCE pro vides the to ols for an yb o dy to implemen t their o wn reference monitor. The job of a reference monitor is to matc h the information in the certicate against an access con trol list. The DCE denes a standard RPC managemen t in terface for an A CL facilit y and allo ws one to use the A CLs in man y w a ys. F or example, users can b e c hec k ed b oth as individuals and as mem b ers of groups. Applications can also c ho ose their o wn kinds of p ermissions but ev ery application should supp ort a con trol p ermission that determines who can up date the A CL.

PAGE 25

18 Another reason that reference monitors are custom-made is that eac h application needs to dene its o wn storage mo del. F or example, a distributed UNIX-lik e le system will probably store its securit y attributes in the ino de while a database managemen t system ma y c ho ose to store it in some other data structure. 2.4.3 Commen ts Since the mo del do es not describ e the implemen tation, it is highly rexible. A common in terface allo ws a managemen t to ol lik e acl e dit to manage all DCE A CLs, including those implemen ted b y applications. Ho w ev er, the securit y serv er has to b e carefully protected. If someone can gain con trol of the system with the securit y serv er and its registry that p erson w ould ha v e access to all the accoun ts. If the securit y serv er is cut o from the rest of the net w ork, nob o dy can p erform an y access b ecause they cannot get the certicates to authen ticate themselv es to the reference monitor. Ho w ev er, this mo del pro vides cross-platform supp ort and allo ws applications to sp ecify their o wn access t yp es. 2.5 Role-Based Access Con trol 2.5.1 In tro duction Role-Based Access Con trol (RBA C) is a mo del standardized b y Da vid F erraiolo and Ric hard Kuhn at the National Institute of Standards and T ec hnology The principal motiv ations b ehind RBA C are the abilit y to articulate and enforce en terprise-sp ecic securit y p olicies and to streamline the t ypically burdensome pro cess of securit y managemen t [16]. In man y organizations, the end users do not "o wn" the information for whic h they are allo w ed access. The corp oration is the actual "o wner" of system ob jects as w ell as the programs that pro cess it and con trol is often based on emplo y ee functions rather than data o wnership [17]. In RBA C, users do not ha v e discretionary access to en terprise ob jects. Instead, access p ermissions are asso ciated with roles and users are asso ciated with roles.

PAGE 26

19 2.5.2 Description A role based access con trol p olicy bases access con trol decisions on the roles a user is allo w ed to tak e on within an organization. The determination of role mem b ership and the allo cation of transactions to a role is in compliance with organization-sp ecic protection guidelines deriv ed from existing la ws, ethics, regulations, or generally accepted practices [17]. With RBA C, users are not gran ted p ermission to p erform op erations on an individual basis, but op erations are asso ciated with roles. This has the adv an tage of simplifying the understanding and managemen t of privileges. System administrators con trol access at a lev el of abstraction that is natural to the w a y en terprises t ypically conduct business. RBA C addresses securit y primarily for application-lev el systems, as opp osed to general purp ose op erating systems. T o impro v e eciency and pro vide for the natural structure of an en terprise, RBA C includes the concept of r ole hier ar chies A role hierarc h y denes roles that ha v e unique attributes and that ma y "con tain" other roles, i.e., one role ma y implicitly include the op erations, constrain ts, and ob jects that are asso ciated with another role. RBA C enforces the follo wing rules on role authorization, role allo cation, and op eration execution. 1. R ole Hier ar chy If a sub ject is authorized to access a role and that role con tains another role, then the sub ject is also allo w ed to access the con tained role. 2. Static Sep ar ation of Duty A user is authorized as a mem b er of a role only if that role is not m utually exclusiv e with an y if the other roles for whic h the user already p ossesses mem b ership. 3. Car dinality The capacit y of a role cannot b e exceeded b y an additional role mem b er. 4. R ole A uthorization A sub ject can nev er ha v e an activ e role that is not authorized for that sub ject.

PAGE 27

20 5. R ole Exe cution A sub ject can execute an op eration only if the sub ject is acting within an activ e role. 6. Dynamic Sep ar ation of Duty A sub ject can b ecome activ e in a new role only if the prop osed role is not m utually exclusiv e with an y of the roles in whic h the sub ject is curren tly activ e. 7. Op er ation A uthorization A sub ject can execute an op eration only if the op eration is authorized for the role in whic h the sub ject is curren tly activ e. 8. Obje ct A c c ess A uthorization A sub ject can access an ob ject only if the role is part of the sub ject's curren t activ e role set, the role is allo w ed to p erform the op eration and the op eration to access the ob ject is authorized. 2.5.3 Commen ts RBA C pro vides a means of naming and describing relationships b et w een individuals and righ ts. Some form of RBA C is used in commercial systems to da y but there is no commonly accepted formal standards encompassing RBA C and RBA C remains a long w a y from b eing a commercially p opular tec hnology 2.6 Access Con trol in UNIX Op erating System 2.6.1 In tro duction The UNIX op erating system w as dev elop ed at Bell Lab oratories in the late 1960s. It ev olv ed in a "friendly" en vironmen t, on systems that encouraged users to share their les [4]. Ho w ev er, UNIX is b y design a v ery robust system. The follo wing is a brief discussion of the basic principles in UNIX access con trol. 2.6.2 Description Files are cen tral to UNIX in w a ys that are not true for other op erating systems. Commands are executable les in sp ecic directories lik e /bin /usr/bin etc. System privileges and p ermissions are con trolled in a large part via access to les [18 ]. Access to les is organized around le o wnership and protection. Eac h le has a user o wner and a group o wner. UNIX supp orts three t yp es of le access: read ( r ), write ( w ), and execute( x ). A dieren t set of access righ ts can b e set for user o wner, group mem b ers and others. F or example, the access righ t

PAGE 28

21 r w xr xr means that the user o wner can read, write and execute the le, mem b ers of the group o wner can read and execute the le but all others can only read the le. The command that is used to alter the access mo de is chmo d There are a few other dened le mo des, namely t (Stic ky bit, k eep executable in memory after exit), s (Set pro cess user ID or group ID on execution), and l (set mandatory le lo c king on reads/writes). Files that b egin with a p erio d are hidden les and are not listed b y ls command unless used with the a option. The l option of ls command lists the les along with the mo des and o wners of the les. The set of commands that are used to mo dify the access righ ts of les are: chmo d Sp ecify the protection mo des for les. umask Sp ecify the default mo de for newly created les. chown Change the user o wner of a le. chgrp Change the group o wner of a le. Some v arian ts of UNIX, lik e AIX and HP-UX pro vide access con trol lists whic h oer a further renemen t to the standard UNIX le p ermissions capabilities. These A CLs consists of three parts: 1. Attr ibutes Sp ecies an y sp ecial attributes lik e SETUID and SETGID. 2. B ase per missions These corresp ond exactly to the UNIX le mo des and sp ecify access righ ts for o wner, group and others. 3. E xtended per missions These are access information sp ecied b y user and group name. A CLs that sp ecify a username and group are useful for accoun ting purp oses. They are also useful if y ou add a user on a temp orary basis [18]. UNIX w as the rst ma jor net w ork op erating system. It pro vides v arious services lik e NIS (Net w ork Information Services) and NFS (Net w ork File System) that help in administering a net w ork. Using NIS, users can log on to an y mac hine

PAGE 29

22 on the net w ork that b elong to the same NIS Domain. In a net w ork with t w en t y mac hines, the administrator has to add the new user on just one mac hine and that user can log on to an y one of these t w en t y mac hines. In order to pro vide a uniform directory structure when a user logs in, administrators moun t le systems o v er the net w ork. Usually the user's home directories are moun ted using NFS. This w a y the user's les are a v ailable to him/her on an y mac hine in the net w ork. The adv an tage with this arrangemen t is that con trolling le p ermissions is the same as describ ed earlier. 2.6.3 Commen ts Users authen ticate themselv es to the system b y pro viding a user name and passw ord. It is v ery imp ortan t for users to protect their passw ords b ecause if the passw ord is compromised, then all of the logins ma y b e compromised [4]. P assw ords and le p ermissions are t w o basic w a ys of prev en ting securit y problems in UNIX. P assw ords prev en t bad guys from getting on the system in the rst place and prop er le p ermissions prev en t normal users from doing things they are not supp osed to [18]. One imp ortan t issue in UNIX le p ermissions is the restricted access t yp es. There is no w a y for users to dene their o wn access t yp es Moreo v er, the o wner of a le has full righ ts to do an ything with the le. In man y organizations, the les are not "o wned" b y the users but b y the organization itself. 2.7 Distributed Compartmen t Mo del 2.7.1 In tro duction The Distributed Compartmen t Mo del w as prop osed b y Stev en Green w ald as a solution to managemen t of system resources and access con trol in a distributed computing en vironmen t. The mo del consists of t w o parts, (i) Distribute d Hand les a means for user iden tication and access con trol and (ii) Distribute d Comp artments a metho d for allo wing users to manage resources within a distributed system across

PAGE 30

23 computer system b oundaries with a measure of indep endence from an y system administrations [3]. 2.7.2 Description The distributed handles eliminates group w are application userIDs as a means of iden tication and access con trol. A user joining a group w are session is queried for a handle that is unique to that application and is then v eried b y a group w are securit y manager. Under this metho d, an individual user w ould rst gain access to a particular computer system in the distributed system b y ha ving a v alid user ID and passw ord. The user w ould then need a v alid distributed handle and w ould then need to b e v alidated b y the group w are's access con trol securit y in order to b e allo w ed access to the application. The ma jor adv an tage of this approac h is that securit y dep endencies are reduced. Moreo v er, the handles can b e more descriptiv e than user IDs, for example "Third programmer" instead of "a v0". Multiple handles can b e p ermitted for the same user and man y users can share the same handle. Distributed compartmen ts (also called discom) is the designated platform for access con trol and administration of distributed handles. A discom is a logical group of ob jects that is conceptually similar to a standard hierarc hical directory structure but do es not necessarily reside in a single computer. The users of discoms gain access via distributed handles. A ro ot discom is called an empir e disc om Eac h discom m ust ha v e at least one sub ject called g ov er nor Go v ernors ha v e the maxim um privileges for the discom they go v ern. There are 24 basic op erations called initial privile ges They include op erations that create/destro y/merge/split/mo dify ob jects/c hild discom/empire, create/rescind privilege/go v ernorship/sub ject/resource/priv ilege etc. This com bination of sub jects, ob jects and privileges, mak es it p ossible to create a system similar to an access con trol matrix.

PAGE 31

24 The Distributed Compartmen t Mo del has a set of axioms and prop erties some of whic h are: Genesis Axiom The initial state of the system is secure. D iv ine R ig ht Axiom A sub ject can create an empire discom only if giv en that privilege b y the administrators. T empor al Axiom A sub ject ma y only access an ob ject with the same time index as the sub ject. U sag e P r oper ty If a sub ject is curren tly accessing an ob ject, it either accessed the ob ject b efore the presen t time, or it requested access of the ob ject b efore the presen t time. C r eator P r oper ty The creator of a discom automatically b ecomes a go v ernor of that discom. Gov er nment P r oper ty The go v ernor of a discom ma y gran t and rev ok e privileges to non-go v ernor sub jects of that discom. C or don P r oper ty Discoms ma y nev er in tersect with other discoms. D emesne P r oper ty The go v ernor of a discom alw a ys has unrestricted access to descendan t discoms. C eil ing P r oper ty A sub ject ma y not access an ancestor discom without b eing a sub ject of that discom. A distributed compartmen t is actually a group w are application, with access to the discoms determined b y distributed handles. Managemen t of discoms is not done b y the lo cal system administrators but b y the individual users who are go v ernors of empire discoms. 2.7.3 Commen ts One ma jor disadv an tage with this mo del is that users will ha v e to ha v e a separate handle for eac h application they use. This means that they will ha v e to remem b er not just their user ID and passw ord but the handle and passw ord for eac h application. It w ould ha v e b een preferable to a v oid suc h m ultiple "logins".

PAGE 32

25 Since man y users can share handles, this reduces accoun tabilit y Moreo v er, this mo del practices a t yp e of monarc h y in whic h the go v ernors ha v e absolute p o w er whereas a more demo cratic form of go v ernmen t will b e more practical in the long run.

PAGE 33

CHAPTER 3 REQUIREMENTS 3.1 In tro duction A complete understanding of soft w are requiremen ts is essen tial to the success of an y soft w are dev elopmen t eort. No matter ho w w ell designed or w ell co ded, a p o orly analyzed and sp ecied program will disapp oin t the user and bring grief to the dev elop er [19]. The requiremen t analysis task is a pro cess of disco v ery renemen t, mo deling and sp ecication. The nal output exp ected from this stage is a detailed sp ecication of the requiremen ts. Ho w ev er as Dwigh t Eisenho w er said, "The plan is nothing; the planning is ev erything". The corollary of this statemen t as applicable to requiremen ts analysis is "The pro duct is nothing; the pro cess is ev erything" [20]. 3.2 The Pro cess The soft w are dev elopmen t mo del used in DCS is the spiral mo del. The v arious stages in the soft w are dev elopmen t cycle o v erlap and feed information to eac h other. During design, problems with requiremen ts are iden tied; during co ding, design problems are found and so on [21 ]. The soft w are pro cess is not linear and one go es through sev eral iterations b efore the nal v ersion. An ecien t w a y to capture the exp ected p erformance of the system is through scenarios. Scenario-based requiremen t solicitation is an approac h that has w ork v ery w ell for us. The idea b ehind this approac h is to list out v arious scenarios and discuss ho w the system should p erform in these scenarios. This not only helps us understand the system, but also serv ed as a go o d starting p oin t for further discussions. 26

PAGE 34

27 Eac h set of scenarios along with the exp ected system b eha vior w as discussed among the DCS group mem b ers. This w a y the other group mem b ers could understand ho w the Access Con trol Services (A CS) in teracts with their mo dules. During these brainstorming sessions, w e w ere able to nail do wn most of the functions and exp ectations. An added adv an tage with this approac h w as that w e had a set of test cases ready along with the exp ected p erformances. This also help ed us with the user in terface design to o. Let us no w lo ok at a set of sample scenarios. 3.3 A Sample Scenario Initially let us assume that there are three sites, A, B, and C and that a DCS user can log in without b eing b ound to an y conference (i.e., logs in to the v estibule conference). All new mem b ers of a conference are b ound to the role member unless otherwise sp ecied during the joining pro cess. 1. User Alice is added to DCS from site A. A new DCS Id is created for Alice and v arious information ab out Alice, lik e address, email etc., are stored in a global database. 2. Alice creates a new conference DCS at site A. The system rst c hec ks to see if Alice has the righ t to create new conferences, if so, DCS is added to the global conferences database from site A. Alice binds to the role admin Alice has to create the initial roles and initialize the access con trol matrix (A CM). 3. Alice creates a new role outsider for users who request to join the conference. This is a part of initiating the conference and since Alice is the admin, she can do it. 4. Bob logs in as an outsider and requests to join DCS. Since r eq uesting to j oin the conf er ence is a righ t gran ted to the role outsider, the issue is put to v ote. Let us sa y that Bob is allo w ed to join the conference. 5. Alice requests to allo w Bob to b e an admin.

PAGE 35

28 The A CM is c hec k ed to see if Alice can add new role bindings to the role admin. If so, then the corresp onding decision p oin ter is activ ated and if the result is p ositiv e, the request is carried out. 6. Bob requests to allo w admin to c hange the access privileges of an y user. This issue is put to v ote based on the template for c hanging the A CM. 7. Charles logs in as an outsider from site B and requests to join the conference. 8. Alice and Bob agree to let Charles in. Since they are the only t w o mem b ers of the conference, the request is gran ted. Charles is added to the conference as a mem b er and site B is added to the list of sites that are a part of the conference DCS. The relev an t databases are copied to site B. 9. Alice imp orts a do cumen t, "W elcome.do c" and sets p ermissions in suc h a w a y that ev ery mem b er of the conference can read it but she alone can mo dify it. This is allo w ed as Alice has the righ t to imp ort ob jects. She also has to add a new ob ject t yp e sa y C onf er ence D ocuments and gran t read access to all mem b ers. There has to b e a w a y to sp ecify sub ject-to-ob ject relationships. This can b e ac hiev ed using special per missions 10. Charles requests to c hange the v oting template for mem b ership requests to include mem b ers as w ell. The A CS has to c hec k if a mem b er has the righ t to mak e suc h a request. If he is allo w ed, the issue is out to v ote, else the request is denied. 11. Donald logs in from site C and requests to join the conference. The v ote is placed on the table and rejected. Donald has to b e notied ab out the result. 12. Dan applies to join the conference from site C. Dan's request is put to v ote and once he is appro v ed, the relev an t databases are copied to site C and the site is added to the list of sites for the conference. 13. Bob creates t w o new roles, w r iter and editor Since the conference p olicy allo ws admin to create new roles, these t w o new roles are added. 14. Alice mak es Dan a writer. This is allo w ed if admin can add new user binding to the role writer. 15. Alice adds a video conferencing application to site A.

PAGE 36

29 The application is registered for site A and new access t yp es are added to the A CS. 16. Dan creates a new ob ject t yp e w r iter document and imp orts four new do cumen ts. This action is allo w ed only if writers can add new ob ject t yp es and imp ort do cumen ts. Dan has to set the initial p ermissions for the ob ject t yp e writer do cumen t. 17. Charles copies one of the writer do cumen ts to his p ersonal space. This is allo w ed if Charles has the righ t to exp ort writer do cumen ts. 18. Dan logs in as a mem b er and mo v es to dissolv e the conference. First the system c hec ks if mem b ers can delete the conference, if so the issue is v oted on and dep ending on the template a decision is made. 3.4 Requiremen ts of the A CS This section deals with the access con trol requiremen ts of the Distributed Conferencing System (DCS). The access con trol mo dule con trols the access to v arious conference ob jects in t w o w a ys: role sp ecic access privileges and additional pro cessing functions called De cision T emplates It m ust b e noted that dieren t sites and conferences ma y ha v e dieren t access con trol p olicies. 1. Access con trol decisions are made b y lo oking up at the Access Con trol T able Eac h en try in the A CT has a p oin ter to the decision template that m ust b e used to obtain the result. The actual pro cess of arriving at a decision is tak en care of b y the Decision Supp ort Services (DSS) 2. The default decision for access is No That is, unless otherwise explicitly men tioned, all access requests are denied. 3. Privileges are rev o cable actions whic h sub jects ma y p erform on ob jects using applications. 4. Dieren t applications ha v e dieren t t yp es of access privileges. Hence the A CS m ust b e able to handle new access t yp es. 5. A role is a lab eled set of sub ject/ob ject privileges within a conference. Privileges are sp ecied for particular roles. In order to c hec k the privileges of a sub ject, w e lo ok at the privileges of the role to whic h the sub ject is b ound.

PAGE 37

30 6. A sub ject-role mapping is not one-to-one. There can b e more than one sub ject b ound to a role and a sub ject can b e allo w ed to bind to dieren t role at dieren t p oin ts of time. Ho w ev er, at an y p oin t of time, a sub ject can bind to at most one role. 7. It should b e p ossible to add new roles and delete existing roles. 8. There should b e an A dmin role for eac h conference. The admins initially ha v e Go d-lik e p o w ers within the conference (this is required for initializing the conference and to get the conference started). A t a later stage, it is up to the mem b ers of the conference to retain these righ ts or replace them with more demo cratic decision templates. 9. Certain users ma y b e able to mo dify the access privileges of certain roles. 10. Ob jects of the same t yp e are group ed together under Ob ject T yp es. The A CT sp ecies privileges with resp ect to ob ject t yp es only 11. The A CT itself is an ob ject and access privileges can b e sp ecied as to who can mo dify the A CT. Dieren t sub jects can ha v e dieren t gran ularit y of access. F or example, some sub jects can mo dify a paricular column, some can mo dify a few sp ecic ro ws and some can mo dify the whole matrix. 12. Some examples of access privileges are: Application sp ecic access to an ob ject lik e pla y a m usic le etc. Delete an ob ject. View an ob ject's existence. Execute an application. Add/remo v e an application to/from a conference. Create/mo dify/delete an ob ject. Create/mo dify/delete a sub ject. Create/delete a role. Mo dify access privileges of a role. Mo dify decision p oin ters of an en try 13. The creator of the conference should b e able to initialize the tables, i.e., sp ecify the initial righ ts, roles, t yp es, decision templates and accesses. 14. W e should b e able to dene certain sp ecial relationships b et w een ob jects and sub jects that are not v alid for other sub jects in that role and other ob jects of that ob ject t yp e. These are called sp e cial p ermissions 15. Gran ting and rev oking these sp ecial p ermissions is also an access righ t.

PAGE 38

31 16. There are certain site sp e cic access con trol requiremen ts that ha v e to b e handled b y the A CS. An outsider should b e able to join a conference. Certain users should b e able to install new applications on the site. Certain users should b e able to remo v e applications from the site. Adding a new site to the DCS instance is a righ t that m ust b e a v ailable to certain users. Splitting/merging/deleting of sites should also b e p ossible. Users should b e able to create a new conference. Splitting/deleting a conference and merging t w o conferences should also b e p ossible.. 17. The mo del should b e fault toleran t. If one of the sites go es do wn, then the other sites should con tin ue to pro vide service to the b est of their abilities. When a site comes bac k on-line from a crash or sh utdo wn, it should b e able to commit the up dates it missed and get bac k to normal op erations. 18. If the net w ork is partitioned, the system should b e able to sort out an y inconsistencies once the comm unication links get bac k online. 19. If a particular site go es do wn, then up on reco v ering, it should b e able to get the most up to date information from one of the other sites and con tin ue pro cessing the stalled requests. 3.5 In teractions with other DCS services The A CS will ha v e to comm unicate with other services within the DCS in order to pro vide services and to mak e use of their services. This section deals with what is exp ected from the A CS b y the other services and what A CS can exp ect from the others. 3.5.1 Database Services The A CS will ha v e to con tact the Database Services for almost all queries. The A CT and the other tables required b y the A CS are accessed through the DBS and all queries and mo dications run through the DBS. If an y database query cannot b e executed, the A CS should b e able to handle the error and rep ort the cause. The A CT should b e replicated across all sites that are a part of the conference. This is guaran teed b y the DBS.

PAGE 39

32 The A CT consists of follo wing elds, R oleID, Obje ctT yp e, A c c ess, De cisionPointer in the least. In addition to this, w e also ha v e a sp e cial p ermissions table whic h records sp ecial relationships b et w een ob jects and users lik e ownership If a user w an ts to read a le, then w e rst lo ok at the A CT to see if the role to whic h the user is b ound can read ob jects of the le's t yp e. If this is not allo w ed, w e then lo ok at the sp ecial p ermissions table to see if the user has an y sp ecial p ermissions on the ob ject. The sp ecial p ermissions table has the follo wing elds, UserId, Obje ctId, SplR oleId If the user has an y sp ecial p ermissions, then the corresp onding SplRoleId is then c hec k with on the A CT to see if that role has the p ermission to read the ob ject. 3.5.2 Conference Con trol Services The CCS con trols the en tire conference and instan tiates the ob jects that pro vide the services. Moreo v er, most user requests are passed on to the A CS through the CCS. Most CCS-originated actions ha v e to b e c hec k ed through the A CS for access privileges. F or example, if a user w an ts to imp ort a new le, the CCS will ha v e to c hec k with the A CS b efore pro ceeding with the imp ort. A ma jor task for the CCS is application managemen t. Adding a new application to the conference, c hanging ob ject-t yp e asso ciations, deleting an application and ev en running certain applications will require an A CS request. 3.5.3 Decision Supp ort Services The DSS handles the decision-making pro cess and is therefore closely tied to the A CS. If a request requires a v ote, the DSS has to b e notied and the v oting pro cess initiated. The A CS m ust b e able to c hec k the status of a particular v ote. When a v ote is completed, the DSS should notify A CS. Similarly the A CS m ust b e able to rep ort a list of activ e v otes to the DSS if the DSS decides to delete obsolete v otes. Actions lik e dening new templates and mo difying existing ones require a c hec k b y the A CS.

PAGE 40

33 3.6 In teresting Issues There w ere a few in teresting issues that required considerable discussions b efore the requiremen ts w ere nalized. Some of them are listed b elo w. 3.6.1 Admin role The admin role w as an in teresting issue. Suc h a role mak es the task of initializing the conference databases easy and simple. If suc h a role do es not exist, w e ma y need complicated initiation mec hanisms to p opulate the A CT. So to a v oid suc h complications, it w as felt that w e m ust ha v e an administrativ e role in all conferences. By default, the creator of the conference can b e an administrator and an y new user can b e added to or dropp ed from the role b y a v ote among admins or as the conference p olicy sp ecies. The only constrain to b e enforced while remo ving user-admin role bindings is that at an y p oin t of time, there should b e at least one user who can bind to this role. It m ust b e noted that the main idea b ehind using decision p oin ters is to a v oid all-p o w erful users who can do an ything. Although administrators mak e the initial setting up of the conference easy their p o w ers can b e diminished at a later stage and replaced b y a more demo cratic pro cess. 3.6.2 Mo difying the A CT It is ob vious that w e m ust allo w some users to c hange the A CT. In other w ords, some roles ha v e the righ t to gran t/delete righ ts in the A CT. The in teresting question is, ho w do w e represen t the fact that some roles can ha v e the righ t to gran t/delete the righ t men tioned ab o v e. As y ou can see, it is v ery easy to drop in to a b ottomless pit with this line of argumen t. The A CS a v oids this problem b ecause the righ t to gran t/delete righ ts is also represen ted in the A CT and is treated as an y other righ t. 3.6.3 Separation of Dut y Separation of dut y is one of the more common requiremen ts in an y real-life system. F or example, in a bank loan pro cessing system, the p erson appro ving

PAGE 41

34 the loan should not b e the one who prepared or review ed the application do cumen ts. The p erson testing a soft w are mo dule should ideally b e someone not in the programming team. One of the most in teresting p olicy is the Chinese wal l p olicy It ensures that a p erson who has access to do cumen ts of one t yp e, sa y C oco C ol aAdC ampaig n do es not ha v e access to other do cumen ts, lik e P epsicoF oodsAccounts whic h ma y result in a conrict of in terest. Enforcing these p olicies requires some w ork ro w con trol pro cess. In the A CS mo del, the use of decision p oin ters allo ws us to ac hiev e this through the v oting mec hanisms. The mem b ers can reject a request if it is against the conference p olicies. 3.7 Summary As men tioned earlier, the requiremen ts men tioned ab o v e w ere the result of man y iterations through the soft w are dev elopmen t cycle. It is p ossible that some new requiremen t ma y come up at a later stage when more mo dules are added to the system. The curren t implemen tation has b een designed to meet these requiremen ts.

PAGE 42

CHAPTER 4 DESIGN 4.1 In tro duction The next stage in the cycle is the design. A go o d design go es a long w a y in minimizing the dev elopmen t time and simplies testing and main tenance. The input to this pro cess is the requiremen ts do cumen t and the nal design is the result of an ev olutionary pro cess. W e came up with a base design that met the requiremen ts and c hec k ed to see if it handled all the scenarios. W e then lo ok ed at those scenarios that failed and mo died the design as needed. W e then c hec k ed the scenarios again for more failures. In some cases, w e had to mo dify the requiremen ts. Man y organizations freeze the requiremen ts do cumen t once the design stage is reac hed and hence the analysts ha v e to get ev erything righ t the rst time. This is in v ariably not the case. W e therefore decided to follo w the spiral mo del. This c hapter rst discusses the formal denition of the A CS mo del. The database table sc hema and the database query functions are then dened, follo w ed b y the in teraction with other mo dules. Finally some of the alternativ es considered are review ed. 4.2 F ormal Sp ecication of A CS Mo del In this section, w e will presen t the formal sp ecication of the A CS mo del. The A CS mo del is obtained b y adding t yping information in to the HR U mo del [9]. The distribution of righ ts in the system are represen ted b y an access matrix. The matrix has a ro w and a column for eac h sub ject and a column for eac h ob ject. The [ X ; Y ] cell con tains a set of ( r ; dp ) pairs where r is a righ t whic h role X has 35

PAGE 43

36 for ob jects of t yp e Y and dp is a p oin ter to a decision template whic h has to b e activ ated eac h time to X mak es a request to p erform r on Y Eac h sub ject is b ound to one or more r ol es Eac h ob ject is b ound to one obj ect ty pe These bindings can b e c hanged b y an y one who has the righ t to do so. This is a ma jor dierence from the T AM mo del in whic h the bindings are a part of the system denition and can only b e altered b y an external administrator. In the A CS mo del, the administrator is considered to b e a part of the system and is sub ject to the access restrictions imp osed b y the matrix. An instance of A CS has the follo wing nite sets: a set of access righ ts denoted b y R a set of decision templates denoted b y D T a set of ob ject t yp es denoted b y T a set of roles denoted b y T R a set of ob jects denoted b y O B J and a set of sub jects denoted b y S U B (Note that S U B O B J ). W e also ha v e a mapping function t whic h maps eac h sub ject to a subset of T R and eac h ob ject to an elemen t of T The primitiv e op erations that can b e p erformed on the matrix are listed b elo w. create new righ t delete existing righ t create new ob ject t yp e delete ob ject t yp e create new ob ject delete ob ject create new sub ject delete sub ject add new sub ject-role binding delete sub ject-role binding c hange decision p oin ter for an access c hange ob ject t yp e of an ob ject add new en try to matrix cell delete an en try from the matrix cell

PAGE 44

37 In addition to these, w e ha v e a special r el ations function, S R : ( S U B O B J ) T R This returns the sp ecial roles, lik e ow ner ship that individual sub jects ha v e with resp ect to sp ecic ob jects. It m ust b e noted that in T AM, R ; T ; T R and t are all part of the system denition and cannot b e altered b y an y one within the system, whereas these are a part of the A CS mo del instance and can b e mo died b y an y one who has the righ t to do so. T AM do es not ha v e the notion of decision p oin ters either. T AM allo ws an y n um b er of parameters in its commands but the A CS allo ws at most three. A v ersion of T AM, called ternery T AM, whic h allo ws only three parameters, can b e easily reduced to the A CS mo del. Safet y analysis for the A CS mo del is in teresting but is b ey ond the scop e of this thesis. Our in ten tion is to design a mo del that implemen ts distributed access con trol while at the same time mak es the decision making pro cess more demo cratic. 4.3 Database T able Sc hema 4.3.1 Access Con trol T able The Access Con trol T able (A CT) is the main table that is referred for access con trol requests. Since w e w an t to store A CT mo dication righ ts in the A CT itself, w e had to add T ar g etR ol e eld. No w, w e can represen t things lik e, "Role A has the righ t to mo dify the A CT en tries for Role B". In order to handle the v arious scenarios listed earlier, the Access Con trol T able has the follo wing elds: Role T argetRole Ob jectT yp e AccessT yp e DecisionPtr The en try for the target role is NULL unless it is applicable. Hence all en tries corresp onding to righ ts for a role R 1 with resp ect to ob jects of t yp e T 1 and access t yp e A 1 will lo ok lik e: Role T argetRole Ob jectT yp e AccessT yp e DecisionPtr R 1 N U LL T 1 A 1 3 Note that DecisionPtr is of t yp e in teger. The mapping b et w een the Decision p oin ter index and the actual decision template is dened in another table (Decision

PAGE 45

38 T emplate T able). W e can also use AN Y to represen t all instances of that t yp e. F or example, the default en try in the A CT could b e : Role T argetRole Ob jectT yp e AccessT yp e DecisionPtr Admin AN Y AN Y AN Y 1 In all the examples, it is assumed that the decision p oin ter 1 refers to some group decision template that is used for ma jor decisions. The ab o v e en try means that an y access not explicitly allo w ed in the A CT will b e referred to the group decision mec hanism. Sample T able Consider the follo wing A CT: Role T argetRole Ob jectT yp e AccessT yp e DecisionPtr R 1 N U LL T 1 A 1 3 R 1 R 2 T 2 Gr ant 5 R 3 N U LL AC T M odif y D T 1 R 3 N U LL D T M odif y 1 R 1 S R 1 T 1 AddS R 7 R 2 N U LL R T Assig n 3 Admin AN Y AN Y AN Y 1 The en tries in the ab o v e table are discussed b elo w: 1. Role R 1 can p erform access A 1 on ob jects of t yp e T 1 if the result of decision template 3 is p ositiv e. 2. Role R 1 can gran t role R 2 access to ob jects of t yp e T 2 if the result of decision template 5 is p ositiv e. 3. Role R 3 can c hange the decision template p oin ter for some en try in the A CT if decision template 1 returns a yes 4. R 3 can c hange the decision template parameters for en tries that p oin t to that decision template if decision template 1 returns a yes

PAGE 46

39 5. Refer to decision template 7 if a user b ound to role R 1 w an ts to allo w another user (b ound to role R 2 sa y) to b e able to bind to a sp ecial role S R 1 with resp ect to an ob ject of t yp e T 1 (Refer to note regarding sp ecial roles that follo ws later). 6. This en try refers to decision p oin ter 3 if a user b ound to role R 2 w an ts to assign a new R ole x User mapping. 7. This is the en try that gran ts the admin the righ t to do an ything after referring to decision template 1. When the conference is created, the decision p oin ter p oin ts to a template that alw a ys returns a y es A t a later stage, the mem b ers of the conference can remo v e this en try or set the p oin ter to another decision template. In the actual implemen tation, this is treated as a sp ecial case. Note: The en try in the ab o v e table for adding a sp ecial relationship b et w een a user and an ob ject do es not allo w us to enforce automatic enforcemen t of p olicies for assigning sp ecial roles based on the role of the target user. One of the follo wing t w o mo dications can b e used to o v ercome this: 1. W e can write the target role instead of the sp ecial role. Ho w ev er, this do es not enable us to distinguish the sp ecial roles. 2. W e can write the targeted role in the R ole eld. R 1 whic h is the role of the user who w an ts to mak e suc h a mo dication is added as a parameter to the decision template. 4.3.2 Other T ables The A CS has to main tain a few other tables to pro vide the services required. One suc h table is the Sp e cial Permissions table. This table is simply a triple ( U ser I d; O bj ectI D ; S pecial R ol eI D ). The righ ts this user has o v er the ob ject is stored as A CT en tries with S pecial R ol eI D in the role eld and the Ob jectT yp e of O bj ectI D in the ob ject t yp e eld. The A CS also has to main tain the U ser x R ol e bindings in a separate table and the O bj ectI D x O bj ectT y pe information in another table. The A CS m ust also pro vide metho ds to mo dify and query these tables. Another imp ortan t table is the T oDoList This is the list of all access con trol requests for whic h a v ote is

PAGE 47

40 p ending. Once the DSS rep orts the result, the A CS has to lo ok up this list and tak e necessary actions (in most cases, rep ort the result to the CCS). If the request w as to mo dify one of the tables main tained b y A CS, and the result is a "y es", then the mo dication has to b e committed. 4.4 DCS-dened Ob ject t yp es and Access t yp es As w e can see, there are a few DCS sp ecic ob jects that are referred to in the A CT and some DCS sp ecic access t yp es. The ob jects are Access Con trol T able(A CT), Decision T emplate T able (DT), Role T able(R T), Ob jects T able (OT) and Sp ecial Relations T able (SR T). All the tables ha v e the follo wing access t yp es: 1. AddEn try Add a new en try 2. DelEn try Delete an existing en try 3. Mo dify Mo dify an en try The DT is the table that holds the mapping b et w een the decision p oin ter index and the decision template parameters whic h dene the template. The Role T able maps users to the roles to whic h they can bind. The Ob jects T able maps the ob jects and ob ject t yp es. The sp ecial relations table is a table that con tains userid obje ctid and sp e cialr oleid 4.5 Chec k-Access F unction The main service that A CS pro vides is to c hec k if a particular user has the righ t to p erform some action. The C heck Access function could b e a simple query on the A CT for the existence of the tuple corresp onding to the request. The parameters for this function are the U ser I D R ol eI D O bj ectI D AccessT y pe and T ar g etR ol e if applicable. The A CS rst lo oks up the Sp ecial P ermissions table for an y sp ecial relationships. If an y suc h relationship exists, then the R ol eI D is replaced with the corresp onding S pecial R ol eI D W e no w lo ok at the A CT for the existence of suc h a tuple. If one do es exist, the D ecisionT empl ateP tr is passed on

PAGE 48

41 to the DSS to start the pro cess. An en try is made in the T oD oList along with the v ote n um b er returned b y DSS. The T oDolist is the only table that is lo cal to eac h site. All other tables are replicated across all sites in the conference. One tric ky problem w as the AN Y wildcard in the A CT. It w as decided to use the n um b er zero to represen t this wildcard. If the A CT do es not con tain the tuple men tioned earlier, then w e c hec k again with the same set of v alues but a zero for access t yp e rst, then a zero at T argetRole. Note that curren tly only one wild card p er en try is c hec k ed. En tries lik e ( R ol eI D ; AN Y ; O bj ectT y pe; AN Y ; 5) are not supp orted as of no w. The en try ( Admin; AN Y ; AN Y ; AN Y ; D P T R ) is treated as a sp ecial case as it is necessary during the initiation phase. 4.6 In teractions with other Mo dules Since eac h mo dule in the DCS is dev elop ed b y a dieren t p erson, it is v ery imp ortan t to ha v e clearly dened in terfaces b et w een them. Eac h dev elop er has to ha v e a clear idea of what is exp ected from his/her mo dule b y the others. As far as the A CS is concerned, all mo dules call the Chec k-Access metho d. The CCS, DBS and DSS ha v e closer in teraction with the A CS and giv en b elo w are the metho ds for these in teractions. 4.6.1 Conference Con trol Services Since the CCS instan tiates the A CS ob ject, it is also resp onsible for establishing the link b et w een A CS and other mo dules. This is done b y passing references to the other ob jects to the constructor. One problem is that if all ob jects are created at more or less the same time, a particular mo dule ma y not b e ready to service the others and this ma y lead to failures. This is a v oided b y using a t w o step initiation pro cess. In step one, the ob jects are created and they do not comm unicate with eac h other till the CCS sends the go ahead. Therefore, the A CS cannot create the tables b efore the CCS informs it that ev erything is ready The CCS handles the

PAGE 49

42 user login and therefore needs to refer to the Role table. It uses the Role table query metho ds for this. 4.6.2 Database Services All A CS requests in v olv e some form of database queries. The DBS has to pro vide metho ds to create tables, mak e queries on them and to mo dify the en tries. The DBS iden ties one site as the o wner for eac h en try in the tables. An y up date has to go through the o wner site. This is done to ensure consistency Therefore, there are t w o t yp es of database commands, up dates whic h are forw arded to the o wner and queries whic h are pro cessed at the lo cal site. All metho ds in the A CS in v olv e constructing a SQL command that represen ts the user's request and calling either the up date or the query metho d of the DBS. Note that the T oDolist is a lo cal table and is therefore handled separately b y the A CS. 4.6.3 Decision Supp ort Services The DSS main tains the decision templates that are used b y the A CT. When a request is made, the A CS calls a metho d of DSS that initiates the v oting pro cess and returns a v ote n um b er. The DSS also exp orts a metho d that c hec ks the status of a v ote. The DSS ma y ha v e some v otes in its database that are no longer activ e. This is p ossible if it comes bac k from an error state. The A CT pro vides a metho d that lists the v otes that are curren tly activ e. The A CS can also request the DSS to delete a sp ecic v ote that is no longer activ e. 4.7 Alternate Design Earlier, it w as men tioned that access con trol requests to mo dify the A CT are handled b y using the T argetRole eld of the A CT. An alternativ e metho d w as considered to solv e the problem but w as dropp ed b ecause it w as to o complex to implemen t. W e then came up with the additional eld in the A CT. This alternativ e is explained b elo w.

PAGE 50

43 4.7.1 Views The problem arises from the fact that the A CT itself is an ob ject and access to the A CT has to b e con trolled. The mo del used can b e extended to other databases used in the DCS. This op ens up the in teresting issue of access con trol in databases in general. In a database, w e can dene access for dieren t users b y dening view s for them. A view is a sp ecic cut of the en tire database that is a v ailable to the user. W e can sp ecify dieren t views for dieren t users. In the con text of RBA C, w e can sp ecify dieren t views for dieren t roles. Th us the problem of access con trol in databases is equiv alen t to dening dieren t views and enforcing them. Since users can ha v e p ermissions to read some parts of the database and also to some other parts, w e need to dene dieren t views for read and write p ermissions. Normally the write view is a subset of the read view but this need not alw a ys b e the case. Although w e will ha v e to deal with t w o dieren t views b oth the views can b e handled in more or less the same w a y Since w e are implemen ting role-based access con trol, w e will ha v e to sp ecify read and write views for eac h role. T o rerect sp ecial relationships, w e m ust sp ecify sp ecial role views, on the lines of sp e cial p ermissions of the A CM. The rules for c hec king access are the same as that of sp ecial p ermissions of A CM. Implemen ting views p oses some in teresting problems. Unless w e ha v e a go o d understanding of the sc hema of the database, w e can not eectiv ely sp ecify views. It is reasonable to assume that the sc hema of a database do esn't c hange often. W e can refer to the attributes of the database as columns in a table and the individual en tries as ro ws. In order to sp ecify a view, w e need to sp ecify the ro ws and columns that are visible to the user. Moreo v er, w e cannot just sp ecify the b oundary ro ws and columns b ecause there ma y b e some en tries in b et w een that are not a part of the view. So w e sp ecify the b oundaries in a Boundary list and the

PAGE 51

44 sp ecify all those en tries that are inside the b oundary but not a part of the view in a deny list F or an en try to b e a part of the view, it has to b e inside the b oundaries and should not b e presen t in the den y list. Here are t w o metho ds to implemen t these. 1. R ow/Column Numb ers The ob vious w a y to sp ecify suc h a view is to list the ro w and column n um b ers that are a part of the view. This is a v ery easy solution at the outset. Since the in ternal represen tation of the database will b e in the form of a table with eac h en try as an ob ject, w e can easily obtain the ro w and column n um b ers. The problem with this approac h is that eac h time there is an addition or deletion to the table, w e will ha v e to revise the t w o lists to rerect the c hange. This is to o exp ensiv e an o v erhead and this approac h w as dropp ed. Another problem is that the order of en try ma y not rerect the logical organization. 2. A l low/Deny rules A sligh t mo dication of the rst approac h helps us o v ercome this problem. Instead of sp ecifying the ro w and column n um b ers, if w e sp ecify rules for selection, w e need not up date the lists after eac h addition or deletion of en tries. Here, w e dene rules for the views and the ro ws to b e selected can b e sp ecied b y suc h rules. W e can list the column n um b ers (since insertions and deletions of columns, i.e. sc hema c hanges are rare). Here again, w e need t w o lists, A l low-rules list and Deny-rules list W e rst apply the allo w-rules to see if the user is allo w ed access to the curren t en try and if so, w e c hec k the den y-rules to see if suc h an access has b een explicitly disallo w ed. W e can sp ecify the lists via ro w selectors and attribute names. SummaryThis implemen tation will use another table to resolv e access con trol issues in A CM. W e will ha v e to dra w the line here and sa y that only the conference o wner or the mem b ers of a sp ecic role lik e admin can alter this table and they ha v e full access to this table. W e ha v e to do this to a v oid going one step higher eac h time to ha v e a table that con trols access to the curren t database. This approac h w as dropp ed when the T ar g etR ol e attribute w as in tro duced.

PAGE 52

CHAPTER 5 IMPLEMENT A TION AND TESTING The next phase in the soft w are cycle is implemen tation. One ma jor requiremen t of a go o d design is a short implemen tation time. The design from c hapter four has b een implemen ted in Ja v a and tested to meet the requiremen ts sp ecied in c hapter three. One of the rst decisions that w e made w as to implemen t the DCS V2 in Ja v a. The previous v ersion w as implemen ted in C with a TCL/TK user in terface. The dev elop ers faced man y problems including main taining compatibilit y b et w een the v arious v ersions of TCL/TK. The RPC in terface of C w as not dev elop er-friendly and in tegrating the dieren t mo dules b ecame a ma jor c hore. Ja v a pro vides us with an easy-to-use set of built-in library routines and is p ortable across most platforms [22]. Remote Metho d In v o cation (RMI) of Ja v a mak es it easy to call metho ds on another serv er. Moreo v er, Ja v a Swing co de is standard for all platforms and ensures that the user in terface lo oks the same in all the platforms. The bac k end Database Managemen t System (DBMS) used w as P ostgres whic h is a free w are relational DBMS. The DCS V2 w as implemen ted on a Lin ux b o x running RedHat 7.0. P ostgres w as a v ailable with the op erating system and installation w as trivial. W e w ere also able to install the windo ws v ersion of P ostgres on a windo ws mac hine for testing purp oses. Note that only the Database Services (DBS) in teracts with the bac k end DBMS pac k age and the A CS cannot access the DBMS directly This is done b ecause P ostgres is not a distributed DBMS and the DBS has to propagate the up dates to all the sites in the conference. 45

PAGE 53

46 5.1 Implemen tation of A CS As men tioned earlier, the A CS has to main tain man y tables. These tables w ere created in cr e ateT ables() metho d. It m ust b e noted that the A CS sends the SQL command to the Database Service (DBS) whic h in turn executes the command on the bac k end P ostgres through JDBC and also propagates the command to other sites [23 ]. Similarly there is a deleteT ables() metho d that deletes the tables when the conference is deleted. The list of tables along with their attributes is giv en b elo w. T able Name A ttributes Access Con trol T able role1 in t, role2 in t, ob jt yp e in t, accessno in t, decisionptr in t UserRole userid in t, roleid in t Ob jectT able ob jectid in t, ob jectt yp eid in t SplRelations userid in t, ob jectid in t, splroleid in t RoleT able roleid in t, rolename v arc har Ob jectT yp eT able ob jectt yp eid in t, ob jectt yp e v arc har AccessT yp eT able accessno in t, accesst yp e v arc har, application in t In ten tionsList v oten um b er in t, action in t, role1 in t, role2 in t, ob jt yp e in t, accessno in t, decisionptr in t The attributes of the Access Con trol T able ha v e b een discussed in c hapter four (refer Section 4.3.1). The role2 attribute can b e n ull and the primary k ey is all the attributes except the decision p oin ter. The UserRole table stores all the v alid user x role bindings. Since a user can bind to more than one role (but at most one role at a time) and a giv en role can ha v e more than one user, the t w o attributes together form the primary k ey The Ob jectT able maps the ob jects to their ob ject t yp es and since a giv en ob ject can b elong to only one ob ject t yp e, the primary k ey for this table is the ob jectid. The mapping b et w een the ob jectid, ob ject name, path and other suc h information is main tained b y the Conference

PAGE 54

47 Con trol Service (CCS). The primary k ey of the SplRelations table is (userid, ob jectid). The RoleT able maps the roleid to the corresp onding role name and is mainly used b y GUI ob jects to list the roles or a sp ecic subsets. The primary k ey for this table is the roleid. The Ob jectT yp eT able is similar to the RoleT able in function and its primary k ey is the ob jectt yp eid. The AccessT yp eT able con tains information ab out the access n um b ers and the applications that can mak e these accesses. Since more than one application can p erform the same t yp e of access, lik e r ead the primary k ey for this table is (accessno, application). This a v oids the need for m ultiple access t yp es lik e V I r ead N otepadr ead etc. More information ab out the applications is main tained b y the CCS. The In ten tionsList con tains the list of p ending access requests. When the decision template is triggered, a new en try is added to this table. The Decision Supp ort Service (DSS) returns a unique votenumb er for eac h decision and this serv es as the primary k ey for the table. In most cases, when the v ote is decided, the A CS has to inform the CCS ab out it. Ho w ev er, if the access relates to one of the tables main tained b y the A CS, then suitable action m ust b e tak en, lik e adding a new en try to one of the tables or mo difying them. The action attribute indicates the t yp e of action to b e p erformed. F or example, the action n um b er ten corresp onds to deleting an en try from the SplRelations table. The other attributes in the tuple indicate whic h en try to delete. In this case, the attributes role2, accessno and decisionptr will b e n ull. The A CS is a w are of only a limited n um b er of accesses. Ho w ev er, eac h application is allo w ed to add its o wn access t yp es. The access n um b ers 1 through 512 ha v e b een reserv ed for DCS services. The CCS uses n um b ers 1 through 50, the A CS uses 51 through 100 and so on. Because of this, the A CS need not kno w what the access n um b er 21 corresp onds to except for the fact that it is one of the accesses sp ecic to CCS. When eac h DCS service is instan tiated for the rst time,

PAGE 55

48 they call the inform the A CS of their access t yp es b y calling the addA c c essT yp e metho d. Eac h table has t w o sets of metho ds for adding, deleting and mo difying en tries. One set directly p erforms these tasks and can b e called only b y friend ly ob jects i.e., the other DCS ob jects. The other set requires information ab out the user making the request and then c hec ks to see if that user (role) has the righ t to p erform the access. Eac h access request is noted on a log le and another en try made when the result b ecames a v ailable. 5.1.1 Conference Con trol Services The CCS ob ject instan tiates the A CS. It is also resp onsible for linking the v arious DCS ob jects. This is done b y passing the instance of eac h service to the constructor as a parameter. This is a v alid approac h b ecause Ja v a passes ob jects b y reference. Since eac h service is dep enden t on others, the startup pro cess requires t w o phases. In the rst phase, all the ob jects are instan tiated. Once this is done, the CSS informs eac h service to pro ceed to phase t w o, whic h means that the other services are up and can b e con tacted. The CCS also informs the A CS if this is a restart instead of a new conference. The A CS can determine this on its o wn b y c hec king for the existence of the tables. This approac h w as not used b ecause the CCS has to kno w this information and if the CCS do es not pass this information, eac h service has to mak e a database query to get it. If the services are b eing restarted, then the cr e ateT ables() metho d is not called. In case of a new conference, the CCS creates t w o roles, A dmin and Memb er b y default and also adds its access t yp es to the AccessT yp esT able. The creator of the conference is b ound to the Admin role. The conference is no w ready to accept new users. 5.1.2 Database Services The DBS exp orts t w o metho ds to access the database. The exe cuteQuery() metho d tak es an SQL query executes it on the bac k end RDBMS and returns

PAGE 56

49 the result in a ResultSet ob ject. This is similar to a SQL cursor [24]. If no tuple matc hes the query then the ResultSet ob ject is n ull. The exe cuteUp date() metho d is more in v olv ed. Up dates ha v e to b e propagated to all sites and the databases in the dieren t site ha v e to b e k ept in sync. Details ab out ho w this is ac hiev ed are a v ailable in Amit Date's thesis [23]. 5.1.3 Decision Supp ort Services The A CS and the DSS ha v e to in teract closely b ecause all decisions are tak en through the DSS. Most access requests that are allo w ed are exp ected to call the decision template that alw a ys returns a p ositiv e answ er, without starting an y v ote. Ho w ev er, these are not handled as sp ecial cases. The DSS exp orts a metho d startV ote() whic h tak es in the decision p oin ter and a message and returns a v ote n um b er. When the v ote is decided, the DSS calls the A CS metho d, r ep ortR esult() Most of the comm unication b et w een the A CS and the DSS is exp ected to b e of this nature. F or b o okk eeping purp oses, a few additional metho ds are also exp orted. The A CS exp orts a getV alidV otes() metho d whic h returns a v ector of v alid v ote n um b ers that are curren tly activ e. The DSS can also c hec k if a particular v ote is still v alid b y calling the isV alid() metho d. The A CS can c hec k the status of a sp ecic v ote b y calling the che ckStatus() metho d of DSS. 5.2 T esting Soft w are testing is a critical elemen t of soft w are qualit y assurance and represen ts the ultimate review of sp ecication, design and co ding [19]. There is a sligh t conrict of in terest in the sense that the success of testing is in iden tifying an as-y et undisco v ered error and the success of the co ding is in deliv ering an error-free program. Most glaring errors w ere caugh t in the co ding stage itself and the testing stage basically serv ed as a review of the sp ecications. The scenarios dev elop ed during the requiremen ts analysis stage serv ed as a c hec k-list and w e sim ulated those scenarios during testing.

PAGE 57

50 5.2.1 Unit T esting Unit testing for the A CS w as a dicult task b ecause most metho ds execute SQL commands whic h require the DBS. A DBS class w as created to test if the SQL commands are passed on correctly Once this w as assured, further testing w as carried out with the DBS. A DSS stub w as created whic h lets the tester decide the result of the v otes. With this stub class, w e ran the scenarios. The main bug detected at this stage w as with the in ten tions list. In the original implemen tation, only those requests that relate to the A CS tables w ere en tered in the in ten tions list and all other v otes' results w ere rep orted to the CCS. The problem arose when the DSS calls the getV alidV otes() metho d whic h did not coun t the non-A CS related v otes as v alid b ecause they w ere not en tered in to the in ten tions list. This problem w as o v ercome b y adding a new action co de whic h corresp onds to "rep ort to CCS" and en tering non-A CS requests with this action n um b er. A CSS stub w as also created and the v arious scenarios sim ulated b y directly calling the metho ds from this class from a runSc enario() metho d. W e selected a subset of the scenarios that w ould co v er all the metho ds and in some cases, their ordering. The runScenario metho d w as mo died for eac h scenario. A part of one suc h scenario is giv en b elo w. Assume that the conference w as created b y user Alice (userid 100) who is b ound to the admin role (roleid 0) b y default. Bob (userid 101) is another user in the DCS instance.

PAGE 58

51 Metho d Callee Commen ts addRole(100,1,"Executiv e") CCS Alice requests to add new role. The DSS returns v ote n um b er 1. rep ortResult(1,1) DSS DSS rep orts that access is allo w ed. The A CS lo oks up the In ten tionsList and adds the en try to roleT able (roleid = 1). addBinding(101,2,101,1) CCS Bob requests to b e b ound to Executiv e role. No en try in A CT. The request is denied. addbinding(100,1,101,1) CSS Alice requests the ab o v e action. DSS returns v ote n um b er 2. rep ortResult(2,1) DSS Request is gran ted. A CS p erforms action. c hec kAccess(101,1,51,25,550) CCS Bob requests to read (accessno 550) a le (ob ject id 51, ob jectt yp e 25) as an Executiv e. DSS returns v ote n um b er 3. c hec kAccess(100,0,51,25,550) CCS Alice requests to read the same le as admin. DSS returns v ote n um b er 4. rep ortResult(4,1) DSS Alice's request is gran ted. rep ortResult(3,0) DSS Bob's request denied. In the ab o v e table, Cal le e refers to the ob ject whic h calls the metho d. This is a part of one of the scenarios and tests addRole, addBinding and c hec kAccess metho ds. Note that some of the accesses are disallo w ed and the A CS handled these rejections as exp ected. 5.2.2 In tegration T esting Once the unit testing w as completed satisfactorily and the CCS w as ready w e w en t ahead with the in tegration testing. W e created conferences through the user in terface pro vided b y the CCS ob ject and ran the same set of scenarios as b efore. One problem encoun tered w as the CCS did not store information ab out the access

PAGE 59

52 request. It exp ected the A CS to return the result of the request immediately Although this is usually the case, once the DSS has b een completed, some access requests ma y require a v ote among the mem b ers and ma y tak e longer to decide. The CCS m ust use some data structure similar to the in ten tions list to store the information. Another problem encoun tered w as with the t w o-phase startup pro cess. The A CS exp ected the CCS to pass the other ob jects as parameters to the constructor. Since the main reason for using the t w o-phase startup w as to ensure that all services are up b efore they start trying to talk to eac h other, the CCS sends these ob jects when calling the goT oSe c ondPhase() metho d. The A CS co de w as mo died to handle this. A few other suc h inconsistencies in the common in terface w ere iden tied and corrected during this stage. Comm unication b et w een the dev elop ers is really imp ortan t and the errors rep orted during in tegration could ha v e b een easily a v oided if the t w o dev elop ers had discussed the in terface in detail b eforehand. On the whole, the curren t implemen tation of A CS for DCS v ersion 2 is fully in tegrated with the DBS and CCS mo dules and all the inconsistencies ha v e b een ironed out. The implemen tation time w as remark ably short b ecause of the extensiv e groundw ork done in requiremen ts analysis and design. In fact, it to ok longer to completely test the mo dule than to implemen t it. The in tegration with DBS and, to a v ery large exten t, CCS w as problem less. The minor problems that cropp ed up w ere due to lac k of comm unication and could ha v e b een a v oided. The dev elop ers of other mo dules that are under dev elopmen t and those y et to b e dev elop ed should ha v e a clear idea of what services are pro vided b y the A CS and should therefore b e able to in teract with A CS without an y problems.

PAGE 60

CHAPTER 6 CONCLUSION The access con trol mo del describ ed in this thesis is used in the Distributed Conferencing System v ersion 2 (DCS v.2). Ho w ev er, this mo del can b e used in an y distributed system that requires highly a v ailable access con trol serv ers and user driv en decision making capabilities. As seen in c hapter four, this mo del satises man y in teresting prop erties of access con trol systems and supp orts user-dened v oting templates. With the curren t design, the Conference Con trol Services has b een able to supp ort conferences, starting from creation, through the da y-to-da y running of the conference till deletion. The access scenarios dev elop ed to help understand the requiremen ts pro vided exhaustiv e test cases. Although the exact design of the Decision Supp ort Service (DSS) is not y et nailed do wn, there are quite a few p ossible templates that ha v e to b e dened as a part of the requiremen ts and the DSS is exp ected to allo w users to dene their o wn templates. The mo dular structure of the DCS allo ws us to ignore the implemen tational details of the templates and refer to the template index in the A CS. Adding new templates and mo difying existing ones is in turn an access to the templ ates ob ject and is con trolled b y the A CS. The Database services (DBS) pro vide the bac k end database managemen t capabilities whic h are used b y the A CS. It m ust b e noted that actions lik e creating a new database etc. is also an A CS con trolled action. Hence all the services are in ter-link ed and are able to in teract with one another. There are a few mo dications that can impro v e the p erformance of A CS and also pro vide b etter service. F or instance, the access con trol table is a replicated database. While this ensures quic k resp onse, it can also add to the net w ork trac 53

PAGE 61

54 and an up date ma y tak e some time to reac h a particular site whic h in turn ma y lead to confusion. T o a v oid this, it is a go o d idea to ha v e a partitioned database. Eac h ob ject is lo cated in one of the sites in the DCS instance and storing access con trol information ab out that ob ject in that site alone is an idea similar to the Access con trol lists discussed in c hapter t w o. Another area that requires further w ork is the special per missions While the curren t implemen tation supp orts sp ecial privileges to sp ecic users, the concept is not clearly dened and more w ork is needed in that direction. It is also p ossible for a careless user to lo c k a particular ob ject from b eing used b y tamp ering with the templates. W e m ust pro vide some mec hanism for the conference to undo or redo an y action. On the whole, the A CS implemen ted for the DCS is a ma jor step to w ards incorp orating demo cratic mec hanisms to access con trol b y giving the mem b ers of the conference more con trol o v er the conference. While more w ork needs to b e done to complete the task, this thesis gets us started in that direction and it is hop ed that the task is tak en closer to completion in the near future.

PAGE 62

REFERENCES [1] W ei Hu, DCE Se curity Pr o gr amming O'Reilly & Asso ciates, Sebastop ol, CA, 1995. [2] R. E. Newman, C. L. Ramirez, H. P elim uhandiram, M. Mon tes, M. W ebb, and D. L. Wilson, \A Brief Ov erview of the DCS Distributed Conferencing System", in Pr o c e e dings of Summer USENIX Confer enc e USENIX, 1991, pp. 437{452. [3] S. J. Green w ald, The Distribute d Comp artment Mo del for R esour c e Management and A c c ess Contr ol Ph.D. dissertation, Univ ersit y of Florida, 1994. [4] P H. W o o d and S. G. Ko c han, UNIX System Se curity Ha yden Bo oks, Indianap olis, 1985. [5] Charlie Kaufman, Radia P erlman, and Mik e Sp eciner, Network Se curity, Private Communic ation in a Public World Pren tice Hall PTR, Upp er Saddle Riv er, NJ, 1995. [6] Charles P Preeger, Se curity in Computing Pren tice Hall Inc., Upp er Saddle Riv er, NJ, 1996. [7] B. W. Lampson, \Protection," in Pr o c e e dings of 5th Princ eton Symp osium on Information Scienc es and Systems Princeton, 1971, pp. 437{443. [8] G. S. Graham and P J. Denning, \Protection{Principles and Practice," in Pr o c e e dings of Spring Joint Computer Confer enc e AFIPS, 1972, pp. 417{429. [9] M. A. Harrison, W. L. Ruzzo, and J. D. Ullman, \Protection in Op erating Systems," Communic ations of the A CM v ol. 19, no. 8, pp. 461{471, August 1976. [10] P E. Ammann and R. S. Sandh u, \Safet y Analysis for the Extended Sc hematic Protection Mo del," in Pr o c e e dings of IEEE Symp osium on R ese ar ch in Se curity and Privacy IEEE, 1991, pp. 87{97. [11] R. S. Sandh u, \The T yp ed Access Matrix Mo del," in Pr o c e e dings of IEEE Symp osium on Se curity and Privacy IEEE, 1992, pp. 122{136. 55

PAGE 63

56 [12] R. S. Sandh u, \The Sc hematic Protection Mo del: Its Defnitions and Analysis for Acyclic A tten uating Sc hemes," Journal of A CM v ol. 36, no. 2 pp. 404{432 1988. [13] R. S. Sandh u and G. S. Suri, \Implemen tation considerations for the T yp ed Access Matrix in a Distributed En vironmen t," in Pr o c e e dings of the 15th NIST-NCSC National Computer Confer enc e NIST, 1992, pp. 221{235. [14] Randy Cho w and Theo dore Johnson, Distribute d Op er ating Systems & A lgorithms Addison-W esley Reading, MA, 1997. [15] Susan Stepney and Stephen P Lord, \F ormal Sp ecifcation of an Access Con trol System," Softwar e{Pr actic e and Exp erienc e v ol. 17, no. 9 pp. 575{593 1987. [16] Da vid F. F erraiolo, Janet A. Cugini, and D. Ric hard Kuhn, \Role-based Access Con trol (RBA C): F eatures and Motiv ations," National Institute of Standards and T ec hnology Gaithersburg, 1992. [17] Da vid F erraiolo and Ric hard Kuhn, \Role-based Access Con trol," in Pr o c e e dings of the 15th NIST-NCSC National Computer Confer enc e NIST, 1992, pp. 437{443. [18] leen F risc h, Essential System A dministr ation O'Reilly & Asso ciates, New Y ork 1996. [19] Roger S. Pressman, Softwar e Engine ering-A Pr actitioner's Appr o ach McGra w-Hill, New Y ork, 1997. [20] Donald C. Gause and Gerald M. W ein b erg, Exploring R e quir ements: Quality b efor e Design Dorset House, New Y ork, 1989. [21] Ian Sommerville, Softwar e Engine ering Addison-W esley Harlo w, England, 1995. [22] Bruce Ec k el, Thinking in Java Addison-W esley Upp er Saddle Riv er, NJ, 2000. [23] Amit V. Date, Implementation of Distribute d Datab ase and R eliable Multic ast for Distribute d Confer encing System version 2 Master's thesis, Univ ersit y of Florida, 2001. [24] Ramez Elmasri and Shamk an t B. Na v athe, F undamentals of Datab ase Systems Addison-W esley Upp er Saddle Riv er, NJ, 1994.

PAGE 64

BIOGRAPHICAL SKETCH Vija y Manian w as b orn in Chennai, India, in 1977, the son of P adma and S V S Manian. He has t w o elder sisters, Chithra and Vidy a. After completing his primary sc ho oling in Chennai, he attended Ida Scudder Sc ho ol, V ellore, India, where he completed his X. He completed high sc ho ol from P adma Seshadri Bala Bha v an Junior College, Chennai, in 1995. He receiv ed a Bac helor of Engineering degree in computer science and engineering from the Univ ersit y of Madras in 1999. He then decided to pursue his master's degree in computer science from the Univ ersit y of Florida's Computer and Information Sciences and Engineering Departmen t in 1999. He is curren tly w orking on his Ph.D. in computer engineering. 57


Permanent Link: http://ufdc.ufl.edu/UFE0000570/00001

Material Information

Title: Access control model for distributed conferencing system
Physical Description: Mixed Material
Language: English
Creator: Manian, Vijay ( Dissertant )
Newman, Richard E. ( Thesis advisor )
Publisher: University of Florida
Place of Publication: Gainesville, Fla.
Publication Date: 2002
Copyright Date: 2002

Subjects

Subjects / Keywords: Computer and Information Science and Engineering thesis, M.S
Computer conferencing   ( lcsh )
Computer networks -- Access control   ( lcsh )
Dissertations, Academic -- UF -- Computer and Information Science and Engineering
Teams in the workplace -- Data processing   ( lcsh )

Notes

Abstract: In today's world, high-speed networks have made geographical distances meaningless and Small Office Home Office (SOHO) is more than the latest buzzword. The Distributed Conferencing System (DCS) is designed to support distributed cooperative work by providing an infrastructure that allows the users to share objects, run common applications, exchange voice and video and view each other's screens. Running collaboration-aware applications on such a system provides the users with better tools for collaborative work. In such a system, access control using the traditional models is ineffective. A popular model is the Access Control Matrix (ACM), which uses a two-dimensional matrix with the active subjects corresponding to the rows and the passive objects corresponding to the columns. Each cell indicates the types of access permissible for that subject on that object. Usually, the answer to an access request is an immediate yes or no. The ACM is often very large to maintain and is compressed by grouping subjects into domains or roles and objects into object types. Popular operating systems like UNIX restrict the set of possible accesses and allow only read, write and execute accesses. Using this model in a distributed environment imposes several limitations on the system. The scope of this work is to extend this model to better suit the requirements of DCS. First, each entry in the ACM also includes a decision pointer which points to a decision making template that has to be processed to arrive at a decision. This models real-life scenarios more closely in which some accesses are permissible if certain conditions are met. These templates are maintained by the Decision Support Service (DSS) of DCS. Eventually, this system can support process work flow model and separation of duty. Secondly, we group users into roles and objects into object types to compress the matrix. We also use a distributed database in the back-end to store the ACM, resulting in a truly distributed system. Another modification is the notion of special permissions which enable us to capture one-to-one relationships between users and objects, like ownerships. This thesis is a part of the DCS project and the access control mechanism described is used in DCS version 2.0. The advantage here is that it supports traditional ACM while providing additional decision-making templates. It is hoped that this extended ACM is used in other systems that require a more democratic voting process.
Abstract: access, control, distributed
General Note: Title from title page of source document.
General Note: Includes vita.
Thesis: Thesis (M.S.)--University of Florida, 2002.
Bibliography: Includes bibliographical references.
General Note: Text (Electronic thesis) in PDF format.

Record Information

Source Institution: University of Florida
Holding Location: University of Florida
Rights Management: All rights reserved by the source institution and holding location.
System ID: UFE0000570:00001

Permanent Link: http://ufdc.ufl.edu/UFE0000570/00001

Material Information

Title: Access control model for distributed conferencing system
Physical Description: Mixed Material
Language: English
Creator: Manian, Vijay ( Dissertant )
Newman, Richard E. ( Thesis advisor )
Publisher: University of Florida
Place of Publication: Gainesville, Fla.
Publication Date: 2002
Copyright Date: 2002

Subjects

Subjects / Keywords: Computer and Information Science and Engineering thesis, M.S
Computer conferencing   ( lcsh )
Computer networks -- Access control   ( lcsh )
Dissertations, Academic -- UF -- Computer and Information Science and Engineering
Teams in the workplace -- Data processing   ( lcsh )

Notes

Abstract: In today's world, high-speed networks have made geographical distances meaningless and Small Office Home Office (SOHO) is more than the latest buzzword. The Distributed Conferencing System (DCS) is designed to support distributed cooperative work by providing an infrastructure that allows the users to share objects, run common applications, exchange voice and video and view each other's screens. Running collaboration-aware applications on such a system provides the users with better tools for collaborative work. In such a system, access control using the traditional models is ineffective. A popular model is the Access Control Matrix (ACM), which uses a two-dimensional matrix with the active subjects corresponding to the rows and the passive objects corresponding to the columns. Each cell indicates the types of access permissible for that subject on that object. Usually, the answer to an access request is an immediate yes or no. The ACM is often very large to maintain and is compressed by grouping subjects into domains or roles and objects into object types. Popular operating systems like UNIX restrict the set of possible accesses and allow only read, write and execute accesses. Using this model in a distributed environment imposes several limitations on the system. The scope of this work is to extend this model to better suit the requirements of DCS. First, each entry in the ACM also includes a decision pointer which points to a decision making template that has to be processed to arrive at a decision. This models real-life scenarios more closely in which some accesses are permissible if certain conditions are met. These templates are maintained by the Decision Support Service (DSS) of DCS. Eventually, this system can support process work flow model and separation of duty. Secondly, we group users into roles and objects into object types to compress the matrix. We also use a distributed database in the back-end to store the ACM, resulting in a truly distributed system. Another modification is the notion of special permissions which enable us to capture one-to-one relationships between users and objects, like ownerships. This thesis is a part of the DCS project and the access control mechanism described is used in DCS version 2.0. The advantage here is that it supports traditional ACM while providing additional decision-making templates. It is hoped that this extended ACM is used in other systems that require a more democratic voting process.
Abstract: access, control, distributed
General Note: Title from title page of source document.
General Note: Includes vita.
Thesis: Thesis (M.S.)--University of Florida, 2002.
Bibliography: Includes bibliographical references.
General Note: Text (Electronic thesis) in PDF format.

Record Information

Source Institution: University of Florida
Holding Location: University of Florida
Rights Management: All rights reserved by the source institution and holding location.
System ID: UFE0000570:00001


This item has the following downloads:


Full Text











ACCESS CONTROL MODEL FOR DISTRIBUTED CONFERENCING SYSTEM


By

VIJAY MANIAN















A THESIS PRESENTED TO THE GRADUATE SCHOOL
OF THE UNIVERSITY OF FLORIDA IN PARTIAL FULFILLMENT
OF THE REQUIREMENTS FOR THE DEGREE OF
MASTER OF SCIENCE

UNIVERSITY OF FLORIDA


2002















ACKNOWLEDGMENTS

I would like to thank Dr.Newman for getting me started on this project. I

would like to express my gratitude to Dr.Thebaut for his willingness to help me

whenever I had a problem. I would also like to thank all the DCS group members,

past and present, for their invaluable contributions without which I would not have

been able to complete this thesis. Special thanks are due to my parents and my

friends for their support and encouragement.















TABLE OF CONTENTS

page

ACKNOW LEDGMENTS ............................. ii

ABSTRACT ....................... ............ vi

CHAPTERS

1 INTRODUCTION .................... ....... 1

1.1 Overview ................... ............. 1
1.2 D efinitions . . . . . . . 1
1.3 Problem Statement .......................... 3
1.4 The Distributed Conferencing System ................ 4
1.5 Thesis Organization ................ ......... 7

2 SURVEY OF RELEVANT WORK ......... ......... .... 9

2.1 Introduction . . . . . . . 9
2.2 Access M atrix Model ......................... 10
2.2.1 Description .................. ...... 10
2.2.2 Harrison-Ruzzo-Ullman Result ...... .......... 11
2.2.3 Typed Access Matrix ......... ......... .... 12
2.2.4 Modifications on AC'i ........ ............ 13
2.2.5 Com m ents .................. ........ 13
2.3 ADMIRAL Model .................. ........ 14
2.3.1 Introduction . . . . . .... 14
2.3.2 Description. .................. ....... .14
2.3.3 Comments .................. ........ 15
2.4 OSF Distributed Computing Environment . . ..... 16
2.4.1 Introduction . . . . . .... 16
2.4.2 Description. .................. ....... .16
2.4.3 Com m ents .................. ........ 18
2.5 Role-Based Access Control .................. ..... 18
2.5.1 Introduction . . . . . .... 18
2.5.2 Description. .................. ....... .19
2.5.3 Comments .................. ........ 20
2.6 Access Control in UNIX Operating System . . 20
2.6.1 Introduction .. .. ... .. .. .. .. .. .. .... 20
2.6.2 Description. .................. ....... 20









2.6.3 Com m ents .................. ........ 22
2.7 Distributed Compartment Model .............. 22
2.7.1 Introduction .. .. ... .. .. .. .. .. .. .... 22
2.7.2 Description. .................. ....... 23
2.7.3 Comm ents .................. ........ 24

3 REQUIREMENTS .................... ...... 26

3.1 Introduction .................. ........... 26
3.2 The Process .................. ........... 26
3.3 A Sample Scenario .................. ....... 27
3.4 Requirements of the ACS .................. .. 29
3.5 Interactions with other DCS services ............... .31
3.5.1 Database Services .................. .. 31
3.5.2 Conference Control Services ............... 32
3.5.3 Decision Support Services .................. .32
3.6 Interesting Issues .................. ........ 33
3.6.1 Adm in role .. .. .. ... .. .. .. .. .. .. .... 33
3.6.2 Modifying the ACT .................. .... 33
3.6.3 Separation of Duty .................. ..... 33
3.7 Summary .................. ............ 34

4 DESIGN ................... ........... .... 35

4.1 Introduction ........ .... ..... ....... 35
4.2 Formal Specification of ACS Model ................ 35
4.3 Database Table Schema .................. .... 37
4.3.1 Access Control Table .................. .. 37
4.3.2 Other Tables .................. ....... 39
4.4 DCS-defined Object types and Access types . . 40
4.5 Check-Access Function .................. ... 40
4.6 Interactions with other Modules .................. .41
4.6.1 Conference Control Services ................ .41
4.6.2 Database Services .................. .. 42
4.6.3 Decision Support Services .................. .42
4.7 Alternate Design .................. ........ 42
4.7.1 V iews . . . . . . .... 43

5 IMPLEMENTATION AND TESTING .................. 45

5.1 Implementation of ACS .................. .. 46
5.1.1 Conference Control Services ................ .48
5.1.2 Database Services .................. .. 48
5.1.3 Decision Support Services .................. .49
5.2 Testing . . . . . . . .... 49
5.2.1 Unit Testing .. .. ... .. .. .. .. .. .. .... 50
5.2.2 Integration Testing .................. ..... 51









6 CONCLUSION ...................... ........ 53

REFERENCES ................................... 55

BIOGRAPHICAL SKETCH ............................ 57















Abstract of Thesis Presented to the Graduate School
of the University of Florida in Partial Fulfillment of the
Requirements for the Degree of Master of Science



ACCESS CONTROL MODEL FOR DISTRIBUTED CONFERENCING SYSTEM



By

Vijay Manian

December 2002

Chair: Richard E. Newman
Major Department: Computer and Information Science and Engineering

In today's world, high-speed networks have made geographical distances mean-

ingless and Small Office Home Office (SOHO) is more than the latest buzzword.

The Distributed Conferencing System (DCS) is designed to support distributed

cooperative work by providing an infrastructure that allows the users to share

objects, run common applications, exchange voice and video and view each other's

screens. Running collaboration-aware applications on such a system provides the

users with better tools for collaborative work.

In such a system, access control using the traditional models is ineffective. A

popular model is the Access Control Matrix (AC'i), which uses a two-dimensional

matrix with the active subjects corresponding to the rows and the passive objects

corresponding to the columns. Each cell indicates the types of access permissible

for that subject on that object. Usually, the answer to an access request is an

immediate yes or no. The AC'i is often very large to maintain and is compressed

by grouping subjects into domains or roles and objects into object types. Popular









operating systems like UNIX restrict the set of possible accesses and allow only

read, write and execute accesses. Using this model in a distributed environment

imposes several limitations on the system.

The scope of this work is to extend this model to better suit the requirements

of DCS. First, each entry in the AC'i also includes a decision pointer which points

to a decision making template that has to be processed to arrive at a decision.

This models real-life scenarios more closely in which some accesses are permissible

if certain conditions are met. These templates are maintained by the Decision

Support Service (DSS) of DCS. Eventually, this system can support process work

flow model and separation of duty. Secondly, we group users into roles and objects

into object '," to compress the matrix. We also use a distributed database in

the back-end to store the AC' resulting in a truly distributed system. Another

modification is the notion of special permissions, which enable us to capture

one-to-one relationships between users and objects, like ownerships.

This thesis is a part of the DCS project and the access control mechanism

described is used in DCS version 2.0. The advantage here is that it supports

traditional AC'i while providing additional decision-making templates. It is hoped

that this extended AC'i is used in other systems that require a more democratic

voting process.















CHAPTER 1
INTRODUCTION

1.1 Overview

Distributed computing is today's solution to the need to share data. No one

can doubt the need for safe, reliable and efficient communication. Individuals

communicate to achieve their day-to-day desires and requirements. Organizations

communicate about their business goals [1]. The Distributed Conferencing System

(DCS) is a distributed package that provides an infrastructure for real-time

cooperative work. The conferences may be long-term or short-term and are

dynamic in that their constituency may change over time; they may also split or

merge. Conference control is hierarchically democratic, and DCS's architecture is

hierarchically distributed [2]. Access to data, programs, and other resources of the

system is a serious concern.

The security model used on most distributed systems is an old one, dating

back to simpler times when most computer systems were centralized [3]. In such

systems, there is a centralized authority that manages access to all objects in the

system. In operating systems like UNIX [4], the users have only three types of

access on any object namely read, write and execute. The access control mechanism

in DCS is intended to provide a truly distributed solution that supports a much

wider range of access types.

1.2 Definitions

The following terms are used throughout this work and it is important to be

clear about their meanings. In general, they correspond to the standard meanings

used in the real world.









User This is an entity in the system that initiates action and (in the context
of access control) requests to access objects. This term usually refers to a
human being.

Subject This represents an active user process that is allowed to perform some
action within the system on behalf of the user.

Object This is a passive entity in the system. Users can perform various
accesses on them. Examples of objects are documents, files and DCS system
specific tables.

Application This is a program that the user launches from within the system
to work on the objects.

Collaboration-ware These are applications that are designed to support
collaborative work. Therefore these applications will have a better access
control features than the regular off-the-shelf applications.

DCS-aware Applications These are applications that are specifically designed
to work within the DCS. These applications can use the features of DCS like
event notification or new access type registration.

Role This is a named group of subjects. Roles can also be viewed as a
collection of job functions. A particular subject can bind to any number of
roles but at any point of time, the subject can be bound to only one role. It
must be noted that role as used here is slightly different from role as used in
Role-based access control (refer Section 2.5) because there is no notion of a
role-hierarchy in the DCS model.

Object T,,1', This is a named group of objects. A particular object can belong
to only one object type.

Decision Template Pointer This is a pointer to some decision making
mechanism like voting that must be initiated in order to get a result.

It must be noted that while the user-role relationship is a many-to-many relation,

i.e., a user can belong to many roles and a role can have many users, the object-

object type relationship is many to one. While any number of objects can belong

to one object type, an object can belong to only one object type. The decision

template pointer can point to any type of decision template that has been defined









earlier. This allows the users to specify a template that suits their conference

policy.

1.3 Problem Statement

A popular model to enforce access control is the Access Control Matrix (ACM).

The access matrix can be represented as a list of triples, having the form
object, rights>. In general, the access control matrix is sparse and/or redundant.

Searching a large number of such triples in a sparse matrix is inefficient. Therefore

an Access Control List (ACL) associated with each object, which lists every subject

or domain allowed to use that resource, is normally used [5].

The scope of this work is to extend the idea of access control matrices to

support the distributed architecture of DCS. The drawbacks of the traditional

approach are listed below.


1. In a distributed system, the resources are distributed across the network
and it is not possible by traditional ways to uniformly control access to all
resources without having a centralized server. The regular AC'i or ACL
depends on a centralized decision making authority. This is not in tune with
the distributed architecture of the DCS. We must find a way to implement
the AC'i in multiple sites and keep them consistent with one another.

2. In a system with a large number of subjects and objects, it is much more
efficient to group the subjects and objects. Traditional access control mecha-
nisms do not support such group control and depend on individual control.

3. A user should be able to log into the system from any site and still per-
form all his/her duties. This is not possible in normal systems without a
centralized service point.

4. The AC'i does not allow the conference members to decide on access
requests. I.e., there is no way to add pointers to decision-making templates
that are activated whenever the concerned access requests are made. This
models the real world situations more closely; for example, Bob can modify
the group constitution if two-thirds of the members agree to the amendment.
Such scenarios are very common and group decision-making should be a vital
part of access control.









5. Although we define access rights with respect to groups of subjects and
objects (i.e., roles and object types) it may be necessary to define more direct
relationships like object ownerships. The current access control mechanisms
either allow only role based definitions or no roles at all.

The core requirement is a distributed system that is capable of making

access control decisions at the individual sites without referring to a central

database. The system should also support Role-Based Access Control (RBAC)

and democratic decision-making. In addition, it should respond to access control

queries from other DCS services (refer Section 1.4). Similarly, it can make use of

the various services provided by the other modules.

1.4 The Distributed Conferencing System

DCS provides a distributed, real-time conferencing facility for cooperative

work. The first version of DCS, referred to as DCS v.1, had a small set of prede-

fined roles and only members who are bound to the voter role can vote. While

DCS v.1 came with a set of applications for shared editing of documents, exporting

user's window and discussions among the users, it also supported stand-alone

off-the-shelf applications [2].

The next version of DCS, referred to as DCS v.2, is a major step from the first

version and supports a much wider range of voting mechanisms, limited RBAC,

synchronous and asynchronous notification, and distributed database services. The

architecture of DCS v.2 is shown in figure 1.1. A brief description of each service is

given below:


1. Conference Control Services (CCS) This is the module responsible for
conference and application control. This module instantiates the other
modules and the clients interact with the other services mainly through
the CCS. Tasks like merging two instances of DCS or sites or conferences
and splitting of the instance or a site or a conference is handled by this
module. It also supports applications by registering them and maintaining
the relevant information. The CCS interacts with the secure messaging and
the cryptographic layers during user login. User's access control requests are









routed through the CCS. The CCS also allows the user to import and export
object, add new members and start sub-conferences.

2. Notification Services (NTF) The NTF provides asynchronous event
notification to registered users. Users can define new event types and register
to be notified on events. The various services and applications running in
the instance raises events as and when they occur and the NTF maintains a
global and local database in which is stores the users to be notified on each
event along with the delivery method.

3. Database Service (DBS) The DBS makes use of a backed Database
Management System (DBMS) to maintain the tables of all the DCS services
and applications. Most tables are stored as partially replicated distributed
databases and the DBS uses group multicast to ensure eventual consistency
among all member sites.

4. Access Control Services (ACS) The ACS, as the name -. -'-, controls
access to all the objects in the conference. It makes use of decision templates
of the DSS to provide group decision-based access control. This results
putting the control of the conference in the hands of the conference users.
The ACS stores its tables in a database through the DBS. The ACS allows
applications to register new access types. This allows more fine-grain access
control if the application supports it.

5. Decision Support Service (DSS) The DSS maintains the decision templates
that are defined for that conference. It allows users to define new templates
and also modify existing templates. It also executes these templates whenever
required, i.e., it initiates and conducts votes among the members and returns
the result to whoever requested the vote.

6. Secure Communications Services (SCS) The SCS handles all the security
related issues like user authentication, encryption and decryption of messages,
storage and retrieval of keys etc. Like all services, this too makes extensive
use of the DBS to keep the information in the various sites up to date.

One important aspect of DCS is the notion of vestibule conference. This is similar

to the lounge and users enter the site through this conference before entering their

conferences. The vestibule conference corresponds to the site as a whole and the

advantage with this view is that site management is handled in the same way

as conference management. Therefore, we do not need a separate access control









module for sites. Most distributed systems have centralized authorities for all its

services. However, DCS distributes authority among the sites.

There are a few major differences between traditional schemes and the ACS in

DCS. Traditional access control schemes have the following service cycle:


1. Receive request

2. Validate request

3. Carry out request

4. Send reply

However, the use of decision templates in ACS adds an additional step to the cycle

and the existence of NTF alters the last step of the cycle. The service cycle of the

DCS model is as follows:


1. Receive request

2. Validate request

3. Authorize request via group decision (asynchronous)

4. Carry out request

5. Notify interested parties. This need not just be the requester but anyone who
is registered to be notified on the event.

In traditional systems that use synchronous communication, response time is an

issue to be considered. However, in DCS, on account of the group decision step,

the entire process is essentially asynchronous and therefore the ACS must store the

information about the request somewhere till it gets a result from the DSS.

The ACS interacts with all the other five modules and provides various

services to the users. The DCS architecture requires the ACS to allow decisions

to be made on access control requests at the source site itself. This coupled with

the decision templates makes the ACS an interesting study in itself. The model







7

used here is not specific to DCS and can be used in any distributed system that

supports group decision-making mechanisms.

1.5 Thesis Organization

This thesis is organized as follows. Chapter 2 is a survey of the relevant work

in the field. Chapter 3 is a description of the requirements for the access control

module in DCS. Chapter 4 is a description of the design satisfying the requirements

of chapter three that we developed. Chapter 5 is a discussion of the various

implementation issues, testing procedures, and test results. Chapter 6 concludes

the thesis.













Applications


Figure 1.1: Architecture of DCS















CHAPTER 2
SURVEY OF RELEVANT WORK

2.1 Introduction

This chapter surveys some of the work in access control that is relevant

to the Access Control Services (ACS) module of DCS. Protection of objects is

complex because the number of access points may be large, there may be no central

authority through which all access requests pass, and the kind of access is not

simply limited to read, write, or execute. According to Pfleeger [6], there are

several complementary goals in such a mechanism.


Check every access. We may want to revoke a user's privilege to access an
object. If we have previously authorized the user to access the object, we do
not necessarily mean the user should retain indefinite access to the object.

Allow least privilege. A subject should have access to the smallest number
of objects necessary to perform some task. Not allowing access to unneces-
sary objects guards against security weaknesses if a part of the protection
mechanism should fail.

Verify acceptable usage. The final decision on an access request is a yes-no
decision. Of more interest is checking that the activity to be performed on an
object is appropriate.

In the following sections we look at various protection mechanisms. First we

will consider the Access Matrix model. We also describe certain modifications like

Access Control Lists and Capability lists along with the Graham-Denning and

Harrison-Ruzzo-Ullman models. Next we will review the access control scheme

in ADMIRAL, a distributed computing based server system. Next comes OSF

Distributed Computing Environment. We will then examine the UNIX operating









system. Finally we will consider the Distributed Compartment Model for resource

management and access control proposed by Steven Greenwald.

2.2 Access Matrix Model

The access matrix model is based on an operating system view of security. It

was originally described by Lampson [7]. Graham and Denning [8] constructed a

model having generic protection properties. This model is simple and is widely

used as the basis for many security systems [6].

2.2.1 Description

The access matrix model as described by Graham-Denning has the following

three components.


1. A set of passive objects.

2. A set of subjects that may actively manipulate the objects. Subjects are
themselves composed of two things: a process and a domain. A domain is a
set of constraints determining how subjects may access objects. Subjects may
also be objects at particular times.

3. A set of rules governing how subjects may actively manipulate the passive
objects.

The protection state of the system is represented as an access control matrix

(ACM). The AC'i is a table in which each row represents a subject, each column

represents an object, and each entry defines the access rights between the subject

and object. For each object, one subject designated as the owner has special rights;

for each subject, another subject designated the controller has special rights.

In this model, there are eight primitive protection rights called commands that

can be issued by subjects, with effects on other subjects or objects.


Tiif, access right allows the subject to transfer one of its rights to another
subject. Each right can be transferable or non-transferable. Only transferable
rights can be transferred.









Grant access right allows the owner of the object to grant any access right for
the object to another subject.

Delete access right allows a subject (S1) to delete a right of another subject
(S2) for an object (o). This is allowed only if S1 is the owner of o or the
controller of S2.

Read access right allows a subject (S1) to determine the current access rights
of another subject (S2) for an object (o). This is allowed only if S1 is the
owner of o or the controller of S2.

Create object allows the commanding subject to create a new object.

Create subject, delete object and delete subject. The interpretations of these
commands are what their names imply.

The above rules provide the basic framework required to design a protection

system. We can now look at a few extensions and modifications of this model that

have found widespread use.

2.2.2 Harrison-Ruzzo-Ullman Result

Harrison, Ruzzo and Ullman [9] proposed a variation on the Graham-Denning

model that answered several questions concerning what protection systems can

determine. The HRU model is very similar to Graham-Denning model and consists

of a finite set of generic rights, R and a finite set C of commands where each

command involves conditions and primitive operations. The primitive operations

are the same as in Graham-Denning model.

Harrison et al. derived two important results that have major implications

for designers of protection systems. The first result states that in a system, where

commands are restricted to a single operation each, it is possible to decide whether

a given subject can ever obtain a particular right to an object. The second result

states that if commands are not restricted to one operation each, it is not always

decidable whether a given protection system can confer a given right.









2.2.3 Typed Access Matrix

Ravi Sandhu and others have worked on modifying the HRU model to make

the safety problem decidable while at the same time maximizing the expressing

power [10]. The Typed Access Matrix (TAM) [11] defined by Sandhu combines

strong safety properties for propagation of access rights of Schematic Protection

Model [12] with the natural expressive power of the HRU model. TAM is obtained

by incorporating strong typing into the HRU model [13]. It is important to

understand that the types and rights are specified as part of the system definition.

The system administrator specifies the following sets for this purpose:


a finite set of access rights denoted by R, and

a finite set of object types denoted by T.

The protection state is a TAM system is given by the four-tuple (OBJ, SUB, t,

AM) interpreted as follows:


OBJ is the set of objects.

SUB is the set of subjects, SUB C OBJ.

t : OBJ -* T, is the tL/,' function which gives the type of every object.

AM is the access matrix. We have AM[S, O] C R where S is a subject and
O is an object.

The protection state of the system is changed by means of TAM commands. Each

TAM command has the following format:
command a(X1 : t1, X2 t2, Xk i tk)

if ri E [X,, Xol] A r2 E [X2, X02] A .. A r, E [Xs, Xo]

then opi; op2; ...;''

end
Here a is the name of the command; Xi are formal parameters whose types are ti;

ri are rights. Each .,p is one of the primitive operations listed below:










enter r into [X5, Xo] delete r from [X,, Xo]

create subject X, of type t, delete subject X,

create object Xo of type to delete object Xo
The rights, types and commands define the system scheme. The scheme

can be modified only by the system administrator, who is not considered to be a

part of the system. The type of an object is fixed and cannot be changed within

the system. Sandhu has proved that TAM has considerable expressive power. A

TAM in which none of the commands use any of the delete operations is called

Monotonic TAM (MTAM). The right leak problem in acyclic MTAM is decidable

[11].

2.2.4 Modifications on AC'i

The above models do not specify what the particular access rules are, and are

therefore very flexible. However, this makes it very difficult to verify the security

of the system and according to the HRU result, it may even be impossible to

decide. Moreover, the AC'i itself is usually a very sparse matrix. For efficiency

and organizational purposes, ACM'i- need to be partitioned and implemented

independently [14]. The model is usually implemented in one of the following ways:


1. CIOwIi;li;t list, where each subject is given a list of objects along with the
allowed accesses for each of these objects. It is analogous to a ticket to a
movie and cannot be duplicated.

2. Access control list, where each object has a list of all subjects that have access
to the object and the allowed access for each subject. This implementation is
very popular and is used in many systems.

2.2.5 Comments

The simplicity of the model makes it a popular choice in many systems. It

is usually implemented as an ACL. In some distributed systems, Capability lists

are used. Each subject carries a token which authenticates the subject and also

contains the access privileges allowed for that subject.









2.3 ADMIRAL Model

2.3.1 Introduction

ADMIRAL is a collaborative project carrying out research into the use and

management of high performance networks. Stepney and Lord [15] have proposed

an access control model for ADMIRAL which can be used in other systems as

well. This model allows users to log in to a distributed computing system and

make requests for services in any part of the system, without having to provide

any more information about themselves. All access control decisions are handled

automatically and remain invisible to the user unless access is refused.

2.3.2 Description

In a multi-administration network, several autonomous access control systems

normally interact. This leads to frustration for both administrators and users.

The ADMIRAL model allows users and services from different administrations to

communicate with each other, while still allowing administrators to retain control

of their own parts of the network.

A system based on this model will have the properties listed below.


1. Autonomous administrations can work with each other, but still retain
control over their own facilities.

2. Users' access to services can be controlled, even when the user and the service
fall under different administrations. This control is invisible to users, unless
they try to access services not available to them.

3. An administrator can make use of another's facilities, if they both agree.

4. Multiple levels of security are available to users and administrators. They can
insist on a particular level for certain operations.

Principals make requests for services. Servers provide services. A Client handles

requests for a principal and passes it on to a server. Principals have access rights,

permissions to make certain requests of certain servers. Authorities provide









access control functions. They store statements about principals' access rights.

Statements say things like 'JOHN has READ access to FILEx'.

Authorities are used by servers to check the access rights of principals, and by

clients to gain access to servers for principals. Authorities can obtain and generate

statements for other authorities and for entities. Each client and server has a local

authority, which it trusts to make appropriate access control decisions. These

entities will not use any other authority directly.

An entire client-server cycle is known as a transaction and takes place as

follows (refer Figure 2.1). The principal makes a request for some service via

a client (1). The client makes the request on the principal's behalf (2). The

request goes through the Client's Local Authority (CLA). The CLA holds cached

statements about the principal and server. These are obtained from its own store

and optionally, from other trusted authorities (3).

The request is passed on (4) to the Server's Local Authority (SLA) which

checks the access right, using its cached statements. These are obtained from the

CLA's cache, and optionally from its own store and from other trusted authorities

(5). If the access conditions have been fulfilled, the request is passed on to the

server for processing (6). Further exchange of data may occur after this (7).

2.3.3 Comments

The ADMIRAL model is a relatively simple system that makes use of remote

procedure calls across the networks to communicate. There are a few drawbacks in

the model. On account of caching of statements, if a particular right of a principal

is removed, it has to be deleted from caches of all the trusted authorities. This

is a major task and may increase the network traffic. Caching may violate the

check every access goal of access control systems. Another important issue is

trust. The authors say that trust is not a transitive relation. If this were so, then

all authorities may end up trusting all the others. The issue of trust is not fully










Principal

1

Client Server

2 6
47
Client's Server's
Local Local
Authority Authority
3 5




Other Authorities

Figure 2.1: Communication paths in a Transaction


solved. The model provides a frame work in which administrations can maintain

autonomy, while allowing close interaction between distributed systems.

2.4 OSF Distributed Computing Environment

2.4.1 Introduction

The Distributed Computing Environment (DCE) from the Open Software

Foundation (OSF) covers more platforms and offers more features than most other

client/server technology [1]. The DCE Security Framework (or model) is simpler

than real-life situations and omits implementation details.

2.4.2 Description

The security activity is centralized in a security server which provides the

security services normally provided by an operating system over the network. All

other clients and servers trust the security server and what it tells them. The

security server maintains a registry that stores information about the principals,

privilege attributes, and secret keys. The DCE security registry is accessible only

via a Remote Procedure Call (RPC) interface. A user must log in to DCE before

he or she can access DCE services. Then, whenever the user wants to access a

























Figure 2.2: DCE security model


remote object, he or she must first ask the security server to issue a certificate that

certifies the identity of the user (refer Figure 2.2). The certificate, also called a

credential, is a message issued by a trusted authority in such a manner that the

server can independently verify the client's authenticity. The client then passes the

certificate as part of a RPC call to the server. When the server receives the call, it

passes the certificate to the reference monitor for the object. The reference monitor

examines the certificate and decides whether the client is authorized to make the

call. If so, the call is accepted, processed, and the results are returned. Otherwise

the call is rejected.

The DCE Security does not provide a reference monitor. Instead, DCE

provides the tools for anybody to implement their own reference monitor. The

job of a reference monitor is to match the information in the certificate against an

access control list. The DCE defines a standard RPC management interface for an

ACL facility and allows one to use the ACLs in many ways. For example, users

can be checked both as individuals and as members of groups. Applications can

also choose their own kinds of permissions but every application should support a

control permission that determines who can update the ACL.









Another reason that reference monitors are custom-made is that each applica-

tion needs to define its own storage model. For example, a distributed UNIX-like

file system will probably store its security attributes in the inode while a database

management system may choose to store it in some other data structure.

2.4.3 Comments

Since the model does not describe the implementation, it is highly flexible. A

common interface allows a management tool like acledit to manage all DCE ACLs,

including those implemented by applications. However, the security server has to

be carefully protected. If someone can gain control of the system with the security

server and its registry, that person would have access to all the accounts. If the

security server is cut off from the rest of the network, nobody can perform any

access because they cannot get the certificates to authenticate themselves to the

reference monitor. However, this model provides cross-platform support and allows

applications to specify their own access types.

2.5 Role-Based Access Control

2.5.1 Introduction

Role-Based Access Control (RBAC) is a model standardized by David Fer-

raiolo and Richard Kuhn at the National Institute of Standards and Technology.

The principal motivations behind RBAC are the ability to articulate and enforce

enterprise-specific security policies and to streamline the typically burdensome

process of security management [16]. In many organizations, the end users do

not "own" the information for which they are allowed access. The corporation is

the actual "o(v i. i of system objects as well as the programs that process it and

control is often based on employee functions rather than data ownership [17]. In

RBAC, users do not have discretionary access to enterprise objects. Instead, access

permissions are associated with roles and users are associated with roles.









2.5.2 Description

A role based access control policy bases access control decisions on the roles

a user is allowed to take on within an organization. The determination of role

membership and the allocation of transactions to a role is in compliance with

organization-specific protection guidelines derived from existing laws, ethics,

regulations, or generally accepted practices [17]. With RBAC, users are not

granted permission to perform operations on an individual basis, but operations

are associated with roles. This has the advantage of simplifying the understanding

and management of privileges. System administrators control access at a level

of abstraction that is natural to the way enterprises typically conduct business.

RBAC addresses security primarily for application-level systems, as opposed to

general purpose operating systems.

To improve efficiency and provide for the natural structure of an enterprise,

RBAC includes the concept of role hierarchies. A role hierarchy defines roles that

have unique attributes and that may "contain" other roles, i.e., one role may

implicitly include the operations, constraints, and objects that are associated

with another role. RBAC enforces the following rules on role authorization, role

allocation, and operation execution.


1. Role Hierarchy If a subject is authorized to access a role and that role
contains another role, then the subject is also allowed to access the contained
role.

2. Static Separation of Duty A user is authorized as a member of a role only if
that role is not mutually exclusive with any if the other roles for which the
user already possesses membership.

3. Ci,li4,,lihl The capacity of a role cannot be exceeded by an additional role
member.

4. Role Authorization A subject can never have an active role that is not
authorized for that subject.









5. Role Execution A subject can execute an operation only if the subject is
acting within an active role.

6. Dil,,mIII Separation of Duty A subject can become active in a new role only
if the proposed role is not mutually exclusive with any of the roles in which
the subject is currently active.

7. Operation Authorization A subject can execute an operation only if the
operation is authorized for the role in which the subject is currently active.

8. Object Access Authorization A subject can access an object only if the role is
part of the subject's current active role set, the role is allowed to perform the
operation and the operation to access the object is authorized.

2.5.3 Comments

RBAC provides a means of naming and describing relationships between

individuals and rights. Some form of RBAC is used in commercial systems today,

but there is no commonly accepted formal standards encompassing RBAC and

RBAC remains a long way from being a commercially popular technology.

2.6 Access Control in UNIX Operating System

2.6.1 Introduction

The UNIX operating system was developed at Bell Laboratories in the late

1960s. It evolved in a "friendly" environment, on systems that encouraged users

to share their files [4]. However, UNIX is by design a very robust system. The

following is a brief discussion of the basic principles in UNIX access control.

2.6.2 Description

Files are central to UNIX in ways that are not true for other operating

systems. Commands are executable files in specific directories like /bin, /usr/bin

etc. System privileges and permissions are controlled in a large part via access to

files [18]. Access to files is organized around file ownership and protection.

Each file has a user owner and a group owner. UNIX supports three types of

file access: read (r), write (w), and execute(x). A different set of access rights can

be set for user owner, group members and others. For example, the access right









rwxr xr means that the user owner can read, write and execute the file,

members of the group owner can read and execute the file but all others can only

read the file. The command that is used to alter the access mode is chmod.

There are a few other defined file modes, namely, t (Sticky bit, keep executable

in memory after exit), s (Set process user ID or group ID on execution), and I (set

mandatory file locking on reads/writes). Files that begin with a period are hidden

files and are not listed by Is command unless used with the -a option. The -1

option of Is command lists the files along with the modes and owners of the files.

The set of commands that are used to modify the access rights of files are:


chmod Specify the protection modes for files.

umask Specify the default mode for newly created files.

chown Change the user owner of a file.

chgrp Change the group owner of a file.

Some variants of UNIX, like AIX and HP-UX provide access control lists which

offer a further refinement to the standard UNIX file permissions capabilities. These

ACLs consists of three parts:


1. Attributes Specifies any special attributes like SETUID and SETGID.

2. Base permissions These correspond exactly to the UNIX file modes and
specify access rights for owner, group and others.

3. Extended permissions These are access information specified by user and
group name.

ACLs that specify a username and group are useful for accounting purposes. They

are also useful if you add a user on a temporary basis [18].

UNIX was the first major network operating system. It provides various

services like NIS (Network Information Services) and NFS (Network File System)

that help in administering a network. Using NIS, users can log on to any machine









on the network that belong to the same NIS Domain. In a network with twenty

machines, the administrator has to add the new user on just one machine and that

user can log on to any one of these twenty machines. In order to provide a uniform

directory structure when a user logs in, administrators mount file systems over the

network. Usually, the user's home directories are mounted using NFS. This way the

user's files are available to him/her on any machine in the network. The advantage

with this arrangement is that controlling file permissions is the same as described

earlier.

2.6.3 Comments

Users authenticate themselves to the system by providing a user name and

password. It is very important for users to protect their passwords because if

the password is compromised, then all of the logins may be compromised [4].

Passwords and file permissions are two basic ways of preventing security problems

in UNIX. Passwords prevent bad guys from getting on the system in the first

place and proper file permissions prevent normal users from doing things they

are not supposed to [18]. One important issue in UNIX file permissions is the

restricted access types. There is no way for users to define their own access types .

Moreover, the owner of a file has full rights to do anything with the file. In many

organizations, the files are not "owned" by the users but by the organization itself.

2.7 Distributed Compartment Model

2.7.1 Introduction

The Distributed Compartment Model was proposed by Steven Greenwald as

a solution to management of system resources and access control in a distributed

computing environment. The model consists of two parts, (i) Distributed Handles, a

means for user identification and access control and (ii) Distributed Compartments,

a method for allowing users to manage resources within a distributed system across









computer system boundaries with a measure of independence from any system

administrations [3].

2.7.2 Description

The distributed handles eliminates groupware application userIDs as a means

of identification and access control. A user joining a groupware session is queried

for a handle that is unique to that application and is then verified by a groupware

security manager. Under this method, an individual user would first gain access

to a particular computer system in the distributed system by having a valid user

ID and password. The user would then need a valid distributed handle and would

then need to be validated by the groupware's access control security in order to be

allowed access to the application.

The major advantage of this approach is that security dependencies are

reduced. Moreover, the handles can be more descriptive than user IDs, for example

"Third programmer" instead of "avO". Multiple handles can be permitted for the

same user and many users can share the same handle.

Distributed compartments (also called discom) is the designated platform for

access control and administration of distributed handles. A discom is a logical

group of objects that is conceptually similar to a standard hierarchical directory

structure but does not necessarily reside in a single computer. The users of discoms

gain access via distributed handles.

A root discom is called an empire discom. Each discom must have at least one

subject called governor. Governors have the maximum privileges for the discom

they govern. There are 24 basic operations called initial privileges. They include

operations that create/destroy/merge/split/modify objects/child discom/empire,

create/rescind privilege/governorship/subject/resource/privilege etc. This combina-

tion of subjects, objects and privileges, makes it possible to create a system similar

to an access control matrix.









The Distributed Compartment Model has a set of axioms and properties some

of which are:


Genesis Axiom The initial state of the system is secure.

Divine Right Axiom A subject can create an empire discom only if given
that privilege by the administrators.

Temporal Axiom A subject may only access an object with the same time
index as the subject.

Usage P ., /, Iti/ If a subject is currently accessing an object, it either
accessed the object before the present time, or it requested access of the
object before the present time.

Creator Pi .,/,, ti/ The creator of a discom automatically becomes a governor
of that discom.

Government Pi .,!, ti, The governor of a discom may grant and revoke
privileges to non-governor subjects of that discom.

Cordon Pi ,/, tii Discoms may never intersect with other discoms.

Demesne Pi .,/,, ti/ The governor of a discom always has unrestricted access
to descendant discoms.

Ceiling Pi .,, ti, A subject may not access an ancestor discom without being
a subject of that discom.

A distributed compartment is actually a groupware application, with access to the

discoms determined by distributed handles. Management of discoms is not done by

the local system administrators but by the individual users who are governors of

empire discoms.

2.7.3 Comments

One major disadvantage with this model is that users will have to have a

separate handle for each application they use. This means that they will have to

remember not just their user ID and password but the handle and password for

each application. It would have been preferable to avoid such multiple "l., n-







25

Since many users can share handles, this reduces accountability. Moreover, this

model practices a type of monarchy in which the governors have absolute power

whereas a more democratic form of government will be more practical in the long

run.















CHAPTER 3
REQUIREMENTS

3.1 Introduction

A complete understanding of software requirements is essential to the success

of any software development effort. No matter how well designed or well coded,

a poorly analyzed and specified program will disappoint the user and bring grief

to the developer [19]. The requirement analysis task is a process of discovery,

refinement, modeling and specification. The final output expected from this stage

is a detailed specification of the requirements. However as Dwight Eisenhower said,

"The plan is nothing; the planning is everything". The corollary of this statement

as applicable to requirements analysis is "The product is nothing; the process is

everything" [20].

3.2 The Process

The software development model used in DCS is the spiral model. The various

stages in the software development cycle overlap and feed information to each

other. During design, problems with requirements are identified; during coding,

design problems are found and so on [21]. The software process is not linear and

one goes through several iterations before the final version.

An efficient way to capture the expected performance of the system is through

scenarios. Scenario-based requirement solicitation is an approach that has work

very well for us. The idea behind this approach is to list out various scenarios and

discuss how the system should perform in these scenarios. This not only helps

us understand the system, but also served as a good starting point for further

discussions.









Each set of scenarios along with the expected system behavior was discussed

among the DCS group members. This way, the other group members could

understand how the Access Control Services (ACS) interacts with their modules.

During these brainstorming sessions, we were able to nail down most of the

functions and expectations. An added advantage with this approach was that

we had a set of test cases ready along with the expected performances. This also

helped us with the user interface design too. Let us now look at a set of sample

scenarios.

3.3 A Sample Scenario

Initially, let us assume that there are three sites, A, B, and C and that a DCS

user can log in without being bound to any conference (i.e., logs into the vestibule

conference). All new members of a conference are bound to the role member unless

otherwise specified during the joining process.


1. User Alice is added to DCS from site A.
A new DCS Id is created for Alice and various information about Alice, like
address, email etc., are stored in a global database.

2. Alice creates a new conference DCS at site A.
The system first checks to see if Alice has the right to create new conferences,
if so, DCS is added to the global conferences database from site A. Alice
binds to the role admin. Alice has to create the initial roles and initialize the
access control matrix (AC'M).

3. Alice creates a new role outsider for users who request to join the conference.
This is a part of initiating the conference and since Alice is the admin, she
can do it.

4. Bob logs in as an outsider and requests to join DCS.
Since requesting to join the conference is a right granted to the role
outsider, the issue is put to vote. Let us say that Bob is allowed to join the
conference.


5. Alice requests to allow Bob to be an admin.









The AC'i is checked to see if Alice can add new role bindings to the role
admin. If so, then the corresponding decision pointer is activated and if the
result is positive, the request is carried out.

6. Bob requests to allow admin to change the access privileges of any user.
This issue is put to vote based on the template for changing the AC'i

7. Charles logs in as an outsider from site B and requests to join the conference.

8. Alice and Bob agree to let Charles in. Since they are the only two members
of the conference, the request is granted.
Charles is added to the conference as a member and site B is added to the
list of sites that are a part of the conference DCS. The relevant databases are
copied to site B.

9. Alice imports a document, "Welcome.doc" and sets permissions in such a way
that every member of the conference can read it but she alone can modify it.
This is allowed as Alice has the right to import objects. She also has to add
a new object type say, Conference Documents, and grant read access to all
members.
There has to be a way to specify subject-to-object relationships. This can be
achieved using special permission.

10. Charles requests to change the voting template for membership requests to
include members as well.
The ACS has to check if a member has the right to make such a request. If
he is allowed, the issue is out to vote, else the request is denied.

11. Donald logs in from site C and requests to join the conference.
The vote is placed on the table and rejected. Donald has to be notified about
the result.

12. Dan applies to join the conference from site C.
Dan's request is put to vote and once he is approved, the relevant databases
are copied to site C and the site is added to the list of sites for the confer-
ence.

13. Bob creates two new roles, writer and editor.
Since the conference policy allows admin to create new roles, these two new
roles are added.

14. Alice makes Dan a writer.
This is allowed if admin can add new user binding to the role writer.


15. Alice adds a video conferencing application to site A.









The application is registered for site A and new access types are added to the
ACS.

16. Dan creates a new object type writer document and imports four new
documents.
This action is allowed only if writers can add new object types and import
documents. Dan has to set the initial permissions for the object type writer
document.

17. Charles copies one of the writer documents to his personal space.
This is allowed if Charles has the right to export writer documents.

18. Dan logs in as a member and moves to dissolve the conference.
First the system checks if members can delete the conference, if so the issue is
voted on and depending on the template a decision is made.

3.4 Requirements of the ACS

This section deals with the access control requirements of the Distributed

Conferencing System (DCS). The access control module controls the access to

various conference objects in two ways: role specific access privileges and additional

processing functions called Decision Templates. It must be noted that different

sites and conferences may have different access control policies.


1. Access control decisions are made by looking up at the Access Control
Table. Each entry in the ACT has a pointer to the decision template that
must be used to obtain the result. The actual process of arriving at a decision
is taken care of by the Decision Support Services (DSS).

2. The default decision for access is No. That is, unless otherwise explicitly
mentioned, all access requests are denied.

3. Privileges are revocable actions which subjects may perform on objects using
applications.

4. Different applications have different types of access privileges. Hence the ACS
must be able to handle new access types.

5. A role is a labeled set of subject/object privileges within a conference.
Privileges are specified for particular roles. In order to check the privileges of
a subject, we look at the privileges of the role to which the subject is bound.









6. A subject-role mapping is not one-to-one. There can be more than one
subject bound to a role and a subject can be allowed to bind to different role
at different points of time. However, at any point of time, a subject can bind
to at most one role.

7. It should be possible to add new roles and delete existing roles.

8. There should be an Admin role for each conference. The admins initially have
God-like powers within the conference (this is required for initializing the
conference and to get the conference started). At a later stage, it is up to the
members of the conference to retain these rights or replace them with more
democratic decision templates.

9. Certain users may be able to modify the access privileges of certain roles.

10. Objects of the same type are grouped together under Object Types. The
ACT specifies privileges with respect to object types only.

11. The ACT itself is an object and access privileges can be specified as to who
can modify the ACT. Different subjects can have different granularity of
access. For example, some subjects can modify a particular column, some can
modify a few specific rows and some can modify the whole matrix.

12. Some examples of access privileges are:
Application specific access to an object like play a music file etc.
Delete an object.
View an object's existence.
Execute an application.
Add/remove an application to/from a conference.
Create/modify/delete an object.
Create/modify/delete a subject.
Create/delete a role.
Modify access privileges of a role.
Modify decision pointers of an entry.

13. The creator of the conference should be able to initialize the tables, i.e.,
specify the initial rights, roles, types, decision templates and accesses.

14. We should be able to define certain special relationships between objects and
subjects that are not valid for other subjects in that role and other objects of
that object type. These are called special permission

15. Granting and revoking these special permissions is also an access right.









16. There are certain site specific access control requirements that have to be
handled by the ACS.
An outsider should be able to join a conference.
Certain users should be able to install new applications on the site.
Certain users should be able to remove applications from the site.
Adding a new site to the DCS instance is a right that must be available
to certain users.
Splitting/merging/deleting of sites should also be possible.
Users should be able to create a new conference.
Splitting/deleting a conference and merging two conferences should also
be possible..

17. The model should be fault tolerant. If one of the sites goes down, then the
other sites should continue to provide service to the best of their abilities.
When a site comes back on-line from a crash or shutdown, it should be able
to commit the updates it missed and get back to normal operations.

18. If the network is partitioned, the system should be able to sort out any
inconsistencies once the communication links get back online.

19. If a particular site goes down, then upon recovering, it should be able to get
the most up to date information from one of the other sites and continue
processing the stalled requests.

3.5 Interactions with other DCS services

The ACS will have to communicate with other services within the DCS in

order to provide services and to make use of their services. This section deals with

what is expected from the ACS by the other services and what ACS can expect

from the others.

3.5.1 Database Services

The ACS will have to contact the Database Services for almost all queries.

The ACT and the other tables required by the ACS are accessed through the

DBS and all queries and modifications run through the DBS. If any database

query cannot be executed, the ACS should be able to handle the error and report

the cause. The ACT should be replicated across all sites that are a part of the


conference. This is guaranteed by the DBS.









The ACT consists of following fields, RoleID, ObjectT,i,,I Access, Decision-

Pointer in the least. In addition to this, we also have a special permissions table

which records special relationships between objects and users like ownership. If a

user wants to read a file, then we first look at the ACT to see if the role to which

the user is bound can read objects of the file's type. If this is not allowed, we then

look at the special permissions table to see if the user has any special permissions

on the object. The special permissions table has the following fields, Userld, Ob-

jectId, SplRoleId. If the user has any special permissions, then the corresponding

SplRoleId is then check with on the ACT to see if that role has the permission to

read the object.

3.5.2 Conference Control Services

The CCS controls the entire conference and instantiates the objects that

provide the services. Moreover, most user requests are passed on to the ACS

through the CCS. Most CCS-originated actions have to be checked through the

ACS for access privileges. For example, if a user wants to import a new file, the

CCS will have to check with the ACS before proceeding with the import. A major

task for the CCS is application management. Adding a new application to the

conference, changing object-type associations, deleting an application and even

running certain applications will require an ACS request.

3.5.3 Decision Support Services

The DSS handles the decision-making process and is therefore closely tied to

the ACS. If a request requires a vote, the DSS has to be notified and the voting

process initiated. The ACS must be able to check the status of a particular vote.

When a vote is completed, the DSS should notify ACS. Similarly, the ACS must be

able to report a list of active votes to the DSS if the DSS decides to delete obsolete

votes. Actions like defining new templates and modifying existing ones require a

check by the ACS.









3.6 Interesting Issues

There were a few interesting issues that required considerable discussions

before the requirements were finalized. Some of them are listed below.

3.6.1 Admin role

The admin role was an interesting issue. Such a role makes the task of

initializing the conference databases easy and simple. If such a role does not exist,

we may need complicated initiation mechanisms to populate the ACT. So to avoid

such complications, it was felt that we must have an administrative role in all

conferences. By default, the creator of the conference can be an administrator and

any new user can be added to or dropped from the role by a vote among admins or

as the conference policy specifies. The only constrain to be enforced while removing

user-admin role bindings is that at any point of time, there should be at least one

user who can bind to this role. It must be noted that the main idea behind using

decision pointers is to avoid all-powerful users who can do anything. Although

administrators make the initial setting up of the conference easy, their powers can

be diminished at a later stage and replaced by a more democratic process.

3.6.2 Modifying the ACT

It is obvious that we must allow some users to change the ACT. In other

words, some roles have the right to grant/delete rights in the ACT. The interesting

question is, how do we represent the fact that some roles can have the right to

grant/delete the right mentioned above. As you can see, it is very easy to drop into

a bottomless pit with this line of argument. The ACS avoids this problem because

the right to grant/delete rights is also represented in the ACT and is treated as any

other right.

3.6.3 Separation of Duty

Separation of duty is one of the more common requirements in any real-life

system. For example, in a bank loan processing system, the person approving









the loan should not be the one who prepared or reviewed the application doc-

uments. The person testing a software module should ideally be someone not

in the programming team. One of the most interesting policy is the Chinese

wall policy. It ensures that a person who has access to documents of one type,

say Coco ColaAdCampaign does not have access to other documents, like

PepsicoFoodsAccounts, which may result in a conflict of interest. Enforcing these

policies requires some work flow control process. In the ACS model, the use of

decision pointers allows us to achieve this through the voting mechanisms. The

members can reject a request if it is against the conference policies.

3.7 Summary

As mentioned earlier, the requirements mentioned above were the result of

many iterations through the software development cycle. It is possible that some

new requirement may come up at a later stage when more modules are added

to the system. The current implementation has been designed to meet these

requirements.















CHAPTER 4
DESIGN

4.1 Introduction

The next stage in the cycle is the design. A good design goes a long way

in minimizing the development time and simplifies testing and maintenance.

The input to this process is the requirements document and the final design is

the result of an evolutionary process. We came up with a base design that met

the requirements and checked to see if it handled all the scenarios. We then

looked at those scenarios that failed and modified the design as needed. We then

checked the scenarios again for more failures. In some cases, we had to modify

the requirements. Many organizations freeze the requirements document once the

design stage is reached and hence the analysts have to get everything right the

first time. This is invariably not the case. We therefore decided to follow the spiral

model.

This chapter first discusses the formal definition of the ACS model. The

database table schema and the database query functions are then defined, followed

by the interaction with other modules. Finally, some of the alternatives considered

are reviewed.

4.2 Formal Specification of ACS Model

In this section, we will present the formal specification of the ACS model.

The ACS model is obtained by adding typing information into the HRU model

[9]. The distribution of rights in the system are represented by an access matrix.

The matrix has a row and a column for each subject and a column for each object.

The [X, Y] cell contains a set of (r, dp) pairs where r is a right which role X has









for objects of type Y and dp is a pointer to a decision template which has to be

activated each time to X makes a request to perform r on Y.

Each subject is bound to one or more roles. Each object is bound to one

object tir,'. These bindings can be changed by anyone who has the right to do so.

This is a major difference from the TAM model in which the bindings are a part

of the system definition and can only be altered by an external administrator. In

the ACS model, the administrator is considered to be a part of the system and is

subject to the access restrictions imposed by the matrix. An instance of ACS has

the following finite sets:


a set of access rights denoted by R,

a set of decision templates denoted by DT,

a set of object types denoted by T,

a set of roles denoted by TR,

a set of objects denoted by OBJ, and

a set of subjects denoted by SUB (Note that SUB C OBJ).

We also have a mapping function t which maps each subject to a subset of TR and

each object to an element of T. The primitive operations that can be performed on

the matrix are listed below.


create new right

create new object type

create new object

create new subject

add new subject-role binding

change decision pointer for an access

add new entry to matrix cell


delete existing right

delete object type

delete object

delete subject

delete subject-role binding

change object type of an object

delete an entry from the matrix cell









In addition to these, we have a special relations function, SR : (SUB x OBJ) -

TR. This returns the special roles, like ownership, that individual subjects have

with respect to specific objects. It must be noted that in TAM, R, T, TR and t

are all part of the system definition and cannot be altered by anyone within the

system, whereas these are a part of the ACS model instance and can be modified

by anyone who has the right to do so. TAM does not have the notion of decision

pointers either. TAM allows any number of parameters in its commands but the

ACS allows at most three. A version of TAM, called ternery TAM, which allows

only three parameters, can be easily reduced to the ACS model. Safety analysis for

the ACS model is interesting but is beyond the scope of this thesis. Our intention

is to design a model that implements distributed access control while at the same

time makes the decision making process more democratic.

4.3 Database Table Schema

4.3.1 Access Control Table

The Access Control Table (ACT) is the main table that is referred for access

control requests. Since we want to store ACT modification rights in the ACT itself,

we had to add TargetRole field. Now, we can represent things like, "Role A has

the right to modify the ACT entries for Role B". In order to handle the various

scenarios listed earlier, the Access Control Table has the following fields:
Role TargetRole ObjectType AccessType DecisionPtr


The entry for the target role is NULL unless it is applicable. Hence all entries

corresponding to rights for a role R1 with respect to objects of type Ti and access

type A1 will look like:
Role TargetRole ObjectType AccessType DecisionPtr

R1 NULL Ti A1 3
Note that DecisionPtr is of type integer. The mapping between the Decision

pointer index and the actual decision template is defined in another table (Decision









Template Table). We can also use ANY to represent all instances of that type. For

example, the default entry in the ACT could be :


Role TargetRole ObjectType AccessType DecisionPtr

Admin ANY ANY ANY 1


In all the examples, it is assumed that the decision pointer 1 refers to some group

decision template that is used for major decisions. The above entry means that

any access not explicitly allowed in the ACT will be referred to the group decision

mechanism.

Sample Table

Consider the following ACT:
Role TargetRole ObjectType AccessType DecisionPtr

R1 NULL Ti A1 3

R R2 T2 Grant 5

R3 NULL ACT ModifyDT 1

R3 NULL DT Modify 1

R1 SR1 T1 AddSR 7

R2 NULL RT Assign 3

Admin ANY ANY ANY 1
The entries in the above table are discussed below:


1. Role R1 can perform access A1 on objects of type Ti if the
template 3 is positive.


result of decision


2. Role R1 can grant role R2 access to objects of type T2 if the result of decision
template 5 is positive.

3. Role R3 can change the decision template pointer for some entry in the ACT
if decision template 1 returns a yes.

4. R3 can change the decision template parameters for entries that point to that
decision template if decision template 1 returns a yes.









5. Refer to decision template 7 if a user bound to role R1 wants to allow another
user (bound to role R2, say) to be able to bind to a special role SR1 with
respect to an object of type Ti. (Refer to note regarding special roles that
follows later).

6. This entry refers to decision pointer 3 if a user bound to role R2 wants to
assign a new Role x User mapping.

7. This is the entry that grants the admin the right to do anything after
referring to decision template 1. When the conference is created, the decision
pointer points to a template that always returns a ',, -. At a later stage, the
members of the conference can remove this entry or set the pointer to another
decision template. In the actual implementation, this is treated as a special
case.

Note: The entry in the above table for adding a special relationship between a

user and an object does not allow us to enforce automatic enforcement of policies

for assigning special roles based on the role of the target user. One of the following

two modifications can be used to overcome this:


1. We can write the target role instead of the special role. However, this does
not enable us to distinguish the special roles.

2. We can write the targeted role in the Role field. R1 which is the role of the
user who wants to make such a modification is added as a parameter to the
decision template.

4.3.2 Other Tables

The ACS has to maintain a few other tables to provide the services required.

One such table is the Special Permissions table. This table is simply a triple

(Userld, ObjectlD, SpecialRoleID). The rights this user has over the object is

stored as ACT entries with SpecialRoleID in the role field and the ObjectType of

ObjectlD in the object type field.

The ACS also has to maintain the User x Role bindings in a separate table

and the ObjectlD x ObjectTii,, information in another table. The ACS must

also provide methods to modify and query these tables. Another important table

is the ToDoList. This is the list of all access control requests for which a vote is









pending. Once the DSS reports the result, the ACS has to look up this list and

take necessary actions (in most cases, report the result to the CCS). If the request

was to modify one of the tables maintained by ACS, and the result is a "yes", then

the modification has to be committed.

4.4 DCS-defined Object types and Access types

As we can see, there are a few DCS specific objects that are referred to in

the ACT and some DCS specific access types. The objects are Access Control

Table(ACT), Decision Template Table (DT), Role Table(RT), Objects Table (OT)

and Special Relations Table (SRT). All the tables have the following access types:


1. AddEntry Add a new entry

2. DelEntry Delete an existing entry

3. Modify Modify an entry

The DT is the table that holds the mapping between the decision pointer index and

the decision template parameters which define the template. The Role Table maps

users to the roles to which they can bind. The Objects Table maps the objects and

object types. The special relations table is a table that contains userid, objected

and specialroleid.

4.5 Check-Access Function

The main service that ACS provides is to check if a particular user has the

right to perform some action. The Check Access function could be a simple

query on the ACT for the existence of the tuple corresponding to the request. The

parameters for this function are the UserID, RoleID, ObjectlD, AccessT,1i,, and

TargetRole if applicable. The ACS first looks up the Special Permissions table

for any special relationships. If any such relationship exists, then the RoleID is

replaced with the corresponding SpecialRoleID. We now look at the ACT for the

existence of such a tuple. If one does exist, the DecisionTemplatePtr is passed on









to the DSS to start the process. An entry is made in the ToDoList along with the

vote number returned by DSS. The ToDolist is the only table that is local to each

site. All other tables are replicated across all sites in the conference.

One tricky problem was the ANY wildcard in the ACT. It was decided to use

the number zero to represent this wildcard. If the ACT does not contain the tuple

mentioned earlier, then we check again with the same set of values but a zero for

access type first, then a zero at TargetRole. Note that currently only one wild card

per entry is checked. Entries like (RoleID, ANY, ObjectTi,, ANY, 5) are not

supported as of now. The entry (Admin, ANY, ANY, ANY, DPTR) is treated

as a special case as it is necessary during the initiation phase.

4.6 Interactions with other Modules

Since each module in the DCS is developed by a different person, it is very

important to have clearly defined interfaces between them. Each developer has to

have a clear idea of what is expected from his/her module by the others. As far as

the ACS is concerned, all modules call the Check-Access method. The CCS, DBS

and DSS have closer interaction with the ACS and given below are the methods for

these interactions.

4.6.1 Conference Control Services

Since the CCS instantiates the ACS object, it is also responsible for establish-

ing the link between ACS and other modules. This is done by passing references to

the other objects to the constructor. One problem is that if all objects are created

at more or less the same time, a particular module may not be ready to service the

others and this may lead to failures. This is avoided by using a two step initiation

process. In step one, the objects are created and they do not communicate with

each other till the CCS sends the go ahead. Therefore, the ACS cannot create the

tables before the CCS informs it that everything is ready. The CCS handles the









user login and therefore needs to refer to the Role table. It uses the Role table

query methods for this.

4.6.2 Database Services

All ACS requests involve some form of database queries. The DBS has to

provide methods to create tables, make queries on them and to modify the entries.

The DBS identifies one site as the owner for each entry in the tables. Any update

has to go through the owner site. This is done to ensure consistency. Therefore,

there are two types of database commands, updates which are forwarded to the

owner and queries which are processed at the local site. All methods in the ACS

involve constructing a SQL command that represents the user's request and calling

either the update or the query method of the DBS. Note that the ToDolist is a

local table and is therefore handled separately by the ACS.

4.6.3 Decision Support Services

The DSS maintains the decision templates that are used by the ACT. When a

request is made, the ACS calls a method of DSS that initiates the voting process

and returns a vote number. The DSS also exports a method that checks the status

of a vote. The DSS may have some votes in its database that are no longer active.

This is possible if it comes back from an error state. The ACT provides a method

that lists the votes that are currently active. The ACS can also request the DSS to

delete a specific vote that is no longer active.

4.7 Alternate Design

Earlier, it was mentioned that access control requests to modify the ACT

are handled by using the TargetRole field of the ACT. An alternative method

was considered to solve the problem but was dropped because it was too complex

to implement. We then came up with the additional field in the ACT. This

alternative is explained below.









4.7.1 Views

The problem arises from the fact that the ACT itself is an object and access to

the ACT has to be controlled. The model used can be extended to other databases

used in the DCS. This opens up the interesting issue of access control in databases

in general.

In a database, we can define access for different users by defining views for

them. A view is a specific cut of the entire database that is available to the user.

We can specify different views for different users. In the context of RBAC, we can

specify different views for different roles. Thus the problem of access control in

databases is equivalent to defining different views and enforcing them. Since users

can have permissions to read some parts of the database and also to some other

parts, we need to define different views for read and write permissions. Normally,

the write view is a subset of the read view but this need not always be the case.

Although we will have to deal with two different views, both the views can be

handled in more or less the same way.

Since we are implementing role-based access control, we will have to specify

read and write views for each role. To reflect special relationships, we must specify

special role views, on the lines of special permissions of the AC'i The rules for

checking access are the same as that of special permissions of AC'i

Implementing views poses some interesting problems. Unless we have a good

understanding of the schema of the database, we can not effectively specify views.

It is reasonable to assume that the schema of a database doesn't change often.

We can refer to the attributes of the database as columns in a table and the

individual entries as rows. In order to specify a view, we need to specify the rows

and columns that are visible to the user. Moreover, we cannot just specify the

boundary rows and columns because there may be some entries in between that are

not a part of the view. So we specify the boundaries in a Boundary list and the









specify all those entries that are inside the boundary but not a part of the view in

a 1/. ',, list. For an entry to be a part of the view, it has to be inside the boundaries

and should not be present in the deny list. Here are two methods to implement

these.


1. Row/Column Numbers The obvious way to specify such a view is to list the
row and column numbers that are a part of the view. This is a very easy
solution at the outset. Since the internal representation of the database will
be in the form of a table with each entry as an object, we can easily obtain
the row and column numbers. The problem with this approach is that each
time there is an addition or deletion to the table, we will have to revise the
two lists to reflect the change. This is too expensive an overhead and this
approach was dropped. Another problem is that the order of entry may not
reflect the logical organization.

2. Allow/Deny rules A slight modification of the first approach helps us over-
come this problem. Instead of specifying the row and column numbers, if we
specify rules for selection, we need not update the lists after each addition
or deletion of entries. Here, we define rules for the views and the rows to
be selected can be specified by such rules. We can list the column numbers
(since insertions and deletions of columns, i.e. schema changes are rare).
Here again, we need two lists, Allow-rules list and D. I,,,-rules list. We first
apply the allow-rules to see if the user is allowed access to the current entry
and if so, we check the deny-rules to see if such an access has been explicitly
disallowed. We can specify the lists via row selectors and attribute names.

Summary

This implementation will use another table to resolve access control issues in

AC'i We will have to draw the line here and say that only the conference owner

or the members of a specific role like admin can alter this table and they have full

access to this table. We have to do this to avoid going one step higher each time

to have a table that controls access to the current database. This approach was


dropped when the TargetRole attribute was introduced.















CHAPTER 5
IMPLEMENTATION AND TESTING

The next phase in the software cycle is implementation. One major require-

ment of a good design is a short implementation time. The design from chapter

four has been implemented in Java and tested to meet the requirements specified

in chapter three. One of the first decisions that we made was to implement the

DCS V2 in Java. The previous version was implemented in C with a TCL/TK user

interface. The developers faced many problems including maintaining compati-

bility between the various versions of TCL/TK. The RPC interface of C was not

developer-friendly and integrating the different modules became a major chore.

Java provides us with an easy-to-use set of built-in library routines and is

portable across most platforms [22]. Remote Method Invocation (RMI) of Java

makes it easy to call methods on another server. Moreover, Java Swing code is

standard for all platforms and ensures that the user interface looks the same in all

the platforms.

The backed Database Management System (DBMS) used was Postgres

which is a free ware relational DBMS. The DCS V2 was implemented on a Linux

box running RedHat 7.0. Postgres was available with the operating system and

installation was trivial. We were also able to install the windows version of

Postgres on a windows machine for testing purposes. Note that only the Database

Services (DBS) interacts with the backed DBMS package and the ACS cannot

access the DBMS directly. This is done because Postgres is not a distributed

DBMS and the DBS has to propagate the updates to all the sites in the conference.









5.1 Implementation of ACS

As mentioned earlier, the ACS has to maintain many tables. These tables were

created in createTables( method. It must be noted that the ACS sends the SQL

command to the Database Service (DBS) which in turn executes the command on

the backed Postgres through JDBC and also propagates the command to other

sites [23]. Similarly, there is a deleteTables( method that deletes the tables when

the conference is deleted. The list of tables along with their attributes is given

below.


Table Name


Access Control Table

UserRole

ObjectTable

SplRelations

RoleTable

ObjectTypeTable

AccessTypeTable

IntentionsList


Attributes


rolel int, role2 int, objtype int, accessno int, decisionptr int

userid int, roleid int

objectid int, objecttypeid int

userid int, objectid int, splroleid int

roleid int, rolename varchar

objecttypeid int, objecttype varchar

accessno int, accesstype varchar, application int

votenumber int, action int, role int, role2 int, objtype int,

accessno int, decisionptr int


The attributes of the Access Control Table have been discussed in chapter

four (refer Section 4.3.1). The role2 attribute can be null and the primary key is

all the attributes except the decision pointer. The UserRole table stores all the

valid user x role bindings. Since a user can bind to more than one role (but at

most one role at a time) and a given role can have more than one user, the two

attributes together form the primary key. The ObjectTable maps the objects to

their object types and since a given object can belong to only one object type,

the primary key for this table is the objectid. The mapping between the objectid,

object name, path and other such information is maintained by the Conference


i









Control Service (CCS). The primary key of the SplRelations table is (userid,

objectid). The RoleTable maps the roleid to the corresponding role name and is

mainly used by GUI objects to list the roles or a specific subsets. The primary key

for this table is the roleid. The ObjectTypeTable is similar to the RoleTable in

function and its primary key is the objecttypeid. The AccessTypeTable contains

information about the access numbers and the applications that can make these

accesses. Since more than one application can perform the same type of access, like

read, the primary key for this table is (accessno, application). This avoids the need

for multiple access types like VIread, Notepadread, etc. More information about

the applications is maintained by the CCS.

The IntentionsList contains the list of pending access requests. When the

decision template is triggered, a new entry is added to this table. The Decision

Support Service (DSS) returns a unique votenumber for each decision and this

serves as the primary key for the table. In most cases, when the vote is decided,

the ACS has to inform the CCS about it. However, if the access relates to one

of the tables maintained by the ACS, then suitable action must be taken, like

adding a new entry to one of the tables or modifying them. The action attribute

indicates the type of action to be performed. For example, the action number ten

corresponds to deleting an entry from the SplRelations table. The other attributes

in the tuple indicate which entry to delete. In this case, the attributes role2,

accessno and decisionptr will be null.

The ACS is aware of only a limited number of accesses. However, each

application is allowed to add its own access types. The access numbers 1 through

512 have been reserved for DCS services. The CCS uses numbers 1 through 50,

the ACS uses 51 through 100 and so on. Because of this, the ACS need not know

what the access number 21 corresponds to except for the fact that it is one of the

accesses specific to CCS. When each DCS service is instantiated for the first time,









they call the inform the ACS of their access types by calling the addAccessT,i,,'

method.

Each table has two sets of methods for adding, deleting and modifying entries.

One set directly performs these tasks and can be called only by fi i,.1,1i objects

i.e., the other DCS objects. The other set requires information about the user

making the request and then checks to see if that user (role) has the right to

perform the access. Each access request is noted on a log file and another entry

made when the result became available.

5.1.1 Conference Control Services

The CCS object instantiates the ACS. It is also responsible for 'li 1.i./' the

various DCS objects. This is done by passing the instance of each service to

the constructor as a parameter. This is a valid approach because Java passes

objects by reference. Since each service is dependent on others, the startup process

requires two phases. In the first phase, all the objects are instantiated. Once this

is done, the CSS informs each service to proceed to phase two, which means that

the other services are up and can be contacted. The CCS also informs the ACS

if this is a restart instead of a new conference. The ACS can determine this on

its own by checking for the existence of the tables. This approach was not used

because the CCS has to know this information and if the CCS does not pass this

information, each service has to make a database query to get it. If the services

are being restarted, then the createTables() method is not called. In case of a new

conference, the CCS creates two roles, Admin and Member by default and also

adds its access types to the AccessTypesTable. The creator of the conference is

bound to the Admin role. The conference is now ready to accept new users.

5.1.2 Database Services

The DBS exports two methods to access the database. The executeQ,., iif)

method takes an SQL query, executes it on the backed RDBMS and returns









the result in a ResultSet object. This is similar to a SQL cursor [24]. If no tuple

matches the query, then the ResultSet object is null. The executeUpdate( method

is more involved. Updates have to be propagated to all sites and the databases in

the different site have to be kept in sync. Details about how this is achieved are

available in Amit Date's thesis [23].

5.1.3 Decision Support Services

The ACS and the DSS have to interact closely because all decisions are taken

through the DSS. Most access requests that are allowed are expected to call the

decision template that always returns a positive answer, without starting any

vote. However, these are not handled as special cases. The DSS exports a method

start Vote) which takes in the decision pointer and a message and returns a vote

number. When the vote is decided, the DSS calls the ACS method, reportResult).

Most of the communication between the ACS and the DSS is expected to be of this

nature. For bookkeeping purposes, a few additional methods are also exported.

The ACS exports a getValidVotes) method which returns a vector of valid vote

numbers that are currently active. The DSS can also check if a particular vote

is still valid by calling the isValid) method. The ACS can check the status of a

specific vote by calling the checkStatus() method of DSS.

5.2 Testing

Software testing is a critical element of software quality assurance and rep-

resents the ultimate review of specification, design and coding [19]. There is a

slight conflict of interest in the sense that the success of testing is in identifying an

Os-v-t undiscovered error and the success of the coding is in delivering an error-free

program. Most glaring errors were caught in the coding stage itself and the testing

stage basically served as a review of the specifications. The scenarios developed

during the requirements analysis stage served as a check-list and we simulated

those scenarios during testing.









5.2.1 Unit Testing

Unit testing for the ACS was a difficult task because most methods execute

SQL commands which require the DBS. A DBS class was created to test if the

SQL commands are passed on correctly. Once this was assured, further testing was

carried out with the DBS. A DSS stub was created which lets the tester decide

the result of the votes. With this stub class, we ran the scenarios. The main bug

detected at this stage was with the intentions list. In the original implementation,

only those requests that relate to the ACS tables were entered in the intentions list

and all other votes' results were reported to the CCS. The problem arose when the

DSS calls the getValidVotes( method which did not count the non-ACS related

votes as valid because they were not entered into the intentions list. This problem

was overcome by adding a new action code which corresponds to "report to CCS"

and entering non-ACS requests with this action number. A CSS stub was also

created and the various scenarios simulated by directly calling the methods from

this class from a runScenario() method. We selected a subset of the scenarios that

would cover all the methods and in some cases, their ordering. The runScenario

method was modified for each scenario. A part of one such scenario is given below.

Assume that the conference was created by user Alice (userid 100) who is

bound to the admin role (roleid 0) by default. Bob (userid 101) is another user in

the DCS instance.











Method Callee Comments


addRole(100,1," Executive")



reportResult(1,1)




addBinding(101,2,101,1)



addbinding(100,1,101,1)



reportResult(2,1)

checkAccess(101,1,51,25,550)




checkAccess(100,0,51,25,550)



reportResult(4,1)

reportResult(3,0)


CCS


DSS




CCS



CSS



DSS

CCS




CCS



DSS

DSS


Alice requests to add new role.

The DSS returns vote number 1.

DSS reports that access is allowed.

The ACS looks up the IntentionsList and

adds the entry to roleTable (roleid = 1).

Bob requests to be bound to Executive role.

No entry in ACT. The request is denied.

Alice requests the above action.

DSS returns vote number 2.

Request is granted. ACS performs action.

Bob requests to read (accessno 550) a file

(object id 51, objecttype 25) as an

Executive. DSS returns vote number 3.

Alice requests to read the same file as

admin. DSS returns vote number 4.

Alice's request is granted.

Bob's request denied.


In the above table, Callee refers to the object which calls the method. This

is a part of one of the scenarios and tests addRole, addBinding and checkAccess

methods. Note that some of the accesses are disallowed and the ACS handled these

rejections as expected.

5.2.2 Integration Testing

Once the unit testing was completed satisfactorily and the CCS was ready, we

went ahead with the integration testing. We created conferences through the user

interface provided by the CCS object and ran the same set of scenarios as before.

One problem encountered was the CCS did not store information about the access









request. It expected the ACS to return the result of the request immediately.

Although this is usually the case, once the DSS has been completed, some access

requests may require a vote among the members and may take longer to decide.

The CCS must use some data structure similar to the intentions list to store the

information.

Another problem encountered was with the two-phase startup process. The

ACS expected the CCS to pass the other objects as parameters to the constructor.

Since the main reason for using the two-phase startup was to ensure that all

services are up before they start trying to talk to each other, the CCS sends

these objects when calling the goToSecondPhase( method. The ACS code was

modified to handle this. A few other such inconsistencies in the common interface

were identified and corrected during this stage. Communication between the

developers is really important and the errors reported during integration could

have been easily avoided if the two developers had discussed the interface in detail

beforehand.

On the whole, the current implementation of ACS for DCS version 2 is

fully integrated with the DBS and CCS modules and all the inconsistencies have

been ironed out. The implementation time was remarkably short because of the

extensive groundwork done in requirements analysis and design. In fact, it took

longer to completely test the module than to implement it. The integration with

DBS and, to a very large extent, CCS was problem less. The minor problems

that cropped up were due to lack of communication and could have been avoided.

The developers of other modules that are under development and those yet to be

developed should have a clear idea of what services are provided by the ACS and

should therefore be able to interact with ACS without any problems.















CHAPTER 6
CONCLUSION

The access control model described in this thesis is used in the Distributed

Conferencing System version 2 (DCS v.2). However, this model can be used in any

distributed system that requires highly available access control servers and user

driven decision making capabilities. As seen in chapter four, this model satisfies

many interesting properties of access control systems and supports user-defined

voting templates. With the current design, the Conference Control Services has

been able to support conferences, starting from creation, through the day-to-day

running of the conference till deletion. The access scenarios developed to help

understand the requirements provided exhaustive test cases.

Although the exact design of the Decision Support Service (DSS) is not yet

nailed down, there are quite a few possible templates that have to be defined

as a part of the requirements and the DSS is expected to allow users to define

their own templates. The modular structure of the DCS allows us to ignore the

implementational details of the templates and refer to the template index in the

ACS. Adding new templates and modifying existing ones is in turn an access to the

templates object and is controlled by the ACS.

The Database services (DBS) provide the backed database management

capabilities which are used by the ACS. It must be noted that actions like creating

a new database etc. is also an ACS controlled action. Hence all the services are

inter-linked and are able to interact with one another.

There are a few modifications that can improve the performance of ACS and

also provide better service. For instance, the access control table is a replicated

database. While this ensures quick response, it can also add to the network traffic









and an update may take some time to reach a particular site which in turn may

lead to confusion. To avoid this, it is a good idea to have a partitioned database.

Each object is located in one of the sites in the DCS instance and storing access

control information about that object in that site alone is an idea similar to the

Access control lists discussed in chapter two.

Another area that requires further work is the special permission. While the

current implementation supports special privileges to specific users, the concept is

not clearly defined and more work is needed in that direction. It is also possible for

a careless user to lock a particular object from being used by tampering with the

templates. We must provide some mechanism for the conference to undo or redo

any action.

On the whole, the ACS implemented for the DCS is a major step towards

incorporating democratic mechanisms to access control by giving the members of

the conference more control over the conference. While more work needs to be done

to complete the task, this thesis gets us started in that direction and it is hoped

that the task is taken closer to completion in the near future.















REFERENCES


[1] Wei Hu, DCE Security FP."ii i'./'i i'"i O'Reilly & Associates, Sebastopol, CA,
1995.

[2] R. E. Newman, C. L. Ramirez, H. Pelimuhandiram, M. Montes, M. Webb,
and D. L. Wilson, "A Brief Overview of the DCS Distributed Conferencing
Sy-t. i in Proceedings of Summer USENIX Conference, USENIX, 1991, pp.
437-452.

[3] S. J. Greenwald, The Distributed Compartment Model for Resource Man-
agement and Access Control, Ph.D. dissertation, University of Florida,
1994.

[4] P. H. Wood and S. G. Kochan, UNIX System Security, Hayden Books,
Indianapolis, 1985.

[5] Charlie Kaufman, Radia Perlman, and Mike Speciner, Network Security,
Private Communication in a Public World, Prentice Hall PTR, Upper Saddle
River, NJ, 1995.

[6] Charles P. Pfleeger, Security in Computing, Prentice Hall Inc., Upper Saddle
River, NJ, 1996.

[7] B. W. Lampson, "Protection," in Proceedings of 5th Princeton S,,I .-
slum on Information Sciences and Siui, Princeton, 1971, pp. 437-443.

[8] G. S. Graham and P. J. Denning, "Protection-Principles and Practice," in
Proceedings of Spring Joint Computer Conference, AFIPS, 1972, pp. 417-429.

[9] M. A. Harrison, W. L. Ruzzo, and J. D. Ullman, "Protection in Operating
Systems," Communications of the ACM, vol. 19, no. 8, pp. 461-471, August
1976.

[10] P. E. Ammann and R. S. Sandhu, "Safety Analysis for the Extended
Schematic Protection Model," in Proceedings of IEEE Si,,! ... i,,In on
Research in Security and PF ;*, i, IEEE, 1991, pp. 87-97.

[11] R. S. Sandhu, "The Typed Access Matrix Model," in Proceedings of IEEE
SiiI' ...'ii; on Security and PFi,;,', IEEE, 1992, pp. 122-136.









[12] R. S. Sandhu, "The Schematic Protection Model: Its Definitions and
Analysis for Acyclic Attenuating Schemes," Journal of ACM, vol. 36, no. 2
pp. 404-432 1988.

[13] R. S. Sandhu and G. S. Suri, "Implementation considerations for the
Typed Access Matrix in a Distributed Environment," in Proceed-
ings of the 15th NIST-NCSC National Computer Conference, NIST, 1992,
pp. 221-235.

[14] Randy Chow and Theodore Johnson, Distributed Operating Sif.' i,
Algorithms, Addison-Wesley, Reading, MA, 1997.

[15] Susan Stepney and Stephen P. Lord, "Formal Specification of an Access
Control System," Sf,,ftf,,, Practice and Experience, vol. 17, no. 9 pp.
575-593 1987.

[16] David F. Ferraiolo, Janet A. Cugini, and D. Richard Kuhn, "Role-based
Access Control (RBAC): Features and Motivations," National Institute of
Standards and Technology, Gaithersburg, 1992.

[17] David Ferraiolo and Richard Kuhn, "Role-based Access Control," in
Proceedings of the 15th NIST-NCSC National Computer Conference, NIST,
1992, pp. 437-443.

[18] }Eleen Frisch, Essential System Administration, O'Reilly & Associates, New
York 1996.

[19] Roger S. Pressman, .fit,,,,'*,' Engineering-A Practitioner's Approach,
McGraw-Hill, New York, 1997.

[20] Donald C. Gause and Gerald M. Weinberg, Exploring Requirements: Qu,,oitf
before Design, Dorset House, New York, 1989.

[21] Ian Sommerville, S,.flt,,',,' Engineering, Addison-Wesley, Harlow, England,
1995.

[22] Bruce Eckel, Ti,;il .;i,/ in Java, Addison-Wesley, Upper Saddle River, NJ,
2000.

[23] Amit V. Date, Implementation of Distributed Database and Reliable Multicast
for Distributed Conferencing System version 2, Master's thesis, University of
Florida, 2001.

[24] Ramez Elmasri and Shamkant B. Navathe, Fundamentals of Database
Sufii,, Addison-Wesley, Upper Saddle River, NJ, 1994.















BIOGRAPHICAL SKETCH


Vijay Manian was born in Chennai, India, in 1977, the son of Padma and S

V S Manian. He has two elder sisters, Chithra and Vidya. After completing his

primary schooling in Chennai, he attended Ida Scudder School, Vellore, India,

where he completed his X. He completed high school from Padma Seshadri Bala

Bhavan Junior College, Chennai, in 1995. He received a Bachelor of Engineering

degree in computer science and engineering from the University of Madras in

1999. He then decided to pursue his master's degree in computer science from

the University of Florida's Computer and Information Sciences and Engineering

Department in 1999. He is currently working on his Ph.D. in computer engineering.