|
Journ31l oi un.nderr.3du.3ae .e-_-.earch
..oluine 4, is.ue ' - June . i:l:i-
Role-Based Access Control Systems In Digital Libraries
Jeremiah Blanchard
ABSTRACT
Digital libraries allow people from distant places to access organized collections of information through the
Internet. The access scheme of a system plays a key part in determining the security and flexibility of the
system. Traditional, hierarchical access schemes, unless modified to allow group systems to function, provide
limited flexibility in assigning access rights to users. By building a role-based access control scheme into a
digital library system as the most basic level of security, a more flexible approach can be taken in assigning
user access rights. The goal of this project was to implement in a digital library system the functions of the
"Core RBAC" requirements of A Proposed NIST Standard for Role-Based Access Control (Ferraiolo et al, 2001.)
INTRODUCTION
Background and Problem Domain
Digital Libraries. Libraries have been serving people's needs for easily locatable information throughout
history. Scholars have long depended on traditional libraries in order to fulfill their information needs. For
years people have used libraries to do academic research as well as fulfill intellectual desire for knowledge,
and traditional libraries are common today in many societies. However, with the advent of computers and
the Internet, the traditional information access methods are being supplanted with and increasingly displaced by
new digital methods. Information accessibility is no longer completely dependent on location. The Internet has
made it possible to access a vast body of information from anywhere in the world, allowing even greater access
to information, and digital libraries further extend this access by providing organization and filtering. (Chen, 1998.)
Role Based Access Control (RBAC). Some access systems are hierarchical in nature and others provide
only simple, one-group-per-user access model. In a hierarchical model, users of a higher security level have
access to information at that security level in addition to all of the information at lower security levels (see figure
1.) As such, a user at a lower security level cannot have exclusive access to any resource (because users at
higher levels also have access to that resource.) Using the one-group-per-user model, exclusive access can
be obtained, but only at the cost of complicating overlapping access rights. When some user should be given
the access rights of two different groups, a new group must be created encompassing those two (because the
user cannot belong to two separate groups) (see figure 2.)
Figure 1. Hierarchical Security System.
Figure 2. Simple Group System.
Role Based Access Control (RBAC) systems provide a layer of security beyond that of hierarchical or simple
one-group-per-user systems. The roots of role-based systems began to appear 25 years ago in the group systems
of some operating systems, most notably UNIX. In a role-based system, all users are assigned one or more
"roles" that dictate what resources they may access. Roles may also inherit other roles. RBAC provides all
the benefits of hierarchical and simple group-based systems provide without some of the limitations (such
as exclusive access via role as opposed to level and overlap without complication.) The hierarchical and simple
group models can be completely emulated by a role-based system with relative ease by making each security
level and group a role. RBAC allows a series of greater and lesser access levels like a hierarchical system, but
also allows for separate role groups that are neither above nor below one another, each instead having access
to resources that the other does not. (Ferraiolo et al, 2001.)
LOVE Server. The Learning Object Virtual Exchange server, or LOVE server, is a specialized digital library
system built for the purpose of providing a forum for students, teachers, and researchers to exchange information.
It was designed to have an open architecture and to provide flexibility as an interactive environment. The
LOVE server is part of the National Biology Digital Library (NBDL) project funded by the National Science
Foundation (NSF.) The LOVE server serves as a repository for classroom materials and research information
that takes the form of various online materials. Entries are stored in an extensive database as Extensible
Markup Language (XML) metadata. Materials may be posted to the server, where they may be reviewed and used
by teachers and students (Choo, 2002.).
Purpose and Motivation
The LOVE server originally used a simple group scheme for security. Several roles were combined into one group
(for example, teachers and content authors) because no user could be a part of more than one group at any
time. This prevented varying access to different parts of the materials (teachers and authors therefore had access
to read information from all authors and post reviews of those pieces.) A system to provide assignment of
reviewers to review a given piece was needed. In addition, a system of intellectual property protection, allowing
all teachers but only certain students, authors, or reviewers to access a given piece of information (and allowing
only the proper reviewer to post a review) could not be implemented within the simple group model.
FINAL SOLUTION
Overview
In order to provide the LOVE server with a more robust system of access, the group system was replaced with a
role based system, emulating the previous system when needed but providing a simpler way to modify and
tweak access to given groups of users to allow for exclusive access by certain groups. This was be done
by implementing most of the "Core RBAC" requirements of the Proposed NIST Standard for Role-Based
Access Control (Ferraiolo et al, 2001.) In addition, various tools were constructed to aid in web-based
management of the role system and to assign reviewers to review certain learning objects in the LOVE
database. Tasks were then limited to the appropriate role (for example, everyone but reviewers was prevented
from posting reviews.) Finally, in a test of the robustness of the new role-based system, an experimental
learning object intellectual property scheme was implemented which allowed users to purchase access to
learning objects.
RBAC Implementation
The RBAC security scheme was added to the system by first creating a new table in the database to store
role information. This table included fields for the role's index number, name, a delineated list of inherited
roles' indexes, and a delineated list of forbidden roles' indexes. In addition, a "roles" field was added to the
user table, each entry containing a delineated list of the given user's roles' indexes. The old, deprecated group
field was then removed from the table.
Next, a static Java RBAC toolbox class was added to the system. The role of this toolbox was to provide all
necessary RBAC functions needed to implement the changes to the system. This toolbox included methods to:
a Fetch a user's list of role indexes
a Convert a list of role indexes into an array of role names
a Convert an array of role names into a list of role indexes
a Check a given user's membership in a given role
a Check for a given role within a list of role indexes
a Provide easily modifiable methods for checking for varying levels of access to certain resources by certain roles
The last step in implementing the RBAC system was going throughout the system and changing all previous
group security checks into role checks. Each check for a specific group was replaced with a check to the
appropriate role or roles.
Role Access Clarification
With the ability of users to belong to more than one role, it became possible to more clearly delineate the
differences between the roles. Former groups (consisting of several roles that needed to be combined due to the
limit of users to only one group) could now be split into different roles, with each user belonging to one or more
of them. The teacher/author and reviewer/curator groups were split into four roles: teacher, author, reviewer,
and administrator. The system access methods, created during the implementation, were then modified to allow
only teachers and authors to read all materials, only reviewers to post reviews, and only authors to modify
resources. Authors were further limited to accessing only their own resources through the use of an 'author'
database table that listed the author's user ID number and all materials created by that author (in a delineated
list.) The 'administrator' role was created to inherit all other roles, giving administrators full access to all
information and functions.
WEB-BASED ADMINISTRATION
Roles
In order to easily administer the role database table and role system, a role administration tool was added to the
web-based LOVE server (with access limited to the 'administrator' role.) This tool allowed for the easy
addition, modification, or removal of roles currently in the role database table. This tool allowed for the
inheritance and/or denial of inheritance of single or multiple roles. The tool searched each inherited role recursively
to avoid a role's inheritance of a denied role or of itself.
Review Assignment
A tool was also needed to assign reviews to reviewers. First, the review system was modified to allow only
reviewers assigned to review a given piece the right to post a review. This was done by adding a 'reviewer' table
to the database containing each reviewer's user ID and a delineated list of those pieces to which the reviewer
had been assigned. A web-based tool was then added which listed all users with the 'reviewer' role and all
works currently in the database. The administrator could use this tool to assign a review to a particular
reviewer, thereby granting access for the user to review the piece.
User Information
A simple tool for modifying user information was also added to the LOVE server. This allowed the administrator
to change user information, in particular user roles. This utility was useful in making a smooth transition from the
old system to the new system, because each user could then be modified to replace the former group with one
or more roles.
INTELLECTUAL PROPERTY SYSTEM
As a test of the system's ability to juggle the access requirements of the RBAC system, an intellectual
property system was implemented. In this system, students had a certain number of "credits" with which they
could "purchase" articles on the system. These "purchased" article rights would then expire after a certain amount
of time.
The first step in adding this system to the server was to add a "credits" field to the user table. For simplicity, this
test assumed that one credit could purchase one article. A table was then added to track each student's
purchased article rights. This table included a user ID and a delineated list of article ID/time stamp components
for each student. The RBAC module's access code was then modified to check the timestamp and rights of a user
with the "student" role before allowing read access to that article.
The last step in implementing this system was the addition of a web-based tool to purchase articles. When a
search was performed by a user with the "student" role, each result, when clicked, would display the result page
with a "Purchase Article" link at the top. This would decrease the user's "credit" field by one and add the article to
the user's entry in the "student" table.
CONCLUSION
Results
Implementing the primary Core RBAC functions can be helpful in a system such a LOVE, in which
users belonged to only one group, in order to differentiate between overlapping access groups
and groups to which more than one user might belong. The LOVE server can now provide more
refined access flexibility. Access rights, now separated into the RBAC module, can also be easily
modified to further tweak access without coursing through thousands of lines of code.
Finally, it is important to note that one key requirement of the Core RBAC - that users use the
access rights of only one role at a time (an "active role") - was not implemented because in the case
of LOVE, it would be less convenient for users to switch roles every time they required access
to materials whose rights did not fall within the current active role. The implementation of the
"active role" is not significantly difficult and could be added at a later time if so desired.
Future Research
The intellectual property system is an interesting concept that could be expanded (or rewritten) to
be used in an electronic repository or to allow libraries greater flexibility in distributing
copyrighted works. While the "credit" system is not well suited for public library work
distribution (where most, if not all, works are available for free), it could be used in an electronic
article repository for copyrighted commercial research, or some similar system. The system could also
be modified to allow a user access to any article for a limited period of time, denying other users
access to that article for that time period (the electronic equivalent of "checking out" a book.)
REFERENCES
C. Choo, "Digital Libraries and Learning Object Research," Graduate Thesis, University of
Missouri-Columbia, MO, August 2002.
S. Chen, "Digital Libraries: The Life Cycle of Information," Better Earth Publisher, 1998, http://
www.amazon.com
D. Ferraiolo, R. Sandhu, S. Gavrila, D. Kuhn, & R. Chandramouli, "A Proposed NIST Standard for
Role-Based Access Control", ACM Transactions on Information and System Security, August 2001.
--top--
Back to the Journal of Undergraduate Research
College of Liberal Arts and Sciences I University Scholars Program I University of NIVERSITY of
Florida I . ,,flon P., r.- ,Nawr
@ University of Florida, Gainesville, FL 32611; (352) 846-2032.
|
