Role-Based Access Control Systems In Digital Libraries

blanchard.pdf

blanchard_Page_6.txt

blanchard_pdf.txt

EGNWNNHNZ_BHTN97_xml.txt

blanchard_Page_1.txt

blanchard_Page_4.txt

blanchard_Page_7.txt

blanchard_Page_3.txt

blanchard_Page_2.txt

blanchard_Page_5.txt

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.

PAGE 1

Journal of Undergraduate Research Volume 4, Issue 9 June 2003Role-Based Access Control Systems In Digital LibrariesJeremiah Blanchard ABSTRACTDigital 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.)INTRODUCTIONBackground 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

PAGE 2

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

PAGE 3

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 SOLUTIONOverview 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:

PAGE 4

Fetch a user's list of role indexes Convert a list of role indexes into an array of role names Convert an array of role names into a list of role indexes Check a given user's membership in a given role Check for a given role within a list of role indexes 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 ADMINISTRATIONRoles 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

PAGE 5

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 SYSTEMAs a test of the systems 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 students purchased article rights. This table included a user ID and a delineated list of article ID/time stamp components for each student. The RBAC modules 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 users credit field by one and add the article to the users entry in the student table. CONCLUSION Results

PAGE 6

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.) REFERENCESC. 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

PAGE 7

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 | University Scholars Program | University of Florida | University of Florida, Gainesville, FL 32611; (352) 846-2032.


xml version 1.0 encoding UTF-8
REPORT xmlns http:www.fcla.edudlsmddaitss xmlns:xsi http:www.w3.org2001XMLSchema-instance xsi:schemaLocation http:www.fcla.edudlsmddaitssdaitssReport.xsd
INGEST IEID EGNWNNHNZ_BHTN97 INGEST_TIME 2011-05-31T20:43:28Z PACKAGE UF00091523_00210
AGREEMENT_INFO ACCOUNT UF PROJECT UFDC
FILES