A Policy Based Framework for Access Control.

Full text

Page 1

A Policy Based Framework for Access Control
Ricardo Nabhen, Edgard Jamhour, Carlos Maziero
PPGIA – PUC PR – CURITIBA – PARANÁ - BRAZIL
{rcnabhen, jamhour, maziero}@ppgia.pucpr.br


Abstract. This paper presents a policy-based framework for managing access
control in distributed heterogeneous systems. This framework is based on the
PDP/PEP approach. The PDP (Policy Decision Point) is a network policy server
responsible for supplying policy information for network devices and
applications. The PEP (Policy Enforcement Point) is the policy client (usually,
a component of the network device/application) responsible for enforcing the
policy. The communication between the PDP and the PEP is implemented by
the COPS protocol, defined by the IETF. The COPS (Common Open Policy
Service) protocol defines two modes of operation: outsourcing and
provisioning. The choice between outsourcing and provisioning is supposed to
have an important influence on the policy decision time. This paper evaluates
the outsourcing model for access control policies based on the RBAC (Role-
Based Access Control) model. The paper describes a complete implementation
of the PDP/PEP framework, and presents the average response time of PDP
under different load conditions.
1. Introduction
In policy-based networking (PBN), a policy is a formal set of statements that define
how the network's resources are allocated among its clients. Policies may be used to
achieve better scaling in network management by describing common attributes of
classes of objects, such as network devices, software services and users, instead of
individually defining attributes for these elements. In order to implement PBN it is
important to define a vendor independent method for representing and storing
network policies. A formal method for representing users, services, groups and
network elements is also required. An important work in this field, called CIM
(Common Information Model), was proposed by the DMTF (Distributed Management
Task Force) [4]. The CIM model addresses the problem of representing network
resources. PCIM (Policy Core Information Model) is an information model proposed
by IETF that extends CIM classes in order to support policy definitions for managing
these resources [5]. PCIM is a generic policy model. Application-specific areas must
be addressed by extending the policy classes and associations proposed by PCIM. For
example, QPIM (QoS Policy Information Model) is a PCIM extension for describing
quality of service polices [11]. In this context, this paper describes a PCIM extension
for access control, called RBPIM (Role Based Policy Information Model), which
permits to represent network access control policies based on roles, as well as static
and dynamic constraints, as defined by the proposed NIST RBAC standard [1].

Page 2

Typically, PCIM is implemented using a PDP/PEP approach [9]. The PDP
(Policy Decision Point) is a network policy server responsible for supplying policy
information for network devices and applications. The PEP (Policy Enforcement
Point) is the policy client (usually, a component of the network device/application)
responsible for enforcing the policy. The communication between the PDP and the
PEP is implemented by the COPS protocol, defined by the IETF [10]. The COPS
(Common Open Policy Service) protocol defines two modes of operation: outsourcing
and provisioning. In the outsourcing model, the PDP receives policy requests from the
PEP, and determines whether or not to grant these requests. Therefore, in the
outsourcing model, the policy rules are evaluated by the PDP. In the provisioning
model the PDP prepares and "pushes" configuration information to the PEP. In this
approach, a PEP can take its own decisions based on the locally stored policy
information.
The motivation for defining RBAC in PCIM terms can be summarized as
follows. First, there are several situations where the same set of access control
policies should be available for heterogeneous applications in a distributed
environment. This feature can be achieved by adopting the PDP/PEP framework.
Second, an access control framework requires having access to information about
users, services and applications already described in a CIM/PCIM repository.
Implementing access control in PCIM terms permits to leverage the existing
information in the CIM repository, simplifying the task of keeping a unique source of
network information in a distributed environment.
The remaining of this paper is organized as follows: Section 2 presents a short
description of the RBAC model used in this paper. Section 3 reviews some related
works. Section 4 presents RBPIM. Section 5 presents the RBPIM framework
implemented using the outsourcing model. Section 6 presents the performance
evaluation results of a prototype of the RBPIM framework under various load
conditions. Finally, the conclusion summarizes the main aspects in this project and
points to future works.
2. RBAC Model
RBAC models have received a broad support as a generalized approach to access
control, and are well recognized for their many advantages in performing large-scale
authorization control. Several RBAC models have been proposed, each one exploring
features that, supposedly, exhibit true enterprise value. The RBAC model adopted by
the RBPIM framework is based on the proposed NIST (National Institute of
Standards and Technology) Standard [1]. The RBPIM framework accommodates the
most important RBAC features described in [1]. Also, the PEP implementation in the
RBPIM framework (called RBPEP – Role Based PEP) is based on API’s described in
the proposed NIST RBAC functional specification [1]. This section will present a
summary of the RBAC features used in the RBPIM framework. The purpose of this
summary is to define a standard nomenclature for presenting the RBPIM framework
in sections 4 and 5. For a more complete description, please, refer to the proposed
NIST standard [1].

