OBJECT-RELATIONAL DATABASE APPROACH FOR ROLE-BASED ACCESS CONTROL (RBAC) A Project. Presented to the faculty of the Department of Computer Science

Transcription

1 OBJECT-RELATIONAL DATABASE APPROACH FOR ROLE-BASED ACCESS CONTROL (RBAC) A Project Presented to the faculty of the Department of Computer Science California State University, Sacramento Submitted in partial satisfaction of the requirements for the degree of MASTER OF SCIENCE in Computer Science by Zhimin Cheng SPRING 2012

2 2012 Zhimin Cheng ALL RIGHTS RESERVED ii

3 OBJECT-RELATIONAL DATABASE APPROACH FOR ROLE-BASED ACCESS CONTROL (RBAC) A Project by Zhimin Cheng Approved by:, Committee Chair Ying Jin, Second Reader Jinsong Ouyang Date iii

4 Student: Zhimin Cheng I certify that this student has met the requirements for format contained in the University format manual, and that this project is suitable for shelving in the Library and credit is to be awarded for the project., Graduate Coordinator Nikrouz Faroughi Date Department of Computer Science iv

5 Abstract of OBJECT-RELATIONAL DATABASE APPROACH FOR ROLE-BASED ACCESS CONTROL (RBAC) by Zhimin Cheng Role-based Access Control (RBAC) provides access control based on permissions associated with roles and simplifies the management of permissions. Among commercial software applications, database management systems (DBMSs) provide access control at several levels of granularity and many have already applied RBAC. Object-Relational Databases (ORDB) integrate an object model with the relational model and its basic goal is to bridge the gap between relational databases and the object-oriented modeling techniques used in programming languages such as Java. In this project, a general pattern called ORDB-RBAC is designed to utilize Role-based Access Control (RBAC) in Object-Relational databases in order to develop secured software applications. This pattern is reusable for most applications, which requires access control. Access control is designed at database level instead of application level, which greatly reduces programming efforts for application developers. In this pattern, I v

6 provide how resources like users, protected objects, which are in the applications, map to RBAC standard model. Then I used a case study of software management to illustrate our approach. I implemented the case study by using Oracle database 11g express edition as the Object-relational Database Management Systems., Committee Chair Ying Jin Date vi

7 ACKNOWLEDGEMENTS I would like to thank Dr. Ying Jin for her guide on doing this project. I appreciate her time and efforts for helping me with this project. I would also thank Dr. Jinsong Ouyang to be my second reader and very helpful advice from him. vii

8 TABLE OF CONTENTS Page Acknowledgements... vii List of Tables...x List of Figures... xi Chapter 1. INTRODUCTION BACKGROUND Role-based Access Control (RBAC) Access control types RBAC Models Object-Relational Database Object-Relational features Advantages and Disadvantages of Object-Relational Database A DESIGN PATTERN FOR RBAC APPLIED TO ORDB Design pattern introduction RBAC applied to ORDB Description of the design pattern: ORDB-RBAC A CASE STUDY: SOFTWARE MANAGEMENT DATABASE DESIGN Apply the pattern to a software management application...24 viii

9 4.2 Implementation Administrator query Creating users Creating roles Object-Relational Database Design Granting privileges Results CONCLUSION...38 Appendix Source Code...40 Bibliography...56 ix

10 LIST OF TABLES Tables Page Table 1 Functional specifications of Core RBAC...9 Table 2 All information in REQUIREMENT_DOC table...36 Table 3 Information for user Ace...36 Table 4 After deleting one row...37 x

11 LIST OF FIGURES Figures Page Figure 1 Discretionary Access Control...5 Figure 2 Mandatory Access Control...6 Figure 3 Role-based Access Control...7 Figure 4 DAC, MAC and RBAC...8 Figure 5 Core RBAC...9 Figure 6 Hierarchical RBAC...10 Figure 7 One Example of Role Hierarchy...10 Figure 8 Constrained RBAC-SSD...11 Figure 9 Constrained RBAC-DSD...12 Figure 10 studenttype object with a reference type...17 Figure 11 Classic way to do access control in application...20 Figure 12 ORDB-RBAC Pattern...23 Figure 13 Role hierarchy created...26 Figure 14 All the created tables...34 Figure 15 project_plan table...34 Figure 16 test_log table...35 Figure 17 All types created...35 xi

12 Figure 18 Some users created...35 xii

13 1 Chapter 1 INTRODUCTION Starting from 1970s, computer systems have featured multiple applications and served multiple users, which lead to heightened awareness of data security issues. Because of that, people like system administrators and software developers have focused on different access control mechanisms to make sure that only authorized users have access to certain data or resources [1]. Role-based access control (RBAC) is one of the emerged mechanisms. In RBAC, there are three main parts, which include users, roles and protected objects. A group of users that have the same job functions or permissions to protected objects or resources is associated with a role. The purpose of RBAC is to protect information or other resources. Among commercial software applications, database management systems (DBMSs) provide access control at several levels of granularity. An application system developed using a DBMS can contain a large amount of data with highly differentiated access permissions for different users depending upon their functions or roles within the organization [2]. Many database management systems have already applied RBAC as it provides access control based on permissions associated with roles and simplifies the management of permissions.

