A Thesis entitled Efficient Isolation Enabled Role-Based Access Control for Database Systems by Mohammad Rahat Helal Submitted to the Graduate Faculty as partial fulfillment of the requirements for the Master of Science Degree in Engineering Dr. Weiqing Sun, Committee Chair Dr. Ahmad Y. Javaid, Committee Co-Chair Dr. Mansoor Alam, Committee Member Dr. Hong Wang, Committee Member Dr. Amanda Bryant-Friedrich, Dean College of Graduate Studies The University of Toledo August 2017 Copyright 2017, Mohammad Rahat Helal This document is copyrighted material. Under copyright law, no parts of this document may be reproduced without the expressed permission of the author. An Abstract of Efficient Isolation Enabled Role-Based Access Control for Database Systems by Mohammad Rahat Helal Submitted to the Graduate Faculty as partial fulfillment of the requirements for the Master of Science Degree in Engineering The University of Toledo August 2017 A user is denied access in a typical Role-Based Access Control (RBAC) system if the system recognizes the user as an unauthorized user. This situation could lead to delay in essential work to be performed in the case of an emergency or an unavoidable circumstance. In this thesis, we propose designing and implementing Isolation enabled RBAC at the record level in a database. The concept involves integrating transaction isolation concepts of a relational database management system (RDBMS) into the NIST RBAC model securely and efficiently. Our proposed system allows the user limited access to the system instead of complete denial. One such example being, the senior role could delegate restricted access to the junior role. Using this restricted access, the junior role can perform actions which are mandatory to be conducted on behalf of the senior role. The system has been designed in a way to keep it secure, efficient, available and consistent. The proposed system enhances the security of and ease of access to the system in the absence of an authorized user by restricting unauthorized user access to only an isolated view of the database. Moreover, in that scope of access, he/she can perform actions that are isolated from other users. The thesis presents design and implementation of the concept and compares our work with the approach followed by other RBAC implementations. iii To my father Mohammad Habibur Rahman, my mother Late Rafat Sultana and my sister Rehana Firdaus for their immense love, care and perseverance to raise me to this level and higher in all odds. Acknowledgments I would like to express my gratitude towards every individual who has in some way helped me achieve my dream of completing Master's degree. It has been a great academic journey here, especially when it started after a long gap of a break from studies. I would thank my adviser Dr. Weiqing Sun to provide me an opportunity to work with him and guide me at every step with patience and perseverance. I would also like to thank my co-adviser Dr. Ahmad Yazdan Javaid for his immense support for showing me the proper direction and encouraging me to take appropriate steps time to time. I would like to thank Dr. Mansoor Alam, EECS and ET Department and my thesis committee member Dr. Hong Wang for taking time out from their busy sched- ule to serve on my thesis evaluation committee and provide valuable comments and suggestions to improve my work. I would like to thank COGS for providing me graduate assistantship. It was a pleasure working with Dr. Amanda-Bryant Friedrich and all the COGS staff. I feel honored to have worked with my supervisor Teresa Hayes, and co-workers Elaine Coopshaw and Mary Main. I would like to thank Quamar for motivating me at every step right from admission to choosing thesis. My gratitude would be incomplete without thanking my friends Bhavana, Shahrukh, and Farid for memorable and learning experiences. And at last, I would also like to thank my family and friends from undergraduate days and good old industry days for always motivating and supporting me. v Contents Abstract iii Acknowledgments v Contents vi List of Tables viii List of Figures ix List of Abbreviations xi 1 Introduction 1 1.1 Role Based Access Control . 1 1.2 Transaction Isolation Levels in a database system . 5 1.3 Background and Motivation . 7 1.4 Related Works . 8 1.5 Research objective and contributions . 10 1.6 Dissertation Outline . 11 2 Isolation enabled Role Based Access Control 12 2.1 Definition of Isolated environment . 12 2.2 Implementation of Isolated system in a Health-care facility . 17 2.2.1 Purpose of using Isolated System . 17 2.2.2 Proposed Isolated system . 18 vi 3 System Design 22 3.1 Design Steps . 25 3.1.1 Design a basic RBAC model . 25 3.1.2 Design Isolated system layer . 26 3.1.3 Define Isolated system attributes . 26 3.1.4 Design scripts for handling records in both environments . 28 3.1.5 Post Isolated system changes . 30 4 System Implementation 31 4.1 Database Level Implementation . 32 4.2 Logic of data flow . 36 4.3 Realization of Isolation at database level . 38 4.3.1 Scenario 1 . 39 4.3.2 Scenario 2 . 40 4.3.3 Scenario 3 . 42 5 Future Work and Conclusion 45 5.1 Future Works . 45 5.2 Conclusion . 46 References 47 vii List of Tables 4.1 Attributes in Isolated System . 38 4.2 Old vs New attribute values for record in Isolated System . 38 4.3 Parameters for latest record in Isolated System . 39 viii List of Figures 1-1 Core RBAC display [16] . 2 1-2 RBAC system process [18] . 3 2-1 I-RBAC process flow-chart [18] . 14 2-2 A typical RBAC policy table . 16 2-3 Role table . 20 2-4 Permissions table . 20 2-5 Objects table . 20 2-6 I-RBAC Policy table . 20 3-1 System Design Flow Chart . 23 3-2 Isolated and Host Users handling records at Isolated and Host System . 27 3-3 Scripts invocation and handling in both the environments . 28 4-1 Sample tables comprising the Host and Isolated system . 32 4-2 Snapshot of an unauthorized user logged into Isolated System . 35 4-3 Records to be approved, rejected or further reviewed . 36 4-4 First session unable to read the record inserted by second session . 39 4-5 After commit operation, first session can read the inserted record . 40 4-6 Individual inserts in two sessions can be read in respective sessions only . 41 4-7 After commit, both sessions can read the committed records . 41 4-8 Second session trying to update the same record is in locked state . 42 ix 4-9 Session 1 commits, so session 2's statement gets executed, but the overall state of database is inconsistent . 43 4-10 Consistent state of database after both sessions commit . 43 x List of Abbreviations ABAC . Attribute based access control ACID . Atomicity, Consistency, Isolation, and Durability BTG . Break the glass I-RBAC . Isolation Enabled Role Based Access Control NIST . National Institute of Standards and Technology RBAC . Role Based Access Control RDBMS . Relational Database Management System SRBAC . Spatial Role-based access control TRBAC . Temporal Role Based Access Control xi Chapter 1 Introduction 1.1 Role Based Access Control Role-Based Access Control (RBAC) is an access control mechanism that is based on the functions that could be performed by the users in an organization [1]. The access permission cannot be transferred between the users at their will. It is concerned with access to functions and information contained in an organization. Therefore, the concept of Role and Permissions arises [16]. It offers the flexibility of adding users to an organization and associates the users with their respective roles, while permissions are assigned to objects based on their roles. Using the user and role information, the concept of \User Assignment" mapping is built. This maps the users to their roles in an organization. This segregates other functionalities offered by the system regarding adding and removing users. Similar to this mapping, the concept of \Permission Assignment" is introduced, where the permission on objects in any organization is mapped to the roles using elements such as roles, permissions, and objects. As is understood from the definitions of the two mappings, user assignment could be many-to-many, and similarly, permission assignment could be many-to-many. Other functionalities include user-role review and user-sessions. The user-role review helps determine roles assigned to a particular user and users assigned to a specific 1 role. User-sessions allow activation and deactivation of roles. Finally, users should also be able to exercise permissions of multiple roles simultaneously. Figure 1-1: Core RBAC display [16] So, it can be summarized as shown in Fig 1-1 that core RBAC includes set of five basic data elements called USERS, ROLES, objects (OBS), operations (OPS), and permissions (PRMS). The definitions can be described as shown here [18]: • UA: User Assignment ⊆ USERS × ROLES • PA: Permission Assignment ⊆ P RMS × ROLES • U-S: user sessions (u: USERS) !2SESSIONS • S-R: session roles (s: SESSIONS) !2ROLES • PRMS: 2(OP S×OBS), the set of permissions The steps followed in a typical RBAC model could be shown in Fig. 1-2. If any user wants to access a particular resource in the system, he/she would first request the application service for access into the system. The credentials used by the user to access the system would be validated by the application service. If the user's credentials are valid and the authentication service finds the user as authorized to access the system, he/she is granted the required level of access to the resources in the system, according to his/her role.