INCORPORATING ATTRIBUTES INTO
ROLE-BASED ACCESS CONTROL
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
Jose Reyes
FALL
2012
© 2012
Jose Reyes
ALL RIGHTS RESERVED
ii
INCORPORATING ATTRIBUTES INTO
ROLE-BASED ACCESS CONTROL (RBAC)
A Project
by
Jose Reyes
Approved by:
__________________________________, Committee Chair
Ying Jin, Ph.D.
__________________________________, Second Reader
Jinsong Ouyang, Ph.D.
____________________________
Date
iii
Student: Jose Reyes
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, Ph.D.
Department of Computer Science
iv
________________
Date
Abstract
of
INCORPORATING ATTRIBUTES INTO
ROLE-BASED ACCESS CONTROL
by
Jose Reyes
This project explored the approach of incorporating attributes into role-based access
control (RBAC). We can define the same role to replace traditional multiple roles when
different roles are distinguished only by attribute values. By introducing attributes into
role-based access control, role definitions and application development can be much
concise and easy to manage.
The project consists of two phases: Implementation of Virtual Privacy Database (VPD) in
relational database system and addressing RBAC in XACML policies. The first phase of
the project implemented RBAC at database level, in which we used attributes to
distinguish users within the same role. We used Oracle's Virtual Private Database (VPD)
feature for the implementation in a Software Management case study. This feature
provides fine-grained access control at individual row level. Rather than opening up an
entire table to any individual user who has any privileges on the table, row-level security
restricts access to specific rows in a table. The result is that any individual user sees a
completely different set of data—only the data that person is authorized to see. The
v
second phase of the project used XACML to address high level policies that eventually
can be implemented using database RBAC.
_______________________, Committee Chair
Ying Jin, Ph D.
_______________________
Date
vi
Dedication
I would like to dedicate this project to my lovely wife that supported me in taking this
challenge and to my lovely kids, Jianna & Andres.
vii
Acknowledgments
I would like to thank Dr. Ying Jin for her guidance and support to this project.
viii
Table of Contents
Page
Dedication ................................................................................................................... vii
Acknowledgments...................................................................................................... viii
List of Tables .............................................................................................................. xii
List of Figures ............................................................................................................ xiii
Chapter
1. INTRODUCTION .....................................................................................................1
2. BACKGROUND .......................................................................................................4
2.1
eXtensible Access Control Markup Language (XACML) ..............................4
2.1.1
XACML Policy Language .......................................................................4
2.1.2
XACML data-flow model. .......................................................................5
2.1.3
RBAC policies in XACML......................................................................6
2.1.4
XACML Request Context........................................................................7
2.1.5
XACML Related Work ............................................................................8
2.2
Role-based Access Control (RBAC) ...............................................................9
2.3
Virtual Privacy Database (VPD) ...................................................................10
2.3.1 How Fine-Grained Access Control Works .................................................11
2.3.2
Application Context ...............................................................................12
2.3.3
VPD Policy Function .............................................................................13
2.3.4
VPD Policy ............................................................................................14
ix
3. RBAC-VPD XACML POLICIES AND REQUEST CONTEXT XACML ...........16
3.1
Role Based Access Control (RBAC) and Virtual Privacy Database (VPD)
XACML Policies. ....................................................................................................16
3.1.1
Role Assignment Policy (RAP) .............................................................16
3.1.2
Role PolicySet (RPS) .............................................................................18
3.1.3
Permission PolicySet (PPS) ...................................................................19
3.2
XACML Request Context .............................................................................21
4. INCORPORATING ATTRIBUTES INTO RBAC .................................................23
4.1 Oracle's Implementation of VPD in RBAC .......................................................25
4.1.1 Setup and Requirements .............................................................................25
4.2 Implementation of Case Study Z RBAC in Oracle ............................................31
4.3 Incorporation of Attributes in RBAC ................................................................32
4.4 Test Incorporation of Attributes in RBAC.........................................................37
5. SUMMARY AND FUTURE PROJECT .................................................................40
Appendix A: Role Assignment Policy for Software Project Case Study ....................42
Appendix B: Role PolicySet Case Study Z..................................................................52
Appendix C: Permission PolicySet (RBAC) for Case Study Z ...................................53
Appendix D: Permission PolicySet (RBAC & VPD) for Case Study Z ......................58
Appendix E: XML Schema "ACCESS_POLICY" ......................................................63
Appendix F: Implementation of Case Study Z RBAC in Oracle .................................66
Appendix G: VPD Policies for Case Study Z ..............................................................70
x
Bibliography ................................................................................................................72
xi
List of Tables
Tables
Page
Table 1 Case Study Z - Roles ........................................................................................... 26
Table 2 This Project - Roles.............................................................................................. 27
Table 3 Assignment of Projects ........................................................................................ 27
Table 4 Constraints ........................................................................................................... 29
Table 5 Table ACCESS_POLICY .................................................................................... 33
xii
List of Figures
Figures
Page
Figure 1 XACML Data Flow Model .................................................................................. 6
Figure 2 Hierarchical RBAC Case Study Z ...................................................................... 10
Figure 3 VPD example...................................................................................................... 15
Figure 4 Proposed Hierarchical RBAC............................................................................. 24
xiii
1
Chapter 1
INTRODUCTION
Role-Based Access Control (RBAC) has been implemented in many organizations for
managing and enforcing security. Basically, RBAC is about users being assigned roles
and roles being assigned permissions. Hence, users get the permissions by being
members of those roles.
In the Master’s Project “Object-Relational Database approach for Role Based Access
Control (RBAC)“[3], Zhimin Cheng designed a pattern to utilize RBAC in object
relational database. She used a case study of Software Management to illustrate her
approach. This Case Study was referred in this project as "Case Study Z".
In Case Study Z, users were granted or denied access to database objects using Oracle
grant predicate (roles). The traditional approach of defining views were used for the
implementation. Multiple roles have to be defined even with similar authorizations,
because of the view updatable issues.
This project solved this issue by incorporating attributes to RBAC using Oracle's Virtual
Privacy Database (VPD). VPD is the combination of fine-grained access control and
application context. Fine-grained access associates database objects with policies while
application context provides session attributes (e,g. user-id).
Hence, when a user request a query (e,g, "select * from table_a"), the application context
returns the user-id which is feed up into a policy in order to get only the projects this user
2
is involved. By doing this, the user is able to see the data that he or she is authorized to
see. Chapter 4 will use the Case Study Z as an example to cover the implementation of
VPD.
Nowadays, many organizations are expressing their business logic using high level
languages. The main advantage is the ability to work in multiple platforms, making it
easier to interoperate between applications using the same language.
The OASIS standard eXtensible Access Control Markup Language (XACML) [1] is a
security policy language that has been widely deployed in the industry by many
organizations to control access to their resources.
XACML describes an access control decision (request/response) and a policy language.
The request/response is a form of query asking if some actions can be performed or not in
the resources. The policy language defines the access control requirements to these
resources.
The OASIS XACML standard defines a data-flow model that describes the steps
involved in getting a response. There are many approaches in a variety of languages and
platforms that use this model to manage the request/response control decisions.
This project is based on the motivation of using Oracle to process the request and get the
response. In order to convey this, we need to convert the XACML request to a SQL query
and the XACML policies to database access control. Chapter 3 defines the XACML
policies that correspond to the incorporation of attributes to RBAC. The conversion of the
policies to Oracle will be done in a future project.
3
Based in the XACML RBAC Profile [2], this project defines the following policies: Role
Assignment Policy, Role PolicySet, Permission PolicySet and the XACML request.
The Role Assignment Policy defines what roles can be enabled for what users. The Role
PolicySet associates the holder of the role with the Permission PolicySet. The Permission
PolicySet contains the actual permissions associated with the given role. It has rules that
define what actions the user can perform in resources. The XACML request consists of a
list of attributes characterizing a subject as well as actions to be performed.
Chapter 3 contains all the policies and the XACML request for the Case Study Z. In the
Permission PolicySet section, it starts with the definition of policies for RBAC and later
explains the incorporation of attributes to RBAC in the policies. It has an example of an
XACML request and its equivalent statement in SQL query.
The rest of the report is organized as follows. Chapter 2 introduces Virtual Privacy
Database in RBAC and XACML language. Chapter 3 defines policies and requests in
XACML. Chapter 4 describes the implementation of VPD in a relational database
system. Chapter 5 contains the summary and future work of the project.
4
Chapter 2
BACKGROUND
This chapter presents background of the eXtensible Access Control Markup Language
(XACML), Role-based Access Control (RBAC) and Oracle's Virtual Privacy Database
(VPD).
2.1
eXtensible Access Control Markup Language (XACML)
The eXtensible Access Control Markup Language (XACML) was standardized by the
OASIS (Advancing Open Standards for the Information Society) community. XACML
defines an access control policy language in XML format. It also defines a data-flow
model describing how to evaluate authorization requests based on policies. The following
sections explain the policies, models, RBAC XACML policies, and XACML Request
Context.
2.1.1
XACML Policy Language
XACML policies have three components: target, rules and rule combining algorithms.
The target identifies the set of subjects, resources, actions and environments to which the
policy is applicable. Rules consist of an additional target (optional), an effect, a condition
5
and (optionally) a set of obligations or advice [1]. The effect specifies if the requested
actions should be allowed (permit) or not (deny). The condition specifies restrictions on
the attribute values in a request that must hold in order for the request to be granted or
denied. The obligations are functions to be executed in conjunction with the enforcement
of an authorization decision. The rule combining algorithm is the procedure for
combining decisions from multiple roles [1]. It is used to resolve conflicts among
applicable rules with different effects.
2.1.2
XACML data-flow model.
The XACML data flow model (see Figure 1) consists of an access control
request/response and four modules called Policy Points: Enforcement, Decision,
Information, and Administration.
An access requester places a request that is converted to XACML format by a context
handler. All Policy Points have their roles but all the information requested travel through
all of these points until it gets a response from the Decision Point module. This response
is translated back to its initial language and sent to the Enforcement Point to deliver the
response.
6
Figure 1 XACML Data Flow Model
2.1.3
RBAC policies in XACML
The XACML RBAC Profile [2] defines four types of policies: Role PolicySet (RPS),
Permission PolicySet (PPS), Role Assignment Policy and HasPrivilegesOfRole Policy.
The Role PolicySet is applicable only to users that have a role. This PolicySet associates
the holder of the role with the Permission PolicySet (PPS) that contains the actual
permissions associated with the given role.
7
The Permission PolicySet (PPS) contains the permissions for the given role. It must be
accessed only from the Role PolicySet. In this way, it can support hierarchical roles as
well as secure the access to permissions in the PPS. The PPS defines rules that specify
what resources the subjects can access and what actions the subjects can perform on these
resources. The Role Assignment Policy (RAP) defines what roles can be enabled to
which users. It can also specify restrictions for the combination of roles or the total
number of roles for a given user. The HasPrivilegesOfRole is a policy (optional) in a
Permission PolicySet that supports requests asking whether a subject has privileges
associated with a given role [2].
All of these policies except HasPrivilegesOfRole are implemented in the Case Study Z
(Chapter 3).
2.1.4
XACML Request Context
The XACML request consists of a list of attributes characterizing a subject as well as the
actions to be performed in resources. Chapter 3 contains an example of an XACML
request for the Case Study Z.
In the XACML model, the request is translated to XACML format by the context
handler. The XACML request context is composed of an XML header and the body.
8
The body in the request context is composed of attribute elements. These elements can
contain attributes in the categories access-subject, resources, actions, environment, etc..
(refer to OASIS XACML RBAC Profile [2] for complete list of categories).
2.1.5
XACML Related Work
XACML has been adopted widely as an industry standard and it is used by many
organizations to achieve effective authorization. There are many approaches in a variety
of languages and platforms that use the XACML model to manage access control.
One approach is by using Attribute Based Access Control (ABAC). In the article
"MyABDAC: Compiling XACML Policies for Attribute-Based Database Access
Control" [7], the authors explored the idea of use the attributes contained in the database
and compile the XACML policies into a collection of Access Control Lists (ACLs). This
enables access rights to be described at a high level but implemented and maintained at a
low level. This project is based on the motivation of using Oracle to process XACML
policies.
9
2.2
Role-based Access Control (RBAC)
In the Master’s Project “Object-Relational Database approach for Role Based Access
Control (RBAC)“[3], Zhimin Cheng designed a pattern to utilize RBAC in object
relational database for developing secured software applications. She used a case study of
software management (Case Study Z) to illustrate her approach.
In Case Study Z, roles are assigned to users based on their positions in the organizations,
such as project managers, software engineers Roles are assigned with permissions to
tables, views or objects stored in the object-relational database. Project numbers
(project_id) are the attributes that differentiate the roles.
In order to differentiate attributes between roles, she used the traditional approach of
defining views for her implementation. Hence, multiple roles have to be defined even
with similar authorizations, e,g, software_engineer_team1, software_engineer_team2,
etc.. (see Figure 2). This implementation is due to the limitation of view updatable issue.
10
Figure 2 Hierarchical RBAC Case Study Z
2.3
Virtual Privacy Database (VPD)
Virtual Privacy Database uses a filtering mechanism to filter rows that match the required
authorization of the user. This filter needs to be dynamic because in real life applications,
change of business needs to be reflected immediately in the view, and should not require
a recreation [6]. This filter is enforced in the Relational Database Management System
by the use of security policies.
The Oracle Database feature "Virtual Privacy Database" is the combination of finegrained access control and application context. Fine-grained access control associates
security policies with database objects. Application context defines database session
attributes. VPD combines both.
11
2.3.1 How Fine-Grained Access Control Works
Fine-Grained Access Control is based on dynamically modified statements. It is about
security policies and functions. The following example explains how it works.
In the Case Study Z, suppose you want to associate the REQUIREMENT_DOC table
with the following security policy: Users can see only the projects they are allowed to
work on.
This process is described as follows:
a. All the security policies need to be managed by a Secure User. In this project, the user
SECMAN is created and granted “execute privileges” in DBMS_RLS package.
Policies are logical constructors, not database objects and are defined with the
DBMS_RLS package. Any user who has the execute privilege on this package can
modify or drop a policy.
b. SECMAN creates the table "ACCESS_POLICY" that defines which project each of
the users can work on.
c. SECMAN creates a function (see 2.3.2) to add a predicate to a SQL statement run by
a user.
Note: A predicate is the WHERE clause based on one of the operators (=, !=, IS, IS
NOT, >, >=, EXIST, BETWEEN, IN, NOT IN, and so on).
In
this
Project_id
project,
=
the
(SELECT
USER_NAME=USER)
function
PROJ_ID
adds
FROM
the
following
ACCESS_POLICY
predicate:
WHERE
12
d. A user enters the following statement:
SELECT * FROM REQUIREMENT_DOC;
e. The Oracle Database server calls the function you created to implement the security
policy (see 2.3.3).
f. The function dynamically modifies the statement entered by the user to read as
follows:
SELECT * FROM REQUIREMENT_DOC WHERE
Project_id = (SELECT PROJ_ID FROM ACCESS_POLICY
WHERE USER_NAME=USER);
g. The Oracle Database server runs the dynamically modified statement.
2.3.2
Application Context
In the predicate returned by the function in previous example, the application context
comes to play by replacing the current user in the variable USER_NAME. This value is
a session-based application context and is a predefined function in Oracle which is
evaluated once for each statement execution and returns the value of the attribute user-id.
13
2.3.3
VPD Policy Function
A policy function returns a predicate to a SQL statement run by a user. Following the
Case Study Z, a policy function example is as follows:
create or replace function GET_PROJ_ID
(
p_schema in varchar2,
p_table in varchar2
)
return varchar2
as
l_retstr varchar2(2000);
begin
if (p_schema = user) then
l_retstr := null;
else
for proj_rec in
(
select PROJ_ID
from ACCESS_POLICY
where USER_NAME = USER
) loop
l_retstr := l_retstr||','||proj_rec.proj_id;
end loop;
l_retstr := ltrim(l_retstr,',');
l_retstr := 'PROJECT_ID IN ('||l_retstr||')';
end if;
return l_retstr;
end;
/
This function returns the list of projects the current user is authorized to see. We will
apply this function as a limit to the rows retrieved from a table. In other words, we will
set it up as a security policy (see 2.3.4) for the tables of the project.
14
2.3.4
VPD Policy
After you create the function, you need to create an Oracle Virtual Private Database
policy that associates the function with a table, view, or synonym. Following the Case
Study Z, a policy example is as follows:
begin
dbms_rls.add_policy (
object_schema => 'SAPP',
object_name => 'REQUIREMENT_DOC',
policy_name => 'REQ_DOC_POLICY',
function_schema => 'SECMAN',
policy_function => 'GET_PROJ_ID',
statement_types => 'SELECT,UPDATE,DELETE,INSERT',
update_check => TRUE
);
end;
/
This policy will append the output of the function "GET_PROJ_ID" to any query on
SELECT,UPDATE,DELETE,INSERT on table REQUIREMENT_DOC.
The object_schema refers to the owner of the object against which this policy is applied.
The object_name specifies the name of the object (table, view).
The procedure add_policy takes the following parameters [6]:
The function_schema refers to the name of the user who owns the function used as a
policy enforcer.
The policy_function specifies the name of the function used to enforce the policy.
The statement_types refer to the actions that can be performed in the objects. A policy
can be restricted to apply for a certain statement only.
15
The update_check is a Boolean value that may or may not allow the policy to update the
object when a new value is placed.
The advantage of VPD is that rather than opening up an entire table to any individual user
who has privileges on the table, row-level security restricts access to specific rows in a
table. The result is that any individual user sees a completely different set of data—only
the data that person is authorized to see.
Figure 3 VPD example
For instance, in Figure 3, the user only is able to access the rows that match the
project_id that was assigned to him.
16
Chapter 3
RBAC-VPD XACML POLICIES AND REQUEST CONTEXT XACML
This chapter presents XACML policies and XACML requests.
3.1
Role Based Access Control (RBAC) and Virtual Privacy Database (VPD)
XACML Policies.
This project shows all the XACML policies that can be implemented by using Oracle
VPD with incorporation of attributes to RBAC . These policies are based on the XACML
v3.0 RBAC Profile [2]: Role Assignment Policy, Role Policy Set, and Permission Policy.
3.1.1
Role Assignment Policy (RAP)
The Role Assignment Policy (RAP) defines what roles can be enabled to which users.
The Role Assignment Policy of Case Study Z contains many rule elements. Each of the
rules state which users can enable their corresponding role assigned. For instance, one of
the rules states that Ace is allowed to have the "&roles;software_engineer" role enabled,
as follows:
<!-- software_engineer role requirements rule -->
<Rule RuleId="software_engineer:role:requirements" Effect="Permit">
<Target>
<AnyOf>
<AllOf>
<Match MatchId="&function;string-equal">
<AttributeValue
17
DataType="&xml;string">Ace
</AttributeValue>
<AttributeDesignator
MustBePresent="false"
Category="&subject-category;access-subject"
AttributeId="&subject;subject-id"
DataType="&xml;string"/>
</Match>
</AllOf>
</AnyOf>
<AnyOf>
<AllOf>
<Match MatchId="&function;anyURI-equal">
<AttributeValue
DataType="&xml;anyURI">&roles;software_engineer
</AttributeValue>
<AttributeDesignator
MustBePresent="false"
Category="&category;resource"
AttributeId="&role;"
DataType="&xml;anyURI"/>
</Match>
</AllOf>
</AnyOf>
<AnyOf>
<AllOf>
<Match MatchId="&function;anyURI-equal">
<AttributeValue
DataType="&xml;anyURI">&actions;enableRole
</AttributeValue>
<AttributeDesignator
MustBePresent="false"
Category="&category;action"
AttributeId="&action;action-id"
DataType="&xml;anyURI"/>
</Match>
</AllOf>
</AnyOf>
</Target>
</Rule>
Refer to appendix A for the complete Role Assignment Policies for Case Study Z.
18
3.1.2
Role PolicySet (RPS)
The Role PolicySet associates the holder of the role with the Permission PolicySet (PPS)
that contains the actual permissions associated with the given role.
For example, in Case Study Z, the Role PolicySet for a software_engineer is as follows:
<PolicySet xmlns="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:oasis:names:tc:xacml:3.0:core:schema:
wd-17 xacml-corev3-schema-wd-17.xsd"
PolicySetId="RPS:software_engineer:role"
Version="1.0"
PolicyCombiningAlgId="&policy-combine;permit-overrides">
<Target>
<AnyOf>
<AllOf>
<Match
MatchId="&function;anyURI-equal">
<AttributeValue
DataType="&xml;anyURI">
&roles;software_engineer
</AttributeValue>
<AttributeDesignator
MustBePresent="false"
Category="&subject-category;access-subject"
AttributeId="&role;"
DataType="&xml;anyURI"/>
</Match>
</AllOf>
</AnyOf>
</Target>
<!-- Use permissions associated with the software_engineer role -->
<PolicySetIdReference>
PPS:software_engineer:role
</PolicySetIdReference>
</PolicySet>
The appendix B contains all the Role PolicySets for Case Study Z.
19
3.1.3
Permission PolicySet (PPS)
The Permission PolicySet (PPS) contains the permissions for the given role. The PPS
defines rules that specify what resources the subjects can access and what actions the
subjects can perform on these resources.
For example, in Case Study Z, a Permission PolicySet for the software engineer contains
a set of rules that correspond to permissions for each of the tables of the project. Hence,
the Rule that has the permissions to read the table requirement_doc has the resource-id
(table) with value requirement_doc and the action-id (select), as follows:
<!-- Permission to read and write table requirement_doc -->
<Rule
RuleId="Permission:to:read and write:table:requirement_doc"
Effect="Permit">
<Description>
A software engineer may read or write on table requirement_doc
</Description>
<Target>
<Resource>
<ResourceMatch MatchId="&function;string-equal">
<Attribute
AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id"
DataType="&xml;string">
<AttributeValue>
requirement_doc
</AttributeValue>
</Attribute>
</ResourceMatch>
</Resource>
<Action>
<Attribute
AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id"
DataType="&xml;string">
<AttributeValue>
SELECT, INSERT, DELETE,UPDATE
</AttributeValue>
</Attribute>
20
</Action>
</Target>
</Rule>
The incorporation of attributes to RBAC can be expressed in the policy rules using the
"obligations" element. Obligations are a set of instructions that are executed along with
the authorization decision.
For example, in the Permission Policy Set for the software engineer, the obligations
element returns the project numbers (project_id) that the user is entitled to work
combined with the permissions granted as a software engineer.
In the Obligations element, the ObligationId is the project_id that is pulled from the
resource (XML schema, Appendix E) that contains the list of projects that correspond to
each of the users. This XML schema corresponds to the Access_Policy table in the
incorporation of attributes to RBAC (chapter 4).
<ObligationExpressions>
<ObligationExpression
ObligationId="urn:oasis:names:tc:xacml:example:obligation:project_id"
FulfillOn="Permit">
<AttributeAssignmentExpression
AttributeId="urn:oasis:names:tc:xacml:3.0:example:attribute:project_id">
<AttributeSelector
MustBePresent="true"
Category="urn:oasis:names:tc:xacml:3.0:attribute-category:resource"
Path="access_policy:access_policy/user/projects/project_id"
DataType="http://www.w3.org/2001/XMLSchema#string"/>
</AttributeAssignmentExpression>
<AttributeAssignmentExpression
AttributeId="urn:oasis:names:tc:xacml:3.0:example:attribute:text">
<AttributeDesignator
MustBePresent="false"
Category="urn:oasis:names:tc:xacml:1.0:subject-category:access-subject"
AttributeId="urn:oasis:names:tc:xacml:1.0:subject:subject-id"
21
DataType="http://www.w3.org/2001/XMLSchema#string"/>
</AttributeAssignmentExpression>
</ObligationExpression>
</ObligationExpressions>
The appendixes C (only RBAC) and D(RBAC & VPD) contains all the Policy
Permission Sets for the Case Study Z.
3.2
XACML Request Context
The XACML request consists of a list of attributes characterizing a subject as well as the
actions to be performed in resources. Following the Case Study Z, we can have the
following request:
In English: User ACE, a software engineer wants to read the content of table
requirement_doc.
In SQL: (logged in as user ACE)
Select * from requirement_doc
In this example, the XACML request has the following categories:
category: access-subject; attributes: subject-id(user) and role
category: resource; attribute: resource-id (table)
category: action; attribute: action-id (select)
The Request Context in XACML is as follows:
<?xml version="1.0" encoding="UTF-8"?>
<Request xmlns="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
22
xsi:schemaLocation="urn:oasis:names:tc:xacml:3.0:core:schema:wdhttp://docs.oasis-open.org/xacml/3.0/xacml-core-v3-schema-wd-17.xsd"
ReturnPolicyIdList="false">
<Attributes
Category="urn:oasis:names:tc:xacml:1.0:subject-category:accesssubject">
<Attribute IncludeInResult="false"
AttributeId="urn:oasis:names:tc:xacml:1.0:subject:subject-id">
<AttributeValue
DataType="http://www.w3.org/2001/XMLSchema#string">
ACE
</AttributeValue>
</Attribute>
<Attribute IncludeInResult="false"
AttributeId="urn:oasis:names:tc:xacml:3.0:example:attribute:role">
<AttributeValue
DataType="http://www.w3.org/2001/XMLSchema#string">
software_engineer
</AttributeValue>
</Attribute>
</Attributes>
<Attributes>
Category="urn:oasis:names:tc:xacml:3.0:attribute-category:resource">
<Attribute IncludeInResult="false"
AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id">
<AttributeValue
DataType="http://www.w3.org/2001/XMLSchema#anyURI">
table:requirement_doc
</AttributeValue>
</Attribute>
</Attributes>
<Attributes>
Category="urn:oasis:names:tc:xacml:3.0:attribute-category:action">
<Attribute IncludeInResult="false"
AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id">
<AttributeValue
DataType="http://www.w3.org/2001/XMLSchema#anyURI">
SELECT
</AttributeValue>
</Attribute>
</Attributes>
</Request>
23
Chapter 4
INCORPORATING ATTRIBUTES INTO RBAC
As mentioned in Chapter 2, the traditional approach of defining views to differentiate
attributes between roles in RBAC incurs updatable issues. These issues are resolved by
incorporating attributes using Oracle' Virtual Privacy Database (VPD).
VPD uses a filter mechanism to filter rows that match the required authorization of the
user. This filter is enforced in the Relational Database Management System by the use of
security policies.
This project implements VPD usingCase Study Z. VPD provides fine-grained access
control at the individual row level. Rather than opening up an entire table to any
individual user who has privileges on the table, row-level security restricts access to
specific rows in a table. The result is that any individual user will see a completely
different set of data, only the data that person is authorized to see.
The main advantage of this implementation is the ability to distinguish between different
roles by using attributes. For instance, in the Software Management case study, the roles
“Software Engineer team 1” and “Software Engineer team2” have the same rights on
particular objects, e,g, write on requirements table. The difference between these roles is
that they are assigned to different projects. In VPD, the project number (attribute) is used
to provide row-level access control. Hence, only one role “Software Engineer” is needed
24
(see figure 4). The role level security provides access to specific rows in the tables based
on the attribute project number.
Figure 4 Proposed Hierarchical RBAC
25
4.1 Oracle's Implementation of VPD in RBAC
4.1.1 Setup and Requirements
Tables:
The following tables are used in the project (from Case Study Z):
REQUIREMENT_DOC, CODE, DESIGN_DOC, TEST_CASE_SCRIPT, TEST_LOG,
and PROJECT_PLAN
Users:
The following users are used in the project (from Case Study Z):
SAPP (administrator, owner of tables), Alice, Bob, Kate, Susan, Carol, Joe, Ace, Bill,
Lucy, Lily, James, Nancy, Jane, Sue, Jack.
Roles:
As mentioned before, in Case Study Z, several roles were created in order to differentiate
the attribute project number. For instance, Case Study Z
has the roles
software_engineer_team1, software_engineer_team2. In this project, we only need one
role, Software Engineer.
26
This project has the following roles:
-
project chief manager
-
project manager
-
software engineer
-
software developer
-
test design engineer
-
test engineer
Assignment of roles(from Case Study Z):
In Case Study Z, the traditional approach of defining views is used for the
implementation. Multiple roles have to be defined even with similar authorizations,
because of the view updatable issues.
Table 1 Case Study Z - Roles
Roles
Team 1
Team 2
Bill
Bill
Project Manager
Alice
Bob
Software Engineer
Ace
Lily, James
Software Developer
Joe, Kate
Jane
Susan
Sue, Nancy
Carol, Lucy
Jack
Project Chief Manager
Test Design Engineer
Test Engineer
27
In this project, users are assigned to a single role as follows:
Table 2 This Project - Roles
Roles
Project Chief Manager
Bill
Project Manager
Alice, Bob
Software Engineer
Ace, Lily, James
Software Developer
Joe, Kate, Jane
Test Design Engineer
Susan, Sue, Nancy
Test Engineer
Carol, Lucy, Jack
Projects:
The attribute “project number” is used in this project to distinguish between roles.
Project Numbers used in this project:
101,102,103,104,105,106
Table 3 Assignment of Projects
Role/User
Projects
project_chief_manager
Bill
101,102,103,104
project_manager
Alice
101,102
Bob
103,104
28
Role/User
Projects
software_engineer
Ace
101,102
Lily
103
James
104
software_developer
Joe
101
Kate
102
Jane
103,104
test_design_engineer
Susan
101,102
Sue
103
Nancy
104
test_engineer
Carol
101
Lucy
102
Jack
103,104
29
Constraints:
Table 4 Constraints
Table
Software
Engineer
Software
Developer
Test
Engineer
Test
Design
Engineer
Project
Manager
Project
Chief
Manager
REQUIREMENT_DOC
S,I,D,U
S
S
S
S,I,D,U
S,I,D,U
CODE
S
S,I,D,U
S
S
S,I,D,U
S,I,D,U
DESIGN_DOC
S
S,I,D,U
S
S
S,I,D,U
S,I,D,U
TEST_CASE_SCRIPT
S
S
S
S,I,D,U
S,I,D,U
S,I,D,U
TEST_LOG
S
S
S,I,D,U
S
S,I,D,U
S,I,D,U
S,I,D,U
S
S
S
S,I,D,U
S,I,D,U
PROJECT_PLAN
According to tables 3 and 4:
-
Software engineers have read and write rights (S,I,D,U) for the tables
REQUIREMENT_DOC and PROJECT_PLAN, for the following projects:
Ace for projects 101,102. Lily for project 103, James for project 104.
-
Software engineers only have read (S) access to tables CODE, DESIGN_DOC,
TEST_CASE_SCRIPT and TEST_LOG for the following projects:
Ace for projects 101,102. Lily for project 103, James for project 104.
-
Software developers have read and write rights (S,I,D,U) for the tables CODE and
DESIGN_DOC, for the following projects:
Joe for project 101, Kate for project 102, Jane for projects 103,104.
30
-
Software developers only have read (S) access to tables REQUIREMENT_DOC,
TEST_CASE_SCRIPT, TEST_LOG and PROJECT_PLAN for the following projects:
Joe for project 101, Kate for project 102, Jane for projects 103,104.
-
Test Engineers have read and write rights (S,I,D,U) only for the table
TEST_LOG, for the following projects:
Carol for project 101, Lucy for project 102, Jack only for projects 103,104.
-
Test Engineers only have read (S) access to tables REQUIREMENT_DOC,
CODE, DESIGN_DOC, TEST_CASE_SCRIPT and PROJECT_PLAN for the following
projects:
Carol for project 101, Lucy for project 102, Jack for projects 103,104.
-
Test Design Engineers have read and write rights (S,I,D,U) only for the table
TEST_CASE_SCRIPT, for the following projects:
Susan for projects 101,102. Sue for project 103, Nancy for project 104.
-
Test
Design
Engineers
only
have
read
(S)
access
to
tables
REQUIREMENT_DOC, CODE, DESIGN_DOC, TEST_LOG and PROJECT_PLAN for
the following projects:
Susan for projects 101,102. Sue for project 103, Nancy for project 104.
-
Project Managers have read and write rights (S,I,D,U) for all tables, for the
following projects:
Alice for projects 101,102. Bob for projects 103,104.
31
-
Project Chief Manager, Bill, has read and write rights (S,I,D,U) for all tables, all
projects.
4.2 Implementation of Case Study Z RBAC in Oracle
Please refer to Appendix F for the creation of users, tables, populate tables, roles,
assignment of roles for Case Study Z.
In the example below, user Ace runs a query on table REQUIREMENT_DOC. This
query satisfies the role assigned to user Ace (Software Engineer). He can read/write the
table REQUIREMENT_DOC. The query returns all the projects. It should return ONLY
the projects 101,102 that were assigned to Ace. We will discuss how to solve the
problem in the next subsection.
Connect as user Ace and run query:
Select project_id, requirement_doc_name from SAPP.REQUIREMENT_DOC;
32
4.3 Incorporation of Attributes in RBAC
The incorporation of attributes in RBAC is done by the implementation of Oracle's
Virtual Privacy Database (VPD) feature. In this project, this implementation is done by
the following steps:
1. Creation of the user SECMAN (security manager). It is very important to create this
user for security purposes. This user is the only one with rights to modify access table
and policies.
CREATE USER SECMAN IDENTIFIED BY password;
GRANT CREATE SESSION TO SECMAN WITH ADMIN OPTION;
GRANT dba TO SECMAN;
33
2. As user SECMAN: Create the table ACCESS_POLICY that identifies the projects
that are associated with the users.
CREATE TABLE ACCESS_POLICY (
USER_NAME VARCHAR2(20),
PROJ_ID NUMBER
);
3. Populate table ACCESS_POLICY based on table 5.
Table 5 Table ACCESS_POLICY
USER_NAME
PROJECT_ID
BILL
101
BILL
102
BILL
103
BILL
104
ALICE
101
ALICE
102
BOB
103
BOB
104
ACE
101
ACE
102
LILY
103
JAMES
104
JOE
101
KATE
102
JANE
103
34
USER_NAME
PROJECT_ID
JANE
104
SUSAN
101
SUSAN
102
SUE
103
NANCY
104
CAROL
101
LUCY
102
JACK
103
JACK
104
4. As user SECMAN: Create a Policy Function. This function returns the projects the
user is involved based on the ACCESS_POLICY table.
create or replace function GET_PROJ_ID
(
p_schema in varchar2,
p_table in varchar2
)
return varchar2
as
l_retstr varchar2(2000);
begin
if (p_schema = user) then
l_retstr := null;
else
for proj_rec in
(
select PROJ_ID
from ACCESS_POLICY
where USER_NAME = USER
) loop
l_retstr := l_retstr||','||proj_rec.proj_id;
end loop;
35
l_retstr := ltrim(l_retstr,',');
l_retstr := 'PROJECT_ID IN ('||l_retstr||')';
end if;
return l_retstr;
end;
/
After building this function, we want to make sure it returns the appropriate predicate
by testing some sample data as follows:
Connect to the database as SECMAN, and insert some records into the
ACCESS_POLICY table, giving SECMAN some projects as follows:
connect SECMAN
password: password
insert into ACCESS_POLICY values ('SECMAN',105);
insert into ACCESS_POLICY values ('SECMAN',106);
Now execute the function:
select GET_PROJ_ID
('SAPP','REQUIREMENT_DOC') from dual;
36
The function returns a string that will be applied as a predicate, as shown in the
following sample output:
5. Grant
execute
privileges
to
user
SECMAN
in
DBMS_RLS.
Policies are logical constructors, not database objects. Policies are defined using
DBMS_RLS package. Any user who has the execute privilege on this package can
modify or drop a policy.
In this implementation, the user SECMAN is granted execute privileges (by SYS
user) on the DBMS_RLS package, as follows:
connect sys as sysdba
password: password
grant execute on dbms_rls to SECMAN;
6. Create policy for each of the tables of the project. This policy applies the predicate
returned by the function GET_PROJ_ID owned by schema SECMAN to all
statements on the table.
37
Whenever any of the tables under SAPP schema is referenced in a query, the server
calls the GET_PROJ_ID function (under the SECMAN schema). This function
returns
a
predicate
specific
to
the
current
user
of
the
policies.
The server then produces a transient view with the text:
SELECT * FROM SAPP.REQUIREMENT_DOC WHERE P1
Here, P1 is the predicate returned from the GET_PROJ_ID function.
The policy for the table REQUIREMENT_DOC is as follows:
begin
dbms_rls.add_policy (
object_schema => 'SAPP',
object_name => 'REQUIREMENT_DOC',
policy_name => 'REQ_DOC_POLICY',
function_schema => 'SECMAN',
policy_function => 'GET_PROJ_ID',
statement_types => 'SELECT,UPDATE,DELETE,INSERT',
update_check => TRUE
);
end;
/
Refer to Appendix F for all the rest of policies corresponding to all tables in project.
4.4 Test Incorporation of Attributes in RBAC
Based on the constraints detailed in table 4, the table REQUIREMENT_DOC has the
following requirements:
38
Software Engineers, Project Managers and Project Chief Managers have read and write
rights on this table. Software Developer, Test Engineer and Test Design Engineers have
only read rights on this table.
Software Engineers: User ACE has rights only in projects 101 and 102. User Lily has
rights only in project 103. User James has rights only in 104.
Project Managers: User ALICE has rights only in projects 101 and 102. BOB has rights
only in projects 103,104.
Project Chief Manager: BILL has rights in all of the projects 101,102,103,104.
The following examples show the incorporation of attributes in the table
REQUIREMENT_DOC for the user ACE and LILY.
Example 1: Connect user ACE and run query:
SELECT project_id, requirement_doc_name from SAPP.REQUIREMENT_DOC;
Example 2: Connect user LILY and run query:
39
SELECT project_id, requirement_doc_name from SAPP.REQUIREMENT_DOC;
As a result of this queries, only the projects assigned to user ACE and LILY are returned,
solving the issue shown in the previous chapter when only RBAC was implemented.
40
Chapter 5
SUMMARY AND FUTURE PROJECT
This project presented the incorporation of attributes to Role-based Access Control and
introduced an approach to address high level policies in XACML that eventually will be
implemented by using database level access control.
In the Master's Project "“Object-Relational Database approach for Role Based Access
Control (RBAC)“[3], Zhimin Cheng used the traditional approach of defining views to
differentiate attributes between roles. This approach incurred view updatable issues. The
issue was resolved by the incorporation of attributes by the Oracle's feature of Virtual
Privacy Database (VPD).
By incorporating attributes to RBAC, multiple roles with same authorization are
simplified to only one role. VPD differentiates attributes between roles by applying
security policies and functions that are defined in the DBMS_RLS package.
The implementation of Oracle Virtual Private Database security policies to Role-based
Access Control provides the benefits of Security, Simplicity and Flexibility.
Nowadays, many organizations are expressing their business logic using high level policy
languages. The OASIS standard eXtensible Access Control Markup Language (XACML)
[1] is a security policy language that has been widely deployed in industry by many
organizations to control access to their resources.
41
In this project, we presented how to follow XACML standard to describe polices and
requests. Future work is to bridge the policies with database access control. Specifically,
we can use database RBAC to implement XACML policies and respond XACML
requests.
42
Appendix A
Role Assignment Policy for Software Project Case Study
<Policy xmlns="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17 xacmlcore-v3-schema-wd-17.xsd"
PolicyId="Role:Assignment:Policy"
Version="1.0"
RuleCombiningAlgId="&rule-combine;permit-overrides">
<Target/>
<!-- project_chief_manager role requirements rule -->
<Rule RuleId="project_chief_manager:role:requirements" Effect="Permit">
<Target>
<AnyOf>
<AllOf>
<Match MatchId="&function;string-equal">
<AttributeValue
DataType="&xml;string">Bill
</AttributeValue>
<AttributeDesignator
MustBePresent="false"
Category="&subject-category;access-subject"
AttributeId="&subject;subject-id"
DataType="&xml;string"/>
</Match>
</AllOf>
</AnyOf>
<AnyOf>
<AllOf>
<Match MatchId="&function;anyURI-equal">
<AttributeValue
DataType="&xml;anyURI">&roles;project_chief_manager
</AttributeValue>
<AttributeDesignator
MustBePresent="false"
Category="&category;resource"
AttributeId="&role;"
DataType="&xml;anyURI"/>
</Match>
</AllOf>
</AnyOf>
43
<AnyOf>
<AllOf>
<Match MatchId="&function;anyURI-equal">
<AttributeValue
DataType="&xml;anyURI">&actions;enableRole
</AttributeValue>
<AttributeDesignator
MustBePresent="false"
Category="&category;action"
AttributeId="&action;action-id"
DataType="&xml;anyURI"/>
</Match>
</AllOf>
</AnyOf>
</Target>
</Rule>
<!-- project_manager role requirements rule -->
<Rule RuleId="project_manager:role:requirements" Effect="Permit">
<Target>
<AnyOf>
<AllOf>
<Match MatchId="&function;string-equal">
<AttributeValue
DataType="&xml;string">Alice
</AttributeValue>
<AttributeDesignator
MustBePresent="false"
Category="&subject-category;access-subject"
AttributeId="&subject;subject-id"
DataType="&xml;string"/>
</Match>
</AllOf>
<AllOf>
<Match MatchId="&function;string-equal">
<AttributeValue
DataType="&xml;string">Bob
</AttributeValue>
<AttributeDesignator
MustBePresent="false"
Category="&subject-category;access-subject"
AttributeId="&subject;subject-id"
DataType="&xml;string"/>
</Match>
</AllOf>
44
</AnyOf>
<AnyOf>
<AllOf>
<Match MatchId="&function;anyURI-equal">
<AttributeValue
DataType="&xml;anyURI">&roles;project_manager
</AttributeValue>
<AttributeDesignator
MustBePresent="false"
Category="&category;resource"
AttributeId="&role;"
DataType="&xml;anyURI"/>
</Match>
</AllOf>
</AnyOf>
<AnyOf>
<AllOf>
<Match MatchId="&function;anyURI-equal">
<AttributeValue
DataType="&xml;anyURI">&actions;enableRole
</AttributeValue>
<AttributeDesignator
MustBePresent="false"
Category="&category;action"
AttributeId="&action;action-id"
DataType="&xml;anyURI"/>
</Match>
</AllOf>
</AnyOf>
</Target>
</Rule>
<!-- software_engineer role requirements rule -->
<Rule RuleId="software_engineer:role:requirements" Effect="Permit">
<Target>
<AnyOf>
<AllOf>
<Match MatchId="&function;string-equal">
<AttributeValue
DataType="&xml;string">Ace
</AttributeValue>
<AttributeDesignator
MustBePresent="false"
Category="&subject-category;access-subject"
AttributeId="&subject;subject-id"
45
DataType="&xml;string"/>
</Match>
</AllOf>
<AllOf>
<Match MatchId="&function;string-equal">
<AttributeValue
DataType="&xml;string">Lily
</AttributeValue>
<AttributeDesignator
MustBePresent="false"
Category="&subject-category;access-subject"
AttributeId="&subject;subject-id"
DataType="&xml;string"/>
</Match>
</AllOf>
<AllOf>
<Match MatchId="&function;string-equal">
<AttributeValue
DataType="&xml;string">James
</AttributeValue>
<AttributeDesignator
MustBePresent="false"
Category="&subject-category;access-subject"
AttributeId="&subject;subject-id"
DataType="&xml;string"/>
</Match>
</AllOf>
</AnyOf>
<AnyOf>
<AllOf>
<Match MatchId="&function;anyURI-equal">
<AttributeValue
DataType="&xml;anyURI">&roles;software_engineer
</AttributeValue>
<AttributeDesignator
MustBePresent="false"
Category="&category;resource"
AttributeId="&role;"
DataType="&xml;anyURI"/>
</Match>
</AllOf>
</AnyOf>
<AnyOf>
<AllOf>
<Match MatchId="&function;anyURI-equal">
46
<AttributeValue
DataType="&xml;anyURI">&actions;enableRole
</AttributeValue>
<AttributeDesignator
MustBePresent="false"
Category="&category;action"
AttributeId="&action;action-id"
DataType="&xml;anyURI"/>
</Match>
</AllOf>
</AnyOf>
</Target>
</Rule>
<!-- software_developer role requirements rule -->
<Rule RuleId="software_developer:role:requirements" Effect="Permit">
<Target>
<AnyOf>
<AllOf>
<Match MatchId="&function;string-equal">
<AttributeValue
DataType="&xml;string">Joe
</AttributeValue>
<AttributeDesignator
MustBePresent="false"
Category="&subject-category;access-subject"
AttributeId="&subject;subject-id"
DataType="&xml;string"/>
</Match>
</AllOf>
<AllOf>
<Match MatchId="&function;string-equal">
<AttributeValue
DataType="&xml;string">Kate
</AttributeValue>
<AttributeDesignator
MustBePresent="false"
Category="&subject-category;access-subject"
AttributeId="&subject;subject-id"
DataType="&xml;string"/>
</Match>
</AllOf>
<AllOf>
<Match MatchId="&function;string-equal">
<AttributeValue
47
DataType="&xml;string">Jane
</AttributeValue>
<AttributeDesignator
MustBePresent="false"
Category="&subject-category;access-subject"
AttributeId="&subject;subject-id"
DataType="&xml;string"/>
</Match>
</AllOf>
</AnyOf>
<AnyOf>
<AllOf>
<Match MatchId="&function;anyURI-equal">
<AttributeValue
DataType="&xml;anyURI">&roles;software_developer
</AttributeValue>
<AttributeDesignator
MustBePresent="false"
Category="&category;resource"
AttributeId="&role;"
DataType="&xml;anyURI"/>
</Match>
</AllOf>
</AnyOf>
<AnyOf>
<AllOf>
<Match MatchId="&function;anyURI-equal">
<AttributeValue
DataType="&xml;anyURI">&actions;enableRole
</AttributeValue>
<AttributeDesignator
MustBePresent="false"
Category="&category;action"
AttributeId="&action;action-id"
DataType="&xml;anyURI"/>
</Match>
</AllOf>
</AnyOf>
</Target>
</Rule>
<!-- test_design_engineer role requirements rule -->
<Rule RuleId="test_design_engineer:role:requirements" Effect="Permit">
<Target>
<AnyOf>
48
<AllOf>
<Match MatchId="&function;string-equal">
<AttributeValue
DataType="&xml;string">Susan
</AttributeValue>
<AttributeDesignator
MustBePresent="false"
Category="&subject-category;access-subject"
AttributeId="&subject;subject-id"
DataType="&xml;string"/>
</Match>
</AllOf>
<AllOf>
<Match MatchId="&function;string-equal">
<AttributeValue
DataType="&xml;string">Sue
</AttributeValue>
<AttributeDesignator
MustBePresent="false"
Category="&subject-category;access-subject"
AttributeId="&subject;subject-id"
DataType="&xml;string"/>
</Match>
</AllOf>
<AllOf>
<Match MatchId="&function;string-equal">
<AttributeValue
DataType="&xml;string">Nancy
</AttributeValue>
<AttributeDesignator
MustBePresent="false"
Category="&subject-category;access-subject"
AttributeId="&subject;subject-id"
DataType="&xml;string"/>
</Match>
</AllOf>
</AnyOf>
<AnyOf>
<AllOf>
<Match MatchId="&function;anyURI-equal">
<AttributeValue
DataType="&xml;anyURI">&roles;test_design_engineer
</AttributeValue>
<AttributeDesignator
MustBePresent="false"
49
Category="&category;resource"
AttributeId="&role;"
DataType="&xml;anyURI"/>
</Match>
</AllOf>
</AnyOf>
<AnyOf>
<AllOf>
<Match MatchId="&function;anyURI-equal">
<AttributeValue
DataType="&xml;anyURI">&actions;enableRole
</AttributeValue>
<AttributeDesignator
MustBePresent="false"
Category="&category;action"
AttributeId="&action;action-id"
DataType="&xml;anyURI"/>
</Match>
</AllOf>
</AnyOf>
</Target>
</Rule>
<!-- test_engineer role requirements rule -->
<Rule RuleId="test_engineer:role:requirements" Effect="Permit">
<Target>
<AnyOf>
<AllOf>
<Match MatchId="&function;string-equal">
<AttributeValue
DataType="&xml;string">Carol
</AttributeValue>
<AttributeDesignator
MustBePresent="false"
Category="&subject-category;access-subject"
AttributeId="&subject;subject-id"
DataType="&xml;string"/>
</Match>
</AllOf>
<AllOf>
<Match MatchId="&function;string-equal">
<AttributeValue
DataType="&xml;string">Lucy
</AttributeValue>
<AttributeDesignator
50
MustBePresent="false"
Category="&subject-category;access-subject"
AttributeId="&subject;subject-id"
DataType="&xml;string"/>
</Match>
</AllOf>
<AllOf>
<Match MatchId="&function;string-equal">
<AttributeValue
DataType="&xml;string">Jack
</AttributeValue>
<AttributeDesignator
MustBePresent="false"
Category="&subject-category;access-subject"
AttributeId="&subject;subject-id"
DataType="&xml;string"/>
</Match>
</AllOf>
</AnyOf>
<AnyOf>
<AllOf>
<Match MatchId="&function;anyURI-equal">
<AttributeValue
DataType="&xml;anyURI">&roles;test_engineer
</AttributeValue>
<AttributeDesignator
MustBePresent="false"
Category="&category;resource"
AttributeId="&role;"
DataType="&xml;anyURI"/>
</Match>
</AllOf>
</AnyOf>
<AnyOf>
<AllOf>
<Match MatchId="&function;anyURI-equal">
<AttributeValue
DataType="&xml;anyURI">&actions;enableRole
</AttributeValue>
<AttributeDesignator
MustBePresent="false"
Category="&category;action"
AttributeId="&action;action-id"
DataType="&xml;anyURI"/>
</Match>
51
</AllOf>
</AnyOf>
</Target>
</Rule>
</Policy>
52
Appendix B
Role PolicySet Case Study Z
Role <PolicySet> for the software_engineer role
<PolicySet xmlns="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17 xacml-corev3-schema-wd-17.xsd"
PolicySetId="RPS:software_engineer:role"
Version="1.0"
PolicyCombiningAlgId="&policy-combine;permit-overrides">
<Target>
<AnyOf>
<AllOf>
<Match
MatchId="&function;anyURI-equal">
<AttributeValue
DataType="&xml;anyURI">
&roles;software_engineer
</AttributeValue>
<AttributeDesignator
MustBePresent="false"
Category="&subject-category;access-subject"
AttributeId="&role;"
DataType="&xml;anyURI"/>
</Match>
</AllOf>
</AnyOf>
</Target>
<!-- Use permissions associated with the software_engineer role -->
<PolicySetIdReference>
PPS:software_engineer:role
</PolicySetIdReference>
</PolicySet>
53
Appendix C
Permission PolicySet (RBAC) for Case Study Z
Permission PolicySet for software_engineer role (RBAC)
<PolicySet xmlns="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17 xacml-217 core-v3
schema-wd-17.xsd"
xmlns:access_policy="company:domain/schemas/access_policy.xsd"
PolicySetId="PPS:software_engineer:role"
Version="1.0"
PolicyCombiningAlgId="&policy-combine;permit-overrides">
<Target/>
<Policy PolicyId="Permissions:specifically:for:the:software_engineer:role"
Version="1.0"
RuleCombiningAlgId="&rule-combine;permit-overrides">
<Target/>
<!-- Permission to read and write table requirement_doc -->
<Rule
RuleId="Permission:to:read and write:table:requirement_doc"
Effect="Permit">
<Description>
A software engineer may read or write on table requirement_doc
only in projects assigned to him
</Description>
<Target>
<Resource>
<ResourceMatch MatchId="&function;string-equal">
<Attribute
AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id"
DataType="&xml;string">
<AttributeValue>
requirement_doc
</AttributeValue>
</Attribute>
</ResourceMatch>
</Resource>
<Action>
<Attribute
54
AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id"
DataType="&xml;string">
<AttributeValue>
SELECT, INSERT, DELETE,UPDATE
</AttributeValue>
</Attribute>
</Action>
</Target>
</Rule>
<!-- Permission to read table code-->
<Rule
RuleId="Permission:to:read:table:code"
Effect="Permit">
<Target>
<Resource>
<ResourceMatch MatchId="&function;string-equal">
<Attribute
AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id"
DataType="&xml;string">
<AttributeValue>
code
</AttributeValue>
</Attribute>
</ResourceMatch>
</Resource>
<Action>
<Attribute
AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id"
DataType="&xml;string">
<AttributeValue>
SELECT
</AttributeValue>
</Attribute>
</Action>
</Target>
</Rule>
<!-- Permission to read table design_doc-->
<Rule
RuleId="Permission:to:read:table:design_doc"
Effect="Permit">
<Target>
<Resource>
<ResourceMatch MatchId="&function;string-equal">
55
<Attribute
AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id"
DataType="&xml;string">
<AttributeValue>
design_doc
</AttributeValue>
</Attribute>
</ResourceMatch>
</Resource>
<Action>
<Attribute
AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id"
DataType="&xml;string">
<AttributeValue>
SELECT
</AttributeValue>
</Attribute>
</Action>
</Target>
</Rule>
<!-- Permission to read table test_case_script-->
<Rule
RuleId="Permission:to:read:table:test_case_script"
Effect="Permit">
<Target>
<Resource>
<ResourceMatch MatchId="&function;string-equal">
<Attribute
AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id"
DataType="&xml;string">
<AttributeValue>
test_case_script
</AttributeValue>
</Attribute>
</ResourceMatch>
</Resource>
<Action>
<Attribute
AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id"
DataType="&xml;string">
<AttributeValue>
SELECT
</AttributeValue>
</Attribute>
56
</Action>
</Target>
</Rule>
<!-- Permission to read table test_log-->
<Rule
RuleId="Permission:to:read:table:test_log"
Effect="Permit">
<Target>
<Resource>
<ResourceMatch MatchId="&function;string-equal">
<Attribute
AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id"
DataType="&xml;string">
<AttributeValue>
test_log
</AttributeValue>
</Attribute>
</ResourceMatch>
</Resource>
<Action>
<Attribute
AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id"
DataType="&xml;string">
<AttributeValue>
SELECT
</AttributeValue>
</Attribute>
</Action>
</Target>
</Rule>
<!-- Permission to write and read table project_plan-->
<Rule
RuleId="Permission:to:read:table:project_plan"
Effect="Permit">
<Target>
<Resource>
<ResourceMatch MatchId="&function;string-equal">
<Attribute
AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id"
DataType="&xml;string">
<AttributeValue>
project_plan
</AttributeValue>
57
</Attribute>
</ResourceMatch>
</Resource>
<Action>
<Attribute
AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id"
DataType="&xml;string">
<AttributeValue>
SELECT, INSERT,DELETE,UPDATE
</AttributeValue>
</Attribute>
</Action>
</Target>
</Rule>
</Policy>
</PolicySet>
58
Appendix D
Permission PolicySet (RBAC & VPD) for Case Study Z
Permission PolicySet for software_engineer role (RBAC & VPD)
<PolicySet xmlns="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17 xacml-217 core-v3
schema-wd-17.xsd"
xmlns:access_policy="company:domain/schemas/access_policy.xsd"
PolicySetId="PPS:software_engineer:role"
Version="1.0"
PolicyCombiningAlgId="&policy-combine;permit-overrides">
<Target/>
<Policy PolicyId="Permissions:specifically:for:the:software_engineer:role"
Version="1.0"
RuleCombiningAlgId="&rule-combine;permit-overrides">
<Target/>
<ObligationExpressions>
<ObligationExpression
ObligationId="urn:oasis:names:tc:xacml:example:obligation:project_id"
FulfillOn="Permit">
<AttributeAssignmentExpression
AttributeId="urn:oasis:names:tc:xacml:3.0:example:attribute:project_id">
<AttributeSelector
MustBePresent="true"
Category="urn:oasis:names:tc:xacml:3.0:attribute-category:resource"
Path="access_policy:access_policy/user/projects/project_id"
DataType="http://www.w3.org/2001/XMLSchema#string"/>
</AttributeAssignmentExpression>
<AttributeAssignmentExpression
AttributeId="urn:oasis:names:tc:xacml:3.0:example:attribute:text">
<AttributeDesignator
MustBePresent="false"
Category="urn:oasis:names:tc:xacml:1.0:subject-category:access-subject"
AttributeId="urn:oasis:names:tc:xacml:1.0:subject:subject-id"
DataType="http://www.w3.org/2001/XMLSchema#string"/>
</AttributeAssignmentExpression>
</ObligationExpression>
</ObligationExpressions>
59
<!-- Permission to read and write table requirement_doc -->
<Rule
RuleId="Permission:to:read and write:table:requirement_doc"
Effect="Permit">
<Description>
A software engineer may read or write on table requirement_doc
only in projects assigned to him
</Description>
<Target>
<Resource>
<ResourceMatch MatchId="&function;string-equal">
<Attribute
AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id"
DataType="&xml;string">
<AttributeValue>
requirement_doc
</AttributeValue>
</Attribute>
</ResourceMatch>
</Resource>
<Action>
<Attribute
AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id"
DataType="&xml;string">
<AttributeValue>
SELECT, INSERT, DELETE,UPDATE
</AttributeValue>
</Attribute>
</Action>
</Target>
</Rule>
<!-- Permission to read table code-->
<Rule
RuleId="Permission:to:read:table:code"
Effect="Permit">
<Target>
<Resource>
<ResourceMatch MatchId="&function;string-equal">
<Attribute
AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id"
DataType="&xml;string">
<AttributeValue>
code
</AttributeValue>
60
</Attribute>
</ResourceMatch>
</Resource>
<Action>
<Attribute
AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id"
DataType="&xml;string">
<AttributeValue>
SELECT
</AttributeValue>
</Attribute>
</Action>
</Target>
</Rule>
<!-- Permission to read table design_doc-->
<Rule
RuleId="Permission:to:read:table:design_doc"
Effect="Permit">
<Target>
<Resource>
<ResourceMatch MatchId="&function;string-equal">
<Attribute
AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id"
DataType="&xml;string">
<AttributeValue>
design_doc
</AttributeValue>
</Attribute>
</ResourceMatch>
</Resource>
<Action>
<Attribute
AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id"
DataType="&xml;string">
<AttributeValue>
SELECT
</AttributeValue>
</Attribute>
</Action>
</Target>
</Rule>
<!-- Permission to read table test_case_script-->
<Rule
61
RuleId="Permission:to:read:table:test_case_script"
Effect="Permit">
<Target>
<Resource>
<ResourceMatch MatchId="&function;string-equal">
<Attribute
AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id"
DataType="&xml;string">
<AttributeValue>
test_case_script
</AttributeValue>
</Attribute>
</ResourceMatch>
</Resource>
<Action>
<Attribute
AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id"
DataType="&xml;string">
<AttributeValue>
SELECT
</AttributeValue>
</Attribute>
</Action>
</Target>
</Rule>
<!-- Permission to read table test_log-->
<Rule
RuleId="Permission:to:read:table:test_log"
Effect="Permit">
<Target>
<Resource>
<ResourceMatch MatchId="&function;string-equal">
<Attribute
AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id"
DataType="&xml;string">
<AttributeValue>
test_log
</AttributeValue>
</Attribute>
</ResourceMatch>
</Resource>
<Action>
<Attribute
AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id"
62
DataType="&xml;string">
<AttributeValue>
SELECT
</AttributeValue>
</Attribute>
</Action>
</Target>
</Rule>
<!-- Permission to write and read table project_plan-->
<Rule
RuleId="Permission:to:read:table:project_plan"
Effect="Permit">
<Target>
<Resource>
<ResourceMatch MatchId="&function;string-equal">
<Attribute
AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id"
DataType="&xml;string">
<AttributeValue>
project_plan
</AttributeValue>
</Attribute>
</ResourceMatch>
</Resource>
<Action>
<Attribute
AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id"
DataType="&xml;string">
<AttributeValue>
SELECT, INSERT,DELETE,UPDATE
</AttributeValue>
</Attribute>
</Action>
</Target>
</Rule>
</Policy>
</PolicySet>
63
Appendix E
XML Schema "ACCESS_POLICY"
<?xml version="1.0" encoding="UTF-8"?>
<access_policy
xmlns="urn:company:schemas:access_policy"
xmlns:xsi="http:///www.w3.org/2001/XMLSchema-instance">
<user>
<userName>BILL</userName>
<projects>
<project_id>101</project_id>
</projects>
<projects>
<project_id>102</project_id>
</projects>
<projects>
<project_id>103</project_id>
</projects>
<projects>
<project_id>104</project_id>
</projects>
</user>
<user>
<userName>ALICE</userName>
<projects>
<project_id>101</project_id>
</projects>
<projects>
<project_id>102</project_id>
</projects>
</user>
<user>
<userName>BOB</userName>
<projects>
<project_id>103</project_id>
</projects>
<projects>
<project_id>104</project_id>
</projects>
</user>
<user>
<userName>ACE</userName>
64
<projects>
<project_id>101</project_id>
</projects>
<projects>
<project_id>102</project_id>
</projects>
</user>
<user>
<userName>LILY</userName>
<projects>
<project_id>103</project_id>
</projects>
</user>
<user>
<userName>JAMES</userName>
<projects>
<project_id>104</project_id>
</projects>
</user>
<user>
<userName>JOE</userName>
<projects>
<project_id>101</project_id>
</projects>
</user>
<user>
<userName>KATE</userName>
<projects>
<project_id>102</project_id>
</projects>
</user>
<user>
<userName>JANE</userName>
<projects>
<project_id>103</project_id>
</projects>
<projects>
<project_id>104</project_id>
</projects>
</user>
<user>
<userName>SUSAN</userName>
<projects>
<project_id>101</project_id>
</projects>
65
<projects>
<project_id>102</project_id>
</projects>
</user>
</access_policy>
66
Appendix F
Implementation of Case Study Z RBAC in Oracle
1. start sql*plus as user with admin privileges
sqlplus sys as sysdba
password: password
2. create user SAPP (user SAPP is the administrator, owns database)
CREATE USER SAPP IDENTIFIED BY password;
GRANT CREATE SESSION TO SAPP WITH ADMIN OPTION;
GRANT dba TO SAPP;
3. Create users Alice, Bob, Kate, Susan, Carol, Joe, Ace, Bill, Lucy, Lily, James, Nancy,
Jane, Sue and Jack per Case Study Z.
4. As user SAPP, Create tables REQUIREMENT_DOC, CODE, DESIGN_DOC,
TEST_CASE_SCRIPT, TEST_LOG and PROJECT_PLAN per Case Study Z.
5. Populate tables
6. Create Roles (user SAPP)
CREATE ROLE software_engineer;
CREATE ROLE software_developer;
CREATE ROLE test_design_engineer;
CREATE ROLE test_engineer;
CREATE ROLE project_manager;
GRANT software_engineer,software_developer,test_design_engineer,test_engineer
to project_manager;
CREATE ROLE project_chief_manager;
GRANT project_manager to project_chief_manager;
67
7. Assign permissions to roles:
Permissions to Software Engineer:
--read write project_plan, requirement_doc
GRANT SELECT, INSERT, UPDATE, DELETE ON requirement_doc to
software_engineer;
GRANT SELECT, INSERT, UPDATE, DELETE ON project_plan to
software_engineer;
--just read permissions for code, design_doc, test_case_script, test_log
GRANT SELECT ON design_doc to software_engineer;
GRANT SELECT ON code to software_engineer;
GRANT SELECT ON test_case_script to software_engineer;
GRANT SELECT ON test_log to software_engineer;
grant create procedure to software_engineer;
Permissions to Software Developer:
--read write code, design_doc
GRANT SELECT, INSERT, UPDATE, DELETE ON design_doc to
software_developer;
GRANT SELECT, INSERT, UPDATE, DELETE ON code to software_developer;
--just read permissions for requirement_doc, test_case_script, test_log, project_plan
GRANT SELECT ON requirement_doc to software_developer;
GRANT SELECT ON project_plan to software_developer;
GRANT SELECT ON test_case_script to software_developer;
GRANT SELECT ON test_log to software_developer;
grant create procedure to software_developer;
68
Permissions to Test Engineer:
--read write test_log
GRANT SELECT, INSERT, UPDATE, DELETE ON test_log to test_engineer;
--just read permissions for requiremnt_doc, code, design_doc,
test_case_script,project_plan
GRANT SELECT ON design_doc to test_engineer;
GRANT SELECT ON code to test_engineer;
GRANT SELECT ON test_case_script to test_engineer;
GRANT SELECT ON requirement_doc to test_engineer;
GRANT SELECT ON project_plan to test_engineer;
grant create procedure to test_engineer;
Permissions to Test Design Engineer:
--read write test_case_script
GRANT SELECT, INSERT, UPDATE, DELETE ON test_case_script to
test_design_engineer;
--just read permissions for code, design_doc, requirement_doc, test_log,project_plan
GRANT SELECT ON design_doc to test_design_engineer;
GRANT SELECT ON code to test_design_engineer;
GRANT SELECT ON requirement_doc to test_design_engineer;
GRANT SELECT ON test_log to test_design_engineer;
GRANT SELECT ON project_plan to test_design_engineer;
grant create procedure to test_design_engineer;
8. Grant roles to users
grant project_manager to Alice;
grant software_engineer to Ace;
69
grant software_developer to Joe;
grant software_developer to Kate;
grant test_design_engineer to Susan;
grant test_engineer to Carol;
grant test_engineer to Lucy;
grant project_manager to Bob;
grant software_engineer to Lily;
grant software_engineer to James;
grant software_developer to Jane;
grant test_design_engineer to Sue;
grant test_design_engineer to Nancy;
grant test_engineer to Jack;
grant project_chief_manager to Bill;
70
Appendix G
VPD Policies for Case Study Z
Policy for table CODE
begin
dbms_rls.add_policy (
object_schema => 'SAPP',
object_name => 'CODE',
policy_name => 'CODE_POLICY',
function_schema => 'SECMAN',
policy_function => 'GET_PROJ_ID',
statement_types => 'SELECT,UPDATE,DELETE,INSERT',
update_check => TRUE
);
end;
/
Policy for table DESIGN_DOC
begin
dbms_rls.add_policy (
object_schema => 'SAPP',
object_name => 'DESIGN_DOC',
policy_name => 'DESIGN_DOC_POLICY',
function_schema => 'SECMAN',
policy_function => 'GET_PROJ_ID',
statement_types => 'SELECT,UPDATE,DELETE,INSERT',
update_check => TRUE
);
end;
/
Policy for table TEST_CASE_SCRIPT
begin
dbms_rls.add_policy (
71
object_schema => 'SAPP',
object_name => ' TEST_CASE_SCRIPT ',
policy_name => ' TEST_CASE_SCRIPT _POLICY',
function_schema => 'SECMAN',
policy_function => 'GET_PROJ_ID',
statement_types => 'SELECT,UPDATE,DELETE,INSERT',
update_check => TRUE
);
end;
/
Policy for table TEST_LOG
begin
dbms_rls.add_policy (
object_schema => 'SAPP',
object_name => ' TEST_LOG ',
policy_name => ' TEST_LOG _POLICY',
function_schema => 'SECMAN',
policy_function => 'GET_PROJ_ID',
statement_types => 'SELECT,UPDATE,DELETE,INSERT',
update_check => TRUE
);
end;
/
Policy for table PROJECT_PLAN
begin
dbms_rls.add_policy (
object_schema => 'SAPP',
object_name => ' PROJECT_PLAN ',
policy_name => ' PROJECT_PLAN _POLICY',
function_schema => 'SECMAN',
policy_function => 'GET_PROJ_ID',
statement_types => 'SELECT,UPDATE,DELETE,INSERT',
update_check => TRUE
);
end;
/
72
Bibliography
[1] OASIS.“eXtensible Access Control Markup Language (XACML)" Version 3.0.
Committee Specification 01, 10 August 2010. [online] http://docs.oasisopen.org/xacml/3.0/xacml-3.0-core-spec-cs-01-en.pdf [Accessed: November 9,
2012]
[2] OASIS. "XACML v3.0 Core and Hierarchical Role Based Access Control
(RBAC) Profile" Version 1.0. Committee Draft 03, 11 March 2010. [online]
http://docs.oasis-open.org/xacml/3.0/xacml-3.0-rbac-v1-spec-cs-01-en.pdf
[Accessed: November 9, 2012]
[3] Zhimin Cheng. "Object-Relational Database approach for Role-Based Access
Control (RBAC)", Project Master of Computer Science, Sacramento State
University, Spring 2012
[4] Oracle Database Security Guide 10g Release 1 (10.1) Part Number B10773-01.
[online] http://docs.oracle.com/cd/B14117_01/network.101/b10773/index.htm
[Accessed: November 9, 2012]
[5] Oracle Database Security Guide 11g Release 1 (11.1) Part Number B28531-16.
[online] http://docs.oracle.com/cd/B28359_01/network.111/b28531/index.htm
[Accessed: November 9, 2012]
73
[6] Arup Nanda, Donald K. Burleson. "Oracle Privacy Security Auditing". Rampant
Techpress, North Carolina (2003)
[7] Jahid Sonia, Hoque Imranul, Gunter Carl A., Okhravi Hamed. "MyABDAC:
Compiling XACML Policies for Attribute-Based Database Access Control".
CODASPY'11 Proceedings of the first ACM conference on Data and application
security and privacy, New York, NY, USA, 2011, pages 97-108.