14 2 Many software developers do not take advantage of database management systems RBAC when developing software applications. They design and implement RBAC at the application level that requires great efforts of programming and code management. The new distributed applications will be built more and more on modular, object-oriented architectures, which are very appropriate for managing complexity like complex objects and relationships. It is more convenient to store objects directly into database instead of disassembling them into data like string that is stored in traditional relational database. In addition, object-oriented programming languages, which focus on objects, are very popular and widely used. Object-Relational Databases (ORDB) integrate an object model with the relational model and its basic goal is to bridge the gap between relational databases and the object-oriented modeling techniques used in programming languages such as Java. Therefore, Object-Relational Database that maps business entity to object is defined and implemented to provide efficient storage for object-oriented applications. The purpose of this project is to design a general pattern to utilize Role-based Access Control in object-relational database for developing secured software applications. In this pattern, we provide how resources appear at the applications map to RBAC model. In addition, we used a case study of software management to illustrate our approach. Roles are assigned to users based on their job titles within the organization, such as project managers, test design engineers. Roles have different access rights to different tables, views or objects stored in object-relational database, such as test cases. The proposed

15 3 project aims at designing a framework to bridge the gap between application level rolebased access control and database oriented solution. The rest of the report is organized as follows. Chapter 2 introduces Role-based Access Control (RBAC) and Object-Relational Database. Chapter 3 describes our design pattern for RBAC applied to object-relational database. Chapter 4 presents a case study utilized to illustrate the design pattern introduced in Chapter 3. Chapter 5 makes conclusion of the project.

16 4 Chapter 2 BACKGROUND This chapter presents background of Role-based Access Control and its standard models as well as Object-Relational Database features. 2.1 Role-based Access Control (RBAC) Access control types Role-based Access Control (RBAC) has attracted considerable attention as an alternative to traditional Discretionary Access Control (DAC) and Mandatory Access Control (MAC). In DAC, access to resources is based solely on the identity of users who are trying to access them. A user is granted permissions to a resource by being placed on an access control list (ACL) associated with the resource. Owner of the resources can grant permissions to other users. Figure 1 shows how DAC works. As shown in Figure 1, individules like Alice, Bob access resources according to the Access Control List and just one ACL which belongs to Server 3 shows on the figure. We can see that individual access to Server 3 based on the ACL shown in the figure. Alice and Bill can access Server 3 while the other two can not.

17 5 Figure 1 Discretionary Access Control In MAC, the administrator grants permissions to access resources to users. Access to resources is based on an object's security level while users are granted security clearance. Only administrators have the ability to modify an object s security level or a user s security clearence. It provides better security than DAC. Figure 2 shows how MAC works. As shown in the figure, resources have different security level and individuals have security clearance.

18 6 Figure 2 Mandatory Access Control In RBAC, a user has access to an object based on the assigned role. A role is a group of users that have the same job functionality within an organization. Roles access resources based on policies or role rights. The object is concerned with the user s role but not the user. Users frequently change but not the roles, which makes RBAC a better access control mechanism. Figure 3 shows how it works.

19 7 Figure 3 Role-based Access Control As shown in Figure 3, Alice and John are identified as Role 1 associated permissions to access Server 2, while Bob as Role 2 having permissions to access Server 1 and Server 3. Bill can have two roles, which are Role 2 and Role 3 that have access to Server 1and Server 3. DAC, MAC and RBAC are not mutually exclusive, as shown in Figure 4. In a system, two or even three of these policies can be implemented.

20 8 Figure 4 DAC, MAC and RBAC RBAC Models As RBAC is a proven technology for large-scale authorization, the Laboratory of Information Security Technology (NIST) has developed four standard models of Rolebased Access Control [10] Core RBAC This model is the basis model for Role-based Access Control, as shown in Figure 5 Core RBAC. The other models are all developed based on this core model. In this core model, there are users, roles, permissions and sessions. One user can have many roles while one role can be assigned to many users, that is, the relationship called User Assignment (UA) between user and role is many-to-many. The Permission Assignment (PA) between roles

21 9 and permissions is also many-to-many. In the red oval shown Figure 5, operations like select, delete in database are the way of accessing resources. Moreover, one user can be in many sessions but one session can just have one user who created it. In one session, there can be many roles as one user may have many roles and one role can be in many sessions. Figure 5 Core RBAC The functional specifications of this model are shown in Table 1. Table 1 Functional specifications of Core RBAC Administrative Functions Supporting system functions Review Functions Add, Delete users Add, Delete roles Assign, Deassign users Grant, Revoke permissions Create sessions Add active roles in sessions Drop active roles Check access rights Role-user review is required. Role-permission review is optional.

22 Hierarchical RBAC This model, as shown in Figure 6 Hierarchical RBAC, adds hierarchies to roles in order that one role can inherit privileges from other roles. + Figure 6 Hierarchical RBAC One example of role hierarchy is shown in Figure 7. Figure 7 One Example of Role Hierarchy

23 11 In this role hierarchy, the bottom role test intern has the least privilege and test engineer1 can inherit his privileges. Project manager is the max role which has most privileges. In a word, the upper level inherits privileges from the lower level Constrained RBAC: Static and Dynamic separation of duties Separation of duty relations (SOD) are used to enforce conflict of interest policies. Conflict of interest in a role-based system may arise because of a user gaining authorization for permissions associated with conflicting roles. We can use static separation of duty (SSD) that is, to enforce constraints on the assignment of users to roles, to prevent this form of conflict of interest. For example, if one role requests resources and another approves them, the organization may prohibit the same user from being assigned to both roles. Because of the potential for inconsistencies with respect to static separation of duty relations and inheritance relations of a role hierarchy, SSD requirements are defined in both the presence and absence of role hierarchies. Figure 8 shows SSD in Hierarchical RBAC. Figure 8 Constrained RBAC-SSD