Page 3

The proposed NIST standard presents a RBAC reference model based on four
components: Core RBAC, Hierarchical RBAC, Static Separation of Duty Relations
and Dynamic Separation of Duty Relations. The idea of organizing the reference
model in components is to permit vendors to partially implement RBAC features in
their products. The Core RBAC model element includes sets of five basic data
elements called users (USER), roles (ROLES), objects (OBS), operations (OPS), and
permissions (PRMS). The main idea behind the RBAC model is that permissions are
assigned to roles instead of being assigned to users. The User Assignment (UA) is a
many-to-many relationship. An important concept in RBAC is that roles must be
activated in a session. That means that user must select the roles he wants to activate
within a session in order to get the permissions associated to the roles. A session is
associated with a single user, and each user is associated with one or more sessions.
The Permission Assignment (PA) is also a many-to-many relationship (i.e., a
permission can be assigned to one or more roles, and a role can be assigned to one or
more permissions). A permission is an approval to perform an operation (e.g., read,
write, execute, etc.) on one or more RBAC protected objects (e.g., a file, directory
entry, software application, etc.). The Hierarchical RBAC model element introduces
role hierarchies (RH). Role hierarchies simplify the process of creating and updating
roles with overlapping capabilities. In the proposed RBAC model, role hierarchies
define an inheritance relation of permissions among roles; e.g., r1 “inherits” role r2 if
all privileges of r2 are also privileges of r1. The Static Separation of Duty (SSD)
model element introduces static constraints to the User Assignment (UA) relationship
by excluding the possibility of the user to assume conflicting roles. The proposed
RBAC model defines SSD with two arguments: a role set that includes two or more
roles, and a cardinality greater than one indicating the maximum combination of roles
in the set a user can be assigned, e.g., for constraining a user to assume the roles “r1”
and “r2”, one must define a set {r1, r2} with cardinality 2 (the user can assume
cardinality-1 roles in the set). The Dynamic Separation of Duty (DSD) model element
introduces constraints on the roles a user can activate within a session. The strategy
for imposing constraints on the activation of roles is similar to the SSD approach,
using a set of roles and cardinality greater the one. Note that SSD imposes general
constraints on which roles a user can assume, while DSD imposes constraints on
which roles a user can simultaneously activate in a session.
The RBPIM framework described in sections 4 and 5 supports all four elements
of the proposed NIST standard and proposes a more flexible method for defining UA
relationships by combining Boolean conditions as defined by the PCIM standard and
its extensions [6].
3. Related Works
Recent works starts exploring the advantages of the PDP/PEP approach for
implementing an authorization service that could be shared across a heterogeneous
system in a company. An interesting work in this field is the XACML (eXtensible
Access Control Markup Language), proposed by the OASIS consortium [12].
XACML is a XML based language that describes both an access control policy
language and a request/response language. The policy language is used to express

Page 4

