Using terminology from database systems, an authorization allows users or user groups to perform general tasks such as creating and administering a collection ...
A Hierarchical Access Control Scheme for Digital Libraries Chaitanya Baru, Arcot Rajasekar Enabling Technologies Group San Diego Supercomputer Center La Jolla, CA 92093, USA Tel: 6 19-534-5035, FAX: 6 19-822-0906 E-mail: baru @sdsc.edu referred to as the “home” collection of the dependent subcollections and items. The DL environment is defined as follows:
ABSTRACT
We present an access control scheme that extends the authorization/privilege model employed in database systems to handle the notion of digital library collection hierarchies. This scheme is being implemented within the digital library infrastructure at the San Diego Supercomputer Center. KEYWORDS:
A DL contains zero or more collections. A collection contains zero or more sub-collections and zero or more items. A sub-collection contains zero or more other subcollections and zero or more items. An item is an “atomic” element of a DL
Digital library, access control, security.
INTRODUCTION
As part of the NSF National Partnership for Advanced Computational Infrastructure (NPACI), the Data Intensive Computing Environments (DICE) group at the San Diego Supercomputer Center (SDSC) is involved in building advanced distributed data handling environment. A major focus of this effort is in building distributed digital libraries (DLs) of scientific data for use in research and education. The Digital Library
Environment
Any object may have other dependent items associated with it, e.g. metadata. We do not discuss access control issues associated with dependent items in this paper. AUTHORIZATIONS
at SDSC
The NPACI data handling environment includes archival storage systems, database systems, and distributed storage systems. SDSC has developed the Storage Resource Broker (SRB) to provide a uniform interface to distributed, heterogeneous storage resources [ 11. The SRB uses a metadata catalog (MCAT) to provide attribute-based access to data sets. Among other features, MCAT implements a logical, collection-based abstraction of the data stored in the SRB [2]. The access control scheme presented in this paper is a part of the SRB/MCAT infrastructure. This infrastructure
is being
used to support
several
digital
User Authorizations
The following levels of authorization are defined in our DL environment:
library
DLADMIN. This is the DL “superuser” provides full access to and control of the collections. This privilege can be assigned by a well-identified user in the system, or root privileges in the system.
efforts at SDSC including a U.S. patent digital library, the UC Berkeley ELIB, UC Santa Barbara’s Alexandria Digital Library, and a digital library for environmental data [3]. COLLECTION
AND PRIVILEGES
Using terminology from database systems, an authorization allows users or user groups to perform general tasks such as creating and administering a collection and/or a subcollection. Whereas, a privilege provides a user or user group the right to access a collection, sub-collection, or item in a specific way (e.g. read vs. modify), or to perform specific operations on it (e.g. index creation vs. summarization) [4].
HIERARCHIES
The SDSC model organizes digital libraries into hierarchies of collections, sub-collections, and items. The collection is at the root of the hierarchy. The root collection is also
privilege and DL and all its to a user either by a user with
CADMIN. This is the Collection Administrator authorization which can be granted only by a DLADMIN. A CADMIN is allowed to create new collections and delete collections that she/he has created, and has full control on such collections and their entire contents.
permission to m‘ake digital or hard copies of ail or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy othet&se, to republish, to post on servers or to redistribute to lists, requires prior specitic permission and/or a fee.
Curator. The user who creates a collection automatically receives Curator authorization on that collection. By the above definitions, this “initial” Curator must either be a CADMIN or DLADMIN. However, the “initial” Curator, or any DLADMIN, can subsequently extend the Curator
Digital Libraries 98 Pittsburgh PA USA CopyrightACM 1998 O-89791-965-3/98/ 6.SS.00
275
authorization to any other user.
Object: Collection
By default, users do not possess either DLADMIN or CADMIN authorization. These authorizations need to be explicitly granted to users according to the granting rules stated above. However, users can be extended a variety of privileges on DL objects, as discussed below. The grantor of a privilege must have the necessary privilege to be able to do so. The CADMIN authorization level allows DLADMINs to grant the authorization to create and curate collections to other users. In contrast, database systems maintain tighter control on database creation. Only SYSADMINs (similar to DLADMIN) are allowed to create databases. While this suits the production environment of a typical DBMS, we wish to support a more open environment consisting of many collections created and maintained by sophisticated technical users. The CADMIN authorization level provides this flexibility.
Create Privilege: { CADMIN, DLADMIN) Control: (Creator, all users granted Control privilege on the collection, DLADMIN) Privileges: Read, Create-Subcollection , Create-Item, Grant-Ticket: grantor must have control privilege on collection Control: grantor must be creator or DLADMIN. Note that the Create-Subcollection privilege subsumes the Create-Item privilege.
Object: Sub-Collection Creute Privilege: (Users with Create-Subcollection privilege on parent sub-collection, users with control privilege on parent and any ancestor sub-collection, Curators of the “home” collection, DLADMIN) Control: {Creator, users with control privilege on parent and any ancestor sub-collections, Curators of “home” collection, DLADMIN} Privileges: Read, Create-Subcollection, Create-Item, Grunt-Ticket: grantor must have control privilege on sub-collection Control: grantor must be Curator or DLADMIN.
User Privileges
User privileges are discussed in the context of collections, sub-collections, and items. For each, we list the following information, (1) Users who have the privilege to create this type of object, (2) Users with control privilege on the object, (3) All “grantable” privileges associated with the object, and (4) Level of authorization required to grant each privilege to another user. First we list some properties of our access control scheme.
Object: Item Create Privilege: {Users with Create-Item privilege on parent sub-collection, users with control privilege on parent and any ancestor sub-collection, Curators of “home” collection, DLADMIN} Control: (Creator, users with control privilege on parent and any ancestor sub-collections, Curators of “home” collection, DLADMIN} Privileges: Read, Modifi, Grant-Ticket: grantor must have control privilege on item Control: grantor must be Curator or DLADMIN.
The control privilege on an object implies all rights to that object, including the right to delete it. However, it does not necessarily imply the privilege to grant control to another user. The control privilege is recursively defined, thus, the creator of a collection has control privilege on all nested sub-collections and items defined within that collection. The same applies to sub-collections. A user who has control privilege on a sub-collection, SC, can create another subcollection or item anywhere in the hierarchy rooted at SC. While we focus on privileges for standard operations (read, create), our system accommodates an extensible set of privileges. As new operations, such as indexing, summarization, and annotation, are introduced, one can control a user’s rights to invoke these operations on an object.
Note that this definition allows us to implement different rules for granting control privilege on collections versus control on contents of collections. Control on a collection can be granted only by the creator of that collection or by DLADMIN.
Our scheme also supports a ticket mechanism, which is a restricted form of read privilege. It allows a user to control the duration, or the number of times, a particular object is read. The Grant--Ticket privilege on an object allows one to create tickets on the object and issue them to other users. User A may grant the Grant-Ticket privilege to User B on object X. User B can then create a ticket on object X and issue it to users C, D, and E. The issuer of a ticket can revoke the ticket at any time.
REFERENCES
276
I.
Baru et al, “A data handling architecture for a prototype federal application,” Procs. of the IEEE Conference on Mass Storage Systems, College Park, MD, March 1998.
3-.
Baru et al, “Metadata to support information based computing environments,” Procs. of the IEEE Conference on Metadata, Silver Spring, MD, Sept. 1997
3.
The NPACI DICE http://www.npaci.edu/DICE/.
4.
DB2 Version 2. I. I SQL Reference Manual, IBM.
home
page,