24 12 Dynamic separation of duty (DSD) relations, like SSD relations, limits the permissions that are available to a user. DSD requirements limit the availability of the permissions by placing constraints on the roles that can be activated within or across a user s sessions. Figure 9 shows DSD in Hierarchical RBAC. Figure 9 Constrained RBAC-DSD 2.2 Object-Relational Database Object-Relational Databases that have both Object-Oriented Database and Relational Database features become very popular with the development of Object-Oriented programming languages Object-Relational features Object-Relational model extends the relational data model by adding object-oriented concepts. It allows attributes of tuples to have complex types, including non-atomic

25 13 values such as nested relations. Moreover, it preserves relational foundations, in particular the declarative access to data, while extending modeling power and upwards compatibility with the existing relational languages Row types and arrays as collections In relational database terminology, a row is a nonempty collection of values, where the type of each value corresponds to a column definition within a table [11]. In a traditional relational table, all the rows have atomic column value, which is the first normal form (1NF). In order to allow more intuitive modeling for applications with complex data, row type is allowed in object-relational database. A row type allows a row to be stored as a column value inside of another row. Here is an example (SQL): create table student ( ID INT, name varchar(20), address row(street varchar(30), city varchar(20), country varchar(40)), primary key(id) ); In the above example, address is defined as a row type that has three fields and is represented as one column in the table. When inserting values to the table, it should be done in this way: Insert into student Values ( 21234, Alice Wang, row ( 1234 Fremont Drive, Sacramento, CA ));

26 14 The collection type provides an additional way to represent nonatomic values in a relational schema. Theoretically, a collection can be a data structure such as an array. A column in a table can be specified as an array. In the following example, courses that the student takes are represented as an array stored in database. create table student ( ID INT, name varchar(20), address row(street varchar(30), city varchar(20), country varchar(40)), courses varchar(30) array[20], primary key(id) ); When doing insert statements to the array type, it is similar to row types. array[ Physics, Data Structure, Database management ] User-Defined Types (UDT) In SQL standard terminology, user-defined type is for abstract data type. The primary advantage of a UDT is that it allows database developers to define new applicationoriented types. It also provides the basis for creating objects in the relational world. The addressudt in the following example is a typical user-defined type. create type addressudt( street varchar(30), city varchar(20), country varchar(20)) not final; Then this type can be used in the student table. create table student (

27 15 ID INT, name varchar(20), address addressudt, primary key(id) ); Compared to the built-in row type, the UDT, which might be used as a super type of a subtype, can be more flexible. The inserting values statement for UDT: insert into student values ( 21234, Alice Wang, addressudt( 1234 Fremont Drive, Sacramento, CA )); Typed table A typed table is a new form of table that is always associated with a specific structured type. It has a column for every attribute of the structured type on which it is based. We can define a student table by creating a student type first. create type studenttype as ( ID INT, name varchar(20), address addressudt); create table student of studenttype (primary key(id)); In the student table created, it has three columns with ID as primary key. We can construct queries like select, update as the common relational tables. select ID from student where name = Alice ;

28 Hierarchical type and table (Inheritance) Structured types and typed tables can be formed into hierarchies to directly represent the class hierarchies of conceptual models such as UML class diagrams. create type personudt as( ID int, lastname varchar(20), firstname varchar(20), dob date) not final; create type studentudt under personudt as (gradelevel varchar(20), department varchar(30)); create type facultyudt under personudt as (title varchar(20), salary varchar(30)); In the above example, studentudt and facultyudt are defined as subtypes of personudt with the under clause. With the person type hierarchy defined, typed tables can be created that directly correspond to type hierarchy. Person, student and faculty tables are defined as follows: Create table person of personudt (primary key(id)); Create table student of studentudt under person; Create table faculty of facultyudt under person; Reference types Object-oriented languages provide the ability to create and refer to objects. The reference types can model associations between typed tables that are based on object identify rather

29 17 than on foreign keys. Reference types therefore provide a way of modeling object relationships as in the object-oriented data model. The following example shows a studenttype has a reference type called facultytype for its coloumn advisor. create type studenttype as ( ID INT, name varchar(20), advisor REF facultytype); Figure 10 shows in studenttype there is a pointer which points to facultytype object. ID name to a facultytype object Figure 10 studenttype object with a reference type When inserting new rows to a type that has a reference type, there are two ways to do. First is to set the reference value NULL and then use UPDATE statement to update that row. Another way is to use a nested query that is to put SELECT statement into INSERT statement. select advisor fname from student where ID = ; The above SQL query is an example of querying reference types.

30 Advantages and Disadvantages of Object-Relational Database The object-relational features have been introduced in the above section. Obviously, we can see the main advantage of object-relational database is that it has massive scalability and can support for object-oriented features. The advantages of extending the relational data model come from reuse and sharing. Reuse comes from the ability to extend the DBMS server to perform standard functionality centrally, rather than have it coded in each application. The object-relational database approach has obvious disadvantage of complexity and associated increased costs. Some argue that the essential simplicity and purity of the relational model are lost with these types of extension. Some also believe that the relational database approach is being extended for what will be a minority of applications that do not achieve optimal performance with current relational technology. In addition, the architecture of object-relational model is not appropriate for high-speed web applications. However, with advantages like large storage capacity, access speed, and manipulation power of object databases, object-relational approach is set to conquer the database market.

31 19 Chapter 3 A DESIGN PATTERN FOR RBAC APPLIED TO ORDB As described in last chapter, Role-based Access Control is a powerful access control mechanism and utilized in applications and database management systems. Object- Relational Database is suitable to store objects and has both object-oriented features and relational features. In this chapter, I present a design pattern for RBAC applied to ORDB. 3.1 Design pattern introduction In software engineering, a design pattern is a general repeatable solution to a common and recurring problem in software design. Design pattern includes the following elements: Pattern Name Intent: the problem being solved by the pattern Context: the environment or situations where the pattern applies and is useful Problem: the problem that needs a solution Solution: a generic solution to a problem Consequences: the effect of the pattern as well as constraints on its use Known uses: examples that use the pattern