access control policies. The request/response language is used for supporting the
communication between PEP clients and PDP servers. RBPIM framework described
in this paper also uses the PDP/PEP approach. However, our approach differs from
XACML on several points. First, the RBPIM uses a standard COPS protocol for
supporting the PEP/PDP communication, instead of XML. Second, the information
model used for describing policies is based on a PCIM extension. Third, RBPIM has
been implemented for supporting a specific access control method, the RBAC. That
permits to define a complete framework that includes the algorithms in the PDP,
especially conceived for evaluating policies that includes hierarchy of roles and both,
dynamic and static separation of duties.
Most of the research efforts found in the literature refer to the use of the PCIM
model and its extensions for developing policy management tools for QoS support
[11]. However, a pioneer work for defining a PCIM extension for supporting RBAC,
called CADS-2, has been proposed by BARTZ, L.S. [3]. The CADS-2 is a review of a
previous work, called hyperDRIVE, also proposed by BARTZ [2]. The hyperDRIVE
is a LDAP [7] schema for representing RBAC. This schema can be considered as a
first step for implement RBAC using the PDP/PEP approach. However, hyperDRIVE
was elaborated before the PCIM standard, and has been discontinued by the author.
As hyperDRIVE, CADS-2 defines classes suitable to be implemented in a directory-
based repository, such as LDAP. CADS-2 defines RBAC roles in terms of policy
objects, and introduces classes to support different comparison operators, e.g., equal,
greaterThan, lessThan. These operators permit to represent complex comparison
expressions with the attribute values of other object stored in a LDAP repository.
These expressions are used to represent the conditions a user must satisfy in order to
assume a RBAC role. The RBIM model described in the section 5 uses some ideas
presented in the CADS-2 model. Specially, the idea of mapping roles to users using
Boolean expressions. Note that this approach offers an additional degree of freedom
for creating RBAC policies because the UA (User Assingment) relationship can be
expressed through Boolean expressions instead of a direct mapping between user and
roles. However, a recent IETF publication called PCIMe (PCIM Extensions) proposes
a different approach for representing Boolean expressions [6]. The RBPIM
framework adopts the PCIMe strategy. Also, many features have been introduced in
order to support the other elements of the RBAC model, such as hierarchy of roles,
DSD and SSD, not supported in the original CADS-2 model.
4. RBPIM: The Role Based Policy Information Model
Figure 1 shows the PCIM model, and the proposed RBPIM extensions for supporting
RBAC policies. In the PCIM approach, a policy is defined as a set of policy rules
(PolicyRule class). Each policy rule consists of a set of conditions (PolicyCondition
class) and a set of actions (PolicyAction class). If the set of conditions described by
the class PolicyCondition evaluates to true, then a set of actions described by the class
PolicyAction must be executed. A policy rule may also be associated with one or
more policy time periods (PolicyTimePeriodCondition class), indicating the schedule
according to which the policy rule is active and inactive. Policy rules may be

Page 5

aggregated into policy groups (PolicyGroup class) and these groups may be nested, to
represent a hierarchy of policies.

*

-ConditionGroupNumber
PolicyCondition PolicyAction (abstract)
-TimePeriod
PolicyTimePeriodCondition
*
*
**
-RoleName
-InheritedRoles[]
RBACRole **
-PermissionName
RBACPermission **
RBACPolicyGroup **
-AssignedRBACPermission
AssignerRBACPermission **
-DSDName
-RoleSet[]
-Cardinality
DSDRBAC **
-AssignedOperation[]
AssignerOperation **
-DSDName
-RoleSet[]
-Cardinality
SSDRBAC **
*
*
*
SimplePolicyCondition
+ConditionListType
-RulePriority
PolicyRule
*
*
*
*
PolicyVariable
PolicyValue
*
1
*
1
**
RBPIM
classes

Fig.1. PCIM class hierachy and RBPIM extensions.

In a PolicyRule, rule conditions can be grouped by two different ways: DNF
(Disjunctive Normal Form) or CNF (Conjunctive Normal Form). The way of
grouping policy conditions is defined by the attribute ConditionListType in the
PolicyRule class. Additionally, the attributes GroupNumber and ConditionNegated, in
the association class PolicyConditionInPolicyRule helps to create condition
expressions. In DNF, conditions within the same group number are ANDed (∧) and
groups are Ored (∨ ). In CNF, conditions within the same group are ORed (∨ ) and
groups are ANDed (∧). In order to illustrate this approach, suppose we have a set of
five
PolicyConditions Ci(GroupNamber,ConditionNegated)
C={C1(1,false), C2(1,true), C3(1,false), C4(2,true), C5(2,false)}. Then, the overall
condition for the PolicyRule will be defined as:

If ConditionListType = DNF then:
( )
evaluate
C
If ConditionListType = CNF then:
( )
evaluate
C

The RFC 3460 proposes several modifications in the original PCIM standard.
These modifications are called PCIMe (Policy Core Information Model Extensions)
[6]. PCIMe solves many practical issues raised after the original PCIM publication.
For example, PolicyCondition have been extended in order to support a
straightforward way for representing conditions by combining variables and values.
This extension is called SimplePolicyCondition.
The strategy defined by SimplePolicyCondition is to build a condition as a
Boolean expression evaluated as: does <variable> MATCH <value>? Variables are
created as instances of specializations of PolicyVariable. The values are defined by
instances of specializations of PolicyValue. The MATCH element is implicit in the
model. PCIMe defines two types of variables: explicit (PolicyExplicitVariable) and
implicit (PolicyImplicitVariable).
Explicit variables are used to build conditions that refer to objects stored in a
CIM repository. For example, considers the following condition: Person.Surname
MATCH “Doe”. Person.Surname refers to the Surname attribute of the class Person
in the CIM model. This condition is expressed as PolicyExplicitVariable.ModelClass
as follows:
(
C
)
∧
(
C
) C
C
∨
C
(
C
C
∨
C
C
!C
(
5
)
5
43
)
21
∧∨∧∧=

=

!
4321
∨