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: 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 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  [1]. 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 library 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 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

referred to as the "home" collection of the dependent sub-collections and items. The DL environment is defined as follows:

AUTHORIZATIONS 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 sub-collection. 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] .

User Authorizations

The following levels of authorization are defined in our DL environment:

DLADMIN. This is the DL "superuser" privilege and provides full access to and control of the DL and all its collections. This privilege can be assigned to a user either by a well-identified user in the system, or by a user with root privileges in the system.

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.

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 authorization to any other user.

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.

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.

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 sub-collection 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.

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.

Object: Collection

                            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

REFERENCES

1. 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.
2. 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 home page, http://www.npaci.edu/DICE/.
4. DB2 Version 2.1.1 SQL Reference Manual, IBM.