32 RBAC applied to ORDB When designing and developing a system, developers always use access control at the application level. Figure 11 shows the general way people use to access resources. The resources (tables, views, etc.) are stored in the database and the database management system like Oracle provides features like security. Without implementing the access control in application level, we can do this in the database level when initially designing database. Figure 11 Classic way to do access control in application Description of the design pattern: ORDB-RBAC As described above, access control can be done at database level when developing software. We designed a pattern called ORDB-RBAC. The pattern is described as follows: Pattern Name: ORDB-RBAC Intent: The pattern is used to move the access control tasks from application to database level. It provides structures about how objects in an application map to database level and how to utilize role-based access control.

33 21 Context: Any environment where resources stored in database are needed to be accessed. Problem: Many users are now working with most of their data in terms of objects within application software like CAD systems or just in the file storage system. In addition, object-oriented programming languages have been widely used when developing software. On the other hand, security issues like access to resources including business objects stored in the database are important when developing applications. Most developers or programmers now put the burden on the application itself. But it is obvious that the objects have been stored in the database and it is reasonable to let the database do the access control. Solution: Object-Relational database, which has both relational database and objectoriented database features should be a good choice for the application storing objects directly into database instead of disassemble them into data like strings, characters. In order to solve the security issue mentioned above, we have chosen Role-base Access Control (RBAC) among several kinds of access control. Figure 12 shows the design pattern. In an application, it includes three components that are personnel participants, positions and resources. These three components can map to RBAC model. The RBAC model, which has been explained in Chapter 2, is based on NIST standard [10]. However, in the ORDB-RBAC design pattern, we added relationship between users and protected objects to the RBAC model. As we can see from the figure, personnel participants are considered as users in Role-based Access Control. Positions (role) of personnel participants like manager, software engineer, doctor, nurse are mapped to roles in RBAC model. Roles in RBAC model are defined as a group of users who have the same

34 22 privileges to access resources. Roles also have hierarchy, which means that one role can inherit privileges from another role. The example is shown in Chapter 2 when introducing Hierarchical RBAC. The most important is how to map the resources. We have identified that resources include entities with attributes, relationships and business objects. Entities with attributes can be stored as relational tables in database and relationships as associations like aggregation, composition. Business objects can be stored directly into Object-relational database and some types can be defined before storing objects. Finally, the object tables, relational tables and views are generalized as protected objects. Roles can access protected objects based on role_right which can be policies or rules. Then users access resources through roles. Further, users with the same role can access different subsets of data according access_right. The Authorization qualifier can be used to distinguish different users in a role. For example, in an employee database, the role of department manager can view salaries of employees in his/her own department. However, different managers, although in the same role, can see different subset of salaries, which is distinguished by the department number. Department number is the authorization qualifier in this case. This feature can be implemented in multiple ways, such as using Oracle Virtual Private, which is a future direction to extend this project. Consequences: By using object-relational database, types and objects in the application can be stored into database. The RBAC method applied in database solves the security issue in an application.

35 23 Known uses: The pattern introduces mapping from application level to database level. Any application that has objects needed to store into database and be accessed using RBAC can take advantage of this pattern. Figure 12 ORDB-RBAC Pattern

36 24 Chapter 4 A CASE STUDY: SOFTWARE MANAGEMENT DATABASE DESIGN In this chapter, I present a case study utilizing the proposed design pattern in Chapter Apply the pattern to a software management application A software company wants to design a database for storing resources like software design documentation information. Access control should be considered. For example, a software engineer should not have the right to modify test documentations and may read them. One team member can access his team s resources but not all the company s. Rolebased access control can easily solve this problem. Employees are users. Job titles like manager are roles. Resources are information stored in database. In the ORDB-RBAC design pattern, it provides how to do the mapping. The implementation introduced in the next section is based on the pattern. Oracle 11g express edition is selected to be the database management system in the implementation. 4.2 Implementation Administrator query User sapp is the administrator. She owns the database. SQL query for her: GRANT create user, create session TO sapp WITH ADMIN OPTION;

37 25 GRANT dba to sapp; Creating users The application is developed for a company so the people in the company should be recognized as users in the model. For example, one employee called Alice can be a user. The create user statement starts with the keyword CREATE and IDENTIFIED BY follows the password for this user to login to the database. CREATE user Alice IDENTIFIED BY abc; Creating roles In this application, roles are related to employment positions. There are software engineers, software developers, project managers, etc. These roles also have hierarchies such as project manager, which has more privileges than a software engineer does and a software engineer has more privileges than an intern does. Similar to creating user statement, the creating role statement also starts with CREATE keyword. CREATE role software_engineer; In this implementation, there are two teams to simulate independent privacy such that one team can only access its own information. The role hierarchy is shown in Figure 13. CREATE ROLE software_engineer_team1; CREATE ROLE software_engineer_team2; CREATE ROLE software_developer_team1; CREATE ROLE software_developer_team2; CREATE ROLE test_design_engineer_team1;

38 26 CREATE ROLE test_design_engineer_team2; CREATE ROLE test_engineer_team1; CREATE ROLE test_engineer_team2; CREATE ROLE project_manager_team1; GRANT software_engineer_team1, software_developer_team1, test_design_engineer_team1, test_engineer_team1 to project_manager_team1; CREATE ROLE project_manager_team2; GRANT software_engineer_team2, software_developer_team2, test_design_engineer_team2, test_engineer_team2 to project_manager_team2; CREATE ROLE project_chief_manager; GRANT project_manager_team1, project_manager_team2 to project_chief_manager; Figure 13 Role hierarchy created

39 Object-Relational Database Design The most important part is the database design part. In this application, six objects have been recognized and they are requirement_doc, code, design_doc, test_case_script, test_log and project_plan. As the first three are much more independent, they are implemented as relational tables. The other three are object tables. The relationship between test_case_script and test_log is one to many (1:N) which means for each test_case_script there could be many test_log. Then the one side test_case_script is implemented as a reference type in test_log type object. In addition, user defined methods and procedures that help load blob type object into database are defined Relational tables Similar to tables defined in relational database, the attributes are defined as column of a table. For example, for an object requirement_doc, it has attributes project_id, version_no, requirement_doc_name and document. The primary key is the pair of project_id and version_no. The three relational tables are as follows, CREATE TABLE requirement_doc ( project_id VARCHAR(30), version_no INT, requirement_doc_name VARCHAR2(100), document BLOB, primary key(project_id, version_no) ); CREATE TABLE code (project_id VARCHAR(30),

40 28 module_no INT, version_no INT, code_file_name VARCHAR2(100), code_file BLOB, primary key(project_id, module_no,version_no) ); CREATE TABLE design_doc ( project_id VARCHAR(30), version_no INT, design_doc_name VARCHAR2(100), document BLOB, primary key(project_id, version_no) ); Typed tables In the implementation, test_case_type is defined first and then based on the type, test_case_script table is defined. CREATE OR REPLACE TYPE test_case_type AS OBJECT ( project_id VARCHAR(30), test_case_id INT, test_case_name VARCHAR2(100), case_details BLOB ); / CREATE TABLE test_case_script Of test_case_type( primary key(project_id, test_case_id) );

41 Type as Column and reference type In the implementation, result_detail_type is defined as an attribute of test_log_type and test_case_used attribute references to test_case_type as the relationship between test case scripts and test logs is one to many. CREATE OR REPLACE TYPE result_detail_type AS OBJECT( test_start_time DATE, test_end_time DATE, pass_fail VARCHAR(10), comments VARCHAR (50) ); / CREATE OR REPLACE TYPE test_log_type AS OBJECT( project_id VARCHAR(30), test_log_id int, test_case_used REF test_case_type, test_result result_detail_type); / Type hierarchy Project plan type is defined as a subtype of schedule type and it inherits all the attributes of the super type that is schedule type. If one type would be defined as a super type of others, the keyword NOT FINAL should be included. CREATE OR REPLACE TYPE schedule_type AS OBJECT ( start_time DATE, end_time DATE, estimated_no_hours Float, estimated_no_of_personnel Float, granttchart BLOB, member function calcost return float, ---function pragma restrict_references(default, wnds, wnps) )

42 30 instantiable not final; / CREATE OR REPLACE TYPE project_plan_type UNDER schedule_type ( project_id VARCHAR(100), project_name VARCHAR(100), version_no INT, plan_document_name VARCHAR2(100), plan_document BLOB ) instantiable not final; / CREATE TABLE project_plan of project_plan_type (primary key(project_id, version_no)); User Defined Method One method called calcost is defined in the implementation. The method is inside schedule type and is utilized to calculate the project costs. CREATE OR REPLACE TYPE schedule_type AS OBJECT (... member function calcost return float, ---function... ) instantiable not final; / Inserting values The large object blob type can not be inserted as normal ones. A procedure is defined to do the insert. Here is the PL/SQL for inserting values into requirement_doc table: --create directory

43 31 CREATE OR REPLACE directory requirementdoc as 'C:\requirementDoc'; CREATE OR REPLACE PROCEDURE Insert_file ( dir VARCHAR2, file_desc VARCHAR2, file_name VARCHAR2) IS directory VARCHAR2(30) := UPPER(dir); file_decription VARCHAR2(100) := UPPER(file_desc); file_bfile BFILE; file_blob BLOB; BEGIN file_bfile := bfilename(directory, file_name); --Insert null values to lock record INSERT INTO requirement_doc VALUES ('p1_team1','1', 'SRSV1.0_CAMPUSTOUR',EMPTY_BLOB()) --Return the BLOB column into new variable RETURNING document INTO file_blob; --Open the external LOB file DBMS_LOB.OPEN(file_bfile, DBMS_LOB.FILE_READONLY); --Load the external LOB file DBMS_LOB.LoadFromFile( DEST_LOB => file_blob, SRC_LOB => file_bfile, AMOUNT => DBMS_LOB.GETLENGTH(file_bfile) ); --Close the open file DBMS_LOB.CLOSE(file_bfile); END Insert_file; / --Execute the Procedure exec Insert_file('REQUIREMENTDOC', 'this is requirement documentation version 1.0 for campus tour', 'SRSV1.0_CAMPUSTOUR.doc')

44 32 As mentioned in Chapter 2, inserting values to a table that has reference type can be done like this: Set reference type value NULL first, then update the row. INSERT INTO test_log VALUES('p1_team1', '1', null, result_detail_type(to_date(' ','dd-mm-yyyy'), to_date(' ','dd-mm-yyyy'), 'pass', 'good result')); UPDATE test_log t SET test_case_used = (select REF(tt) from test_case_script tt where tt.project_id = 'p1_team1' and tt.test_case_id = '1') Alternatively, we can put the select statement inside insert statement: INSERT INTO test_log VALUES ('p1_team2', '1', (select REF(tt) from test_case_script tt where tt.project_id = 'p1_team2' and tt.test_case_id = '1'), result_detail_type(to_date(' ','dd-mm-yyyy'), to_date(' ','dd-mm-yyyy'), 'fail', 'error happened') ); Granting privileges The granting privileges are used to implement Role-based Access Control in Object- Relational Database. It specifies database security based on roles. One role can access some resources if the privilege is granted otherwise it can not. There are two steps of grant. First is to grant access to tables or views to roles. Second is to grant roles to users.

45 33 In order to implement each team can only access to its own resources. Some views are created, which utilizes where clause to identify which team works on which projects. CREATE or replace VIEW requirement_doc_view_team1 AS SELECT * FROM requirement_doc WHERE project_id = 'p1_team1' or project_id = 'p2_team1'; --Permissions of software_engineer_team1 --read, write project_plan, requirement_doc GRANT SELECT, INSERT, UPDATE, DELETE ON requirement_doc_view_team1 to software_engineer_team1; GRANT SELECT, INSERT, UPDATE, DELETE ON project_plan_view_team1 to software_engineer_team1; --only read permissions for code, design_doc, test_case_script, test_log GRANT SELECT ON design_doc_view_team1 to software_engineer_team1; GRANT SELECT ON code_view_team1 to software_engineer_team1; GRANT SELECT ON test_case_script_view_team1 to software_engineer_team1; GRANT SELECT ON test_log_view_team1 to software_engineer_team1; grant create procedure to software_engineer_team1; --grant roles to users grant project_manager_team1 to Alice; grant software_engineer_team1 to Ace; grant software_developer_team1 to Joe; grant software_developer_team1 to Kate; grant test_design_engineer_team1 to Susan; grant test_engineer_team1 to Carol; grant test_engineer_team1 to Lucy;

46 Results Figure 14 shows six tables that have been created. The screenshot is captured from SQL developer tool. Figure 14 All the created tables project_plan type inherits all the attributes of schedule type and Figure 15 shows the result table. Figure 15 project_plan table

47 35 Figure 16 shows the result of test_log table and we can see the data type of test_case_used is test_case_type and test_result is a result_detail_type. Figure 16 test_log table Figure 17 shows all the types that have been created and Figure 18 shows some created users. Figure 17 All types created Figure 18 Some users created Admin (sapp) can access all the information in the database. Users can access information that has been granted privileges on. Take requirement_doc table as an

48 36 example to show the access control. The results of query: select * from requirement_doc; (logged in as Admin-sapp) show in Table 2. Table 2 All information in REQUIREMENT_DOC table PROJECT_ID VERSION_NO REQUIREMENT_DOC_NAME DOCUMENT p1_team1 1 SRSV1.0_CAMPUSTOUR (BLOB) p1_team1 2 SRSV2.0_CAMPUSTOUR (BLOB) p1_team2 1 SRSV1.0_webdesign (BLOB) Ace is a software engineer in team1 and he can just access the resources of team1. After executing the query: select * from sapp.requirement_doc_view_team1, the result is: Table 3 Information for user Ace PROJECT_ID VERSION_NO REQUIREMENT_DOC_NAME DOCUMENT p1_team1 1 SRSV1.0_CAMPUSTOUR (BLOB) p1_team1 2 SRSV2.0_CAMPUSTOUR (BLOB) Ace has privilege on updating requirement_doc table. Executing the queries delete from sapp.requirement_doc_view_team1 where requirement_doc_name = 'SRSV1.0_CAMPUSTOUR'; update sapp.requirement_doc_view_team1 set requirement_doc_name = 'SRSV1.2_CAMPUSTOUR' where project_id = 'p1_team1' and version_no = '2';

49 37 select * from sapp.requirement_doc_view_team1; The result shows in Table 4. Table 4 After deleting one row PROJECT_ID VERSION_NO REQUIREMENT_DOC_NAME DOCUMENT p1_team1 2 SRSV1.2_CAMPUSTOUR (BLOB)

50 38 Chapter 5 CONCLUSION This project presented the background of Role-based Access Control (RBAC) and Object-relational Databases (ORDB) in Chapter 1 and Chapter 2. Object-Relational Databases (ORDB) integrates an object model with the relational model, which is more powerful and scalable than traditional databases because of the object data type added. Role-based Access Control (RBAC) has been widely implemented in software applications. With the knowledge of RBAC and ORDB, I developed a design pattern, which helps implement RBAC using ORDB approach. This pattern is a general approach for access control in applications, which would save much time and efforts for application developers, as they do not need to design from scratch. The Role-based Access Control has been designed at database level. This eventually reduces the programming efforts. In addition, I used a case study of software management application to illustrate the design pattern proposed. The implementation details of utilizing the ORDB-RBAC pattern and ORDB database are also included in this report. When doing the implementation of Role-based Access Control, I have created some views using where clause to enforce row-level access control. An alternative way is to use Oracle Virtual Private Database (VPD). VPD provides fine-grained access control, which enables to create security policies to control database access at row and column level. It adds a dynamic WHERE clause to a SQL statement that is issued against the

51 39 table, view, or synonym to which an Oracle Virtual Private Database security policy was applied. Role-based Access Control and Virtual Private Database could be used together to implement database access control in the case study s implementation. This would be the future work to do.

52 40 APPENDIX Source Code OR table script.sql set echo on set timing on set linesize cleanup section drop table requirement_doc; drop table code; drop table design_doc; drop table test_case_script; drop table test_log; drop type test_log_type; drop type result_detail_type; drop table project_plan; drop type project_plan_type; drop type schedule_type; drop view requirement_doc_view_team1; drop view project_plan_view_team1; drop view code_view_team1; drop view design_doc_view_team1; drop view test_case_script_view1; drop view test_log_view_team1; drop view requirement_doc_view_team2; drop view project_plan_view_team2; drop view code_view_team2; drop view design_doc_view_team2; drop view test_case_script_view1; drop view test_log_view_team2; ----Relational table CREATE TABLE requirement_doc ( project_id VARCHAR(30), version_no INT, requirement_doc_name VARCHAR2(100), document BLOB, primary key(project_id, version_no) ); CREATE TABLE code (project_id VARCHAR(30),

53 41 module_no INT, version_no INT, code_file_name VARCHAR2(100), code_file BLOB, primary key(project_id, module_no,version_no) ); CREATE TABLE design_doc ( project_id VARCHAR(30), version_no INT, design_doc_name VARCHAR2(100), document BLOB, primary key(project_id, version_no) ); Object Table Test_case type and table(typed table, UDT AS RowType) CREATE OR REPLACE TYPE test_case_type AS OBJECT ( project_id VARCHAR(30), test_case_id INT, test_case_name VARCHAR2(100), case_details BLOB ); / CREATE TABLE test_case_script Of test_case_type( primary key(project_id, test_case_id) ); -----Test_log type and table specify result_detail_type(udt AS columntype) before define test log CREATE OR REPLACE TYPE result_detail_type AS OBJECT( test_start_time DATE, test_end_time DATE, pass_fail VARCHAR(10), comments VARCHAR (50) ); / CREATE OR REPLACE TYPE test_log_type AS OBJECT( project_id VARCHAR(30), test_log_id int, test_case_used REF test_case_type, --relationship to test_case test_result result_detail_type --- use the above result_detail_type

54 42 ); / CREATE TABLE test_log of test_log_type ( primary key (project_id, test_log_id ) ); project plan type and table define schedule type firstly CREATE OR REPLACE TYPE schedule_type AS OBJECT ( start_time DATE, end_time DATE, estimated_no_hours Float, estimated_no_of_personnel Float, granttchart BLOB, member function calcost return float, ---function pragma restrict_references(default, wnds, wnps) ) instantiable not final; / project_plan_type inheritance from schedule_type CREATE OR REPLACE TYPE project_plan_type UNDER schedule_type ( project_id VARCHAR(100), project_name VARCHAR(100), version_no INT, plan_document_name VARCHAR2(100), plan_document BLOB ) instantiable not final; / CREATE TABLE project_plan of project_plan_type (primary key(project_id, version_no)); some views for RBAC create views for team1 CREATE or replace VIEW requirement_doc_view_team1 AS SELECT * FROM requirement_doc WHERE project_id = 'p1_team1' or project_id = 'p2_team1'; CREATE or replace VIEW design_doc_view_team1 AS SELECT * FROM design_doc WHERE project_id = 'p1_team1' OR project_id = 'p2_team1';

55 43 CREATE or replace VIEW code_view_team1 AS SELECT * FROM code WHERE project_id = 'p1_team1' OR project_id = 'p2_team1'; CREATE or replace VIEW test_case_script_view_team1 AS SELECT * FROM test_case_script WHERE project_id = 'p1_team1' OR project_id = 'p2_team1'; CREATE or replace VIEW test_log_view_team1 AS SELECT * FROM test_log WHERE project_id = 'p1_team1' OR project_id = 'p2_team1'; CREATE or replace VIEW project_plan_view_team1 AS SELECT * FROM project_plan WHERE project_id = 'p1_team1' OR project_id = 'p2_team1'; --create views for team2 CREATE or replace VIEW requirement_doc_view_team2 AS SELECT * FROM requirement_doc WHERE project_id = 'p1_team2'; CREATE or replace VIEW design_doc_view_team2 AS SELECT * FROM design_doc WHERE project_id = 'p1_team2'; CREATE or replace VIEW code_view_team2 AS SELECT * FROM code WHERE project_id = 'p1_team2'; CREATE or replace VIEW test_case_script_view_team2 AS SELECT * FROM test_case_script WHERE project_id = 'p1_team2'; CREATE or replace VIEW test_log_view_team2 AS SELECT * FROM test_log WHERE project_id = 'p1_team2'; CREATE or replace VIEW project_plan_view_team2 AS SELECT * FROM project_plan WHERE project_id = 'p1_team2';

56 44 user_role_privileges.sql --droping existing roles if any DROP ROLE project_chief_manager; DROP ROLE project_manager_team1; DROP ROLE software_engineer_team1; DROP ROLE software_developer_team1; DROP ROLE test_design_engineer_team1; DROP ROLE test_engineer_team1; DROP ROLE project_manager_team2; DROP ROLE software_engineer_team2; DROP ROLE software_developer_team2; DROP ROLE test_design_engineer_team2; DROP ROLE test_engineer_team2; --Creating new roles with role hierachies CREATE ROLE software_engineer_team1; CREATE ROLE software_engineer_team2; CREATE ROLE software_developer_team1; CREATE ROLE software_developer_team2; CREATE ROLE test_design_engineer_team1; CREATE ROLE test_design_engineer_team2; CREATE ROLE test_engineer_team1; CREATE ROLE test_engineer_team2; CREATE ROLE project_manager_team1; GRANT software_engineer_team1, software_developer_team1, test_design_engineer_team1, test_engineer_team1 to project_manager_team1; CREATE ROLE project_manager_team2; GRANT software_engineer_team2, software_developer_team2, test_design_engineer_team2, test_engineer_team2 to project_manager_team2; CREATE ROLE project_chief_manager; GRANT project_manager_team1, project_manager_team2 to project_chief_manager; permissions of software_engineer_team read write project_plan, requirement_doc GRANT SELECT, INSERT, UPDATE, DELETE ON requirement_doc_view_team1 to software_engineer_team1; GRANT SELECT, INSERT, UPDATE, DELETE ON project_plan_view_team1 to software_engineer_team1; --just read permissions for code, design_doc, test_case_script, test_log GRANT SELECT ON design_doc_view_team1 to software_engineer_team1; GRANT SELECT ON code_view_team1 to software_engineer_team1; GRANT SELECT ON test_case_script_view_team1 to software_engineer_team1;

