|UFDC Home||myUFDC Home | Help|
This item has the following downloads:
ACCESS CONTROL MODEL FOR DISTRIBUTED CONFERENCING SYSTEM
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
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
ACKNOW LEDGMENTS ............................. ii
ABSTRACT ....................... ............ vi
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
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
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 . 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 . 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 . In such
systems, there is a centralized authority that manages access to all objects in the
system. In operating systems like UNIX , 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.
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
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
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
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 .
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 .
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
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
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
Figure 1.1: Architecture of DCS
SURVEY OF RELEVANT WORK
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 , 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 . Graham and Denning  constructed a
model having generic protection properties. This model is simple and is widely
used as the basis for many security systems .
The access matrix model as described by Graham-Denning has the following
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
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  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 . The Typed Access Matrix (TAM)  defined by Sandhu combines
strong safety properties for propagation of access rights of Schematic Protection
Model  with the natural expressive power of the HRU model. TAM is obtained
by incorporating strong typing into the HRU model . 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; ...;''
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
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 . 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.
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
ADMIRAL is a collaborative project carrying out research into the use and
management of high performance networks. Stepney and Lord  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.
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).
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
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
The Distributed Computing Environment (DCE) from the Open Software
Foundation (OSF) covers more platforms and offers more features than most other
client/server technology . The DCE Security Framework (or model) is simpler
than real-life situations and omits implementation details.
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.
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
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 . 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 . In
RBAC, users do not have discretionary access to enterprise objects. Instead, access
permissions are associated with roles and users are associated with roles.
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 . 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
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
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.
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
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 . However, UNIX is by design a very robust system. The
following is a brief discussion of the basic principles in UNIX access control.
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 . 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
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 .
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
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 .
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 . 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
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
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
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-
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
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 . 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
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 . 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
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
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
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
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
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-
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
16. Dan creates a new object type writer document and imports four new
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
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
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
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
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.
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
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
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
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
. 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 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
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
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
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
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
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
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.
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 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
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.
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.
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 . 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 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 . 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
Access Control Table
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
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,,'
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 . 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 .
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.
Software testing is a critical element of software quality assurance and rep-
resents the ultimate review of specification, design and coding . 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
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
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
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.
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
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.
 Wei Hu, DCE Security FP."ii i'./'i i'"i O'Reilly & Associates, Sebastopol, CA,
 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.
 S. J. Greenwald, The Distributed Compartment Model for Resource Man-
agement and Access Control, Ph.D. dissertation, University of Florida,
 P. H. Wood and S. G. Kochan, UNIX System Security, Hayden Books,
 Charlie Kaufman, Radia Perlman, and Mike Speciner, Network Security,
Private Communication in a Public World, Prentice Hall PTR, Upper Saddle
River, NJ, 1995.
 Charles P. Pfleeger, Security in Computing, Prentice Hall Inc., Upper Saddle
River, NJ, 1996.
 B. W. Lampson, "Protection," in Proceedings of 5th Princeton S,,I .-
slum on Information Sciences and Siui, Princeton, 1971, pp. 437-443.
 G. S. Graham and P. J. Denning, "Protection-Principles and Practice," in
Proceedings of Spring Joint Computer Conference, AFIPS, 1972, pp. 417-429.
 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
 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.
 R. S. Sandhu, "The Typed Access Matrix Model," in Proceedings of IEEE
SiiI' ...'ii; on Security and PFi,;,', IEEE, 1992, pp. 122-136.
 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.
 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,
 Randy Chow and Theodore Johnson, Distributed Operating Sif.' i,
Algorithms, Addison-Wesley, Reading, MA, 1997.
 Susan Stepney and Stephen P. Lord, "Formal Specification of an Access
Control System," Sf,,ftf,,, Practice and Experience, vol. 17, no. 9 pp.
 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.
 David Ferraiolo and Richard Kuhn, "Role-based Access Control," in
Proceedings of the 15th NIST-NCSC National Computer Conference, NIST,
1992, pp. 437-443.
 }Eleen Frisch, Essential System Administration, O'Reilly & Associates, New
 Roger S. Pressman, .fit,,,,'*,' Engineering-A Practitioner's Approach,
McGraw-Hill, New York, 1997.
 Donald C. Gause and Gerald M. Weinberg, Exploring Requirements: Qu,,oitf
before Design, Dorset House, New York, 1989.
 Ian Sommerville, S,.flt,,',,' Engineering, Addison-Wesley, Harlow, England,
 Bruce Eckel, Ti,;il .;i,/ in Java, Addison-Wesley, Upper Saddle River, NJ,
 Amit V. Date, Implementation of Distributed Database and Reliable Multicast
for Distributed Conferencing System version 2, Master's thesis, University of
 Ramez Elmasri and Shamkant B. Navathe, Fundamentals of Database
Sufii,, Addison-Wesley, Upper Saddle River, NJ, 1994.
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.