57 45 GRANT SELECT ON test_log_view_team1 to software_engineer_team1; grant create procedure to software_engineer_team1; permissions of software_developer_team read write code, design_doc GRANT SELECT, INSERT, UPDATE, DELETE ON design_doc_view_team1 to software_developer_team1; GRANT SELECT, INSERT, UPDATE, DELETE ON code_view_team1 to software_developer_team1; --just read permissions for requirement_doc, test_case_script, test_log, project_plan GRANT SELECT ON requirement_doc_view_team1 to software_engineer_team1; GRANT SELECT ON project_plan_view_team1 to software_engineer_team1; GRANT SELECT ON test_case_script_view_team1 to software_engineer_team1; GRANT SELECT ON test_log_view_team1 to software_engineer_team1; grant create procedure to software_engineer_team1; permissions of test_engineer_team read write test_log GRANT SELECT, INSERT, UPDATE, DELETE ON test_log_view_team1 to test_engineer_team1; --just read permissions for requiremnt_doc, code, design_doc, test_case_script,project_plan GRANT SELECT ON design_doc_view_team1 to test_engineer_team1; GRANT SELECT ON code_view_team1 to test_engineer_team1; GRANT SELECT ON test_case_script_view_team1 to test_engineer_team1; GRANT SELECT ON requirement_doc_view_team1 to test_engineer_team1; GRANT SELECT ON project_plan_view_team1 to test_engineer_team1; grant create procedure to test_engineer_team1; permissions of test_design_engineer_team read write test_case_script GRANT SELECT, INSERT, UPDATE, DELETE ON test_case_script_view_team1 to test_design_engineer_team1; --just read permissions for code, design_doc, requirement_doc, test_log,project_plan GRANT SELECT ON design_doc_view_team1 to test_design_engineer_team1; GRANT SELECT ON code_view_team1 to test_design_engineer_team1; GRANT SELECT ON requirement_doc_view_team1 to test_design_engineer_team1; GRANT SELECT ON test_log_view_team1 to test_design_engineer_team1; GRANT SELECT ON project_plan_view_team1 to test_design_engineer_team1; grant create procedure to test_design_engineer_team1; permissions of software_engineer_team read write project_plan, requirement_doc GRANT SELECT, INSERT, UPDATE, DELETE ON requirement_doc_view_team2 to software_engineer_team2;

58 46 GRANT SELECT, INSERT, UPDATE, DELETE ON project_plan_view_team2 to software_engineer_team2; --just read permissions for code, design_doc, test_case_script, test_log GRANT SELECT ON design_doc_view_team2 to software_engineer_team2; GRANT SELECT ON code_view_team2 to software_engineer_team2; GRANT SELECT ON test_case_script_view_team2 to software_engineer_team2; GRANT SELECT ON test_log_view_team2 to software_engineer_team2; grant create procedure to software_engineer_team2; permissions of software_developer_team read write code, design_doc GRANT SELECT, INSERT, UPDATE, DELETE ON design_doc_view_team2 to software_developer_team2; GRANT SELECT, INSERT, UPDATE, DELETE ON code_view_team2 to software_developer_team2; --just read permissions for requirement_doc, test_case_script, test_log, project_plan GRANT SELECT ON requirement_doc_view_team2 to software_engineer_team2; GRANT SELECT ON project_plan_view_team2 to software_engineer_team2; GRANT SELECT ON test_case_script_view_team2 to software_engineer_team2; GRANT SELECT ON test_log_view_team2 to software_engineer_team2; grant create procedure to software_developer_team2; permissions of test_engineer_team read write test_log GRANT SELECT, INSERT, UPDATE, DELETE ON test_log_view_team2 to test_engineer_team2; --just read permissions for requiremnt_doc, code, design_doc, test_case_script,project_plan GRANT SELECT ON design_doc_view_team2 to test_engineer_team2; GRANT SELECT ON code_view_team2 to test_engineer_team2; GRANT SELECT ON test_case_script_view_team2 to test_engineer_team2; GRANT SELECT ON requirement_doc_view_team2 to test_engineer_team2; GRANT SELECT ON project_plan_view_team2 to test_engineer_team2; grant create procedure to test_engineer_team2; permissions of test_design_engineer_team read write test_case_script GRANT SELECT, INSERT, UPDATE, DELETE ON test_case_script_view_team2 to test_design_engineer_team2; --just read permissions for code, design_doc, requirement_doc, test_log,project_plan GRANT SELECT ON design_doc_view_team2 to test_design_engineer_team2; GRANT SELECT ON code_view_team2 to test_design_engineer_team2; GRANT SELECT ON requirement_doc_view_team2 to test_design_engineer_team2; GRANT SELECT ON test_log_view_team2 to test_design_engineer_team2; GRANT SELECT ON project_plan_view_team2 to test_design_engineer_team2;