Meta Model Based Integration of Role-Based and Discretionary Access
Control Using Path Expressions
Kathrin Lehmann, Florian Matthes
Chair for Software Engineering for Business Information Systems
Technische Universitaet Muenchen
{lehmannk, matthes}@in.tum.de
Abstract
Business applications have to deal with two types of
access control models: the role-based and the
discretionary access control model. The main
contribution of this paper is that both data models are
unified in a single description language. Starting from
a meta model of an object oriented data model and a
simple service model this paper shows how to describe
and integrate access control needs in common business
applications using an authorization model based on
path expressions. These path expressions can be used
to construct set-oriented queries for access control
decisions derived from the data model of the
application. Throughout the paper one example shows
the expressive power of this authorization model.
1. Introduction
Reliable
authentication
and
authorization
mechanisms are the two basic requirements that make
up secure systems. By means of authentication the
identity of the calling subject is verified. Entities whose
identity can be verified are also called principals.
Authorization procedures allow controlled access to
restricted system resources. The calling subject must
hold the permissions applicable to the request made in
order to access restricted resources. This paper is about
authorization.
Access control systems are described by subjects,
objects and actions. A permission is the ability to
perform an action on an object. Some synonyms for
permission are “right”, “privilege”, “entitlement” and
“authorization”. Objects for which permissions are
requested are called targets. In the simplest case
granting permission to a subject only depends on the
action, target and subject itself. More complex access
control requests may need to know additional
information like the state of the target object of other
related objects within the system.
Subjects are the active elements within a system;
they are also called “initiators” or “requestors”. Objects
represent the passive elements; they are resources on
which protected operations – the actions – are invoked.
Actions may have side-effects. Therefore, the
invocation of access restricted operations should be
considered a transaction that is either executed as a
whole unit or not at all. This is to protect the integrity
of the system and the resources administered herein at
any time. Here, a transaction does not incorporate all
ACID properties. Consistency and durability are not
considered.
Within business information systems, the role-based
access control (RBAC) model is most widely used. In
RBAC, permissions on objects are grouped into roles.
These roles are then assigned to subjects. In order to
successfully execute an action on an object the
requesting subject needs to have one or more roles
activated that allow the execution of this action. There
exists a proposed standard for this access control model
[1]. The highest possible security of an RBAC-based
system is reached if the principle of least privilege is
implemented. Therefore subjects should be able to
surrender all but the minimal set of roles that enable the
execution of the requested action(s).
In some business information systems, e.g.
community software, it is desirable to leave some
access control decisions to the discretion of the owner
of the respective resource, so that (s)he may decide
which other subjects may impose which actions on the
owned resources. This model is called discretionary
access control (DAC) model.
In most business applications, both kinds of models
are used in a mixed fashion. To unify administration
tasks, both models have to be described in a common
way. A naive way to do this is by establishing for every
subject a separate role which represents the rights of
ownership to owned resources. But this procedure
produces a large number of roles that encapsulate only
one subject, namely the owner of the resource for
whom this role was created.
In this paper, a different approach is taken. Access
control decision functions are represented by paths in a
data model.
The paper is structured a follows. In the next
chapter some related work is referenced. In chapter 3
the meta data model used as a basis for constructing
path expressions for access control is introduced.
Chapter 4 gives an example data model that is used
throughout this paper. Chapter 5 introduces a simple
service model that is assumed for this work. Chapter 6
is the main contribution of this paper. It explains an
access control model based on path expressions.
Chapter 7 gives a short example applying the access
control model to the example introduced in chapter 4.
The paper ends by giving a conclusion and hints on
future work.
hierarchical model most suitable for XML-oriented
languages.
Another example is the Java Security Architecture
(JSA) [3]. JSA supplies the programmer with interfaces
and classes for programming permissions and enforcing
access control policies. The emphasis here lies on code
access security, i.e. users may classify code into being
trusted or not trusted by means of the code base,
signatures of class files and the like. New to JSA is that
security policies may also express access control
decisions based on the principal that is running the
code. Some predefined permissions accessing system
resources like sockets, the file system, etc. are already
being enforced by the security manager installed in the
Java Runtime Environment. Enforcement of userdefined permissions has to be coded by hand.
Therefore usage of JSA does not alleviate work when
defining and implementing access control restrictions
for arbitrary business objects.
SecureUML [4] is a model driven approach to
generating source code from a UML-model using
special extension syntax to express role-based security
demands. The role-based access control model used by
SecureUML is a fixed model. For using different
access control models, like DAC, a different extension
syntax has to be developed.
2. Related work
3. The meta data model
As there exist many publications already on access
control models and implementations the reference list
only shows some major works that are relevant in the
area of business applications.
One example is the eXtensible Access Control
Markup Language, in short: XACML, which is an
OASIS standard currently in version 1.0 [2]. XACML
is a powerful description language for expressing
security policies in distributed systems by means of a
standardized XML-format. XACML consists of a core
specification and some profile extensions for special
needs such as role-based access control or access to
hierarchical resources. However, due to the
hierarchical format of XML-documents, resources that
may be best administered by XACML policies also
have a tree like, hierarchical structure. This is e.g. the
case with file systems. It is rather intricate to express
access control demands for resources structured
otherwise. When protecting business objects that are
connected via associations with other business objects,
this network model is rather awkwardly expressed in a
The meta model used throughout this paper (see
Figure 1) is similar to the object-oriented data model of
the Meta Object Facility specification [5]. The objectoriented data model describes resources, namely the
business objects as classes with properties and
associations between them. Associations may have
properties describing further qualities of the
association. Common association kinds are one-tomany associations with cardinalities 1 on the one-side
and * on the many-side and many-to-many associations
with a cardinality of * on both sides. Instances of
associations that connect instances of classes are called
links in this data model.
Relational ER-diagrams as well as UML-class
diagrams may be directly mapped to their meta model.
2..*
* Role
multiplicity
1..*
1
Association
Class
1
1
1
xor
* Property
type
*
Instance
1
*
1..*
*
Link
*
Figure 1: Meta data model
4. Example data model
The following example application is used
throughout this paper. The example (see figure 2)
represents community software that manages weblogs.
Weblog
-id: String
-name: String
*
author 0..1
WEBLOG_AUTHOR
reader 0..1
*
Group
-id: String
-name: String
WEBLOG_READER
1
parent
*
*
GROUP_MEMBER
WEBLOGENTRY
_WEBLOG
owner 1
WEBLOG_OWNER
*
WeblogEntry
-text: String
-view: int
* member
Person
-name:String
-isAnonymous: boolean
1
*
entryAuthor
WEBLOGENTRY_AUTHOR
Figure 2: Example data model
Weblogs are websites that are published by a
Person and are updated frequently, e.g. daily. They
consist of a list of WeblogEntries that are sorted in
reversed chronological order. In the example below
each weblog belongs to a designated person, the owner.
Each weblog may be read by a Group of persons, the
reader group, and entries may be written by an author
group. The person creating an entry has special rights
connected to this entry, so that the entry author
association becomes necessary. Weblog entries may be
either public (visible to a reader group) or private
(visible to the entry author only).
The entities Weblog, WeblogEntry, Person, and
Group represent Instances from the meta data model.
Instances and their properties are the resources that are
to be protected by an access control system. They are
stored in persistent storage and retrieved from storage
and written on demand.
Weblog_Author, Weblog_Reader, Weblog_Owner,
WeblogEntry_Author are instances of one-to-many
associations; Group_Member is an instance of a manyto-many association.
As can be seen from this example, associations
serve two purposes. They may express “real”
associations, e.g. WeblogEntry_Weblog expresses a
whole-part relationship between weblogs and its
entries. Other associations are used to express access
control features. Discretionary access control is based
on ownership relations. WeblogEntry_Author and
Weblog_Owner are two associations that express just
this kind of access control relationship. For role-based
access control, access rights are given to groups. In this
example Weblog_Author and Weblog_Reader together
with Group_Member form the associations expressing
the role-based part of access control demands in the
weblog application.
5. The service model
When constructing access control models one has to
choose an appropriate level and granularity for
protecting resources. It is common practice to realize
business applications with a three-tiered architecture.
The first tier, the presentation layer, constitutes the
front-end. This could e.g. be a web front-end. Business
logic is encapsulated in the second tier, whereas the
database makes up the third tier. In general, the
business logic is structured rather simple. The main
task of the business applications consists in processing
client requests that essentially do nothing else than
retrieving data from persistent storage, display this data
for the client and writing back some updated data back
to persistent storage. Interactions of clients with the
system take place via predefined interfaces that are
offered in the presentation layer. Of course, if the
application does not have a visual front end, offered
services are interfaces that have to be invoked by some
other protocol. An example for this kind of service
oriented applications is web-services.
Operations protected by an access control system
may be at different levels of granularity. One extreme
may be to protect low-level operations like reading or
writing properties of business objects, creating,
deleting, reading, or writing associations. Alternatively,
access control decisions may be enforced at a medium
level, e.g. at the level of methods of business objects.
This level offers more contexts of the semantics of
protected operations but protected operations have to
be mapped to low-level operations of protected
resources. The third possibility may be to protect highlevel operations, i.e. processing of a complete client
request. This procedure offers the most execution
context but is also hardest to realize in a complete
fashion, since access control enforcement takes place
far away from the resources to be protected.
Protecting low-level operations is not an
appropriate level of abstraction for enforcing access
control policies of business applications. Assume two
different restriction policies, for creating and editing
weblog entries in our example data model. Only
members of the author group and the owner of a
weblog are allowed to create a new entry. Once the
entry is created, the contents may be only edited by the
entry author, namely the person who created the entry.
During execution of both actions, the properties (text
and view in our example) are set. These set-operations
map in both cases to the same low level write-operation
of properties. If access control is enforced at this lowlevel the context of whether these operations take place
during creation or editing is lost. Therefore at this low
level it cannot be decided whether these write
operations should be allowed or denied.
Access control could be enforced at the level of
methods of business objects (medium level). But the
same business method is called during processing
several client requests. When changing one access
control policy of one business object, it is not
immediately clear which kinds of client requests are
affected.
An appropriate higher-level context is given by
service methods. They correspond to the high-level
access control context mentioned above. Before giving
an example, the service model used in this paper is
introduced (see Figure 3). It has a rather simple
structure. A service consists of service methods. Clients
issue service requests to execute some service method
on a specific target. A client is a principal belonging to
a session in which the service request is executed. The
target is some concrete Instance of a business object.
Also the initiator is represented by some Instance for
example of Class Person in Figure 2.
To execute a service method, some access
restrictions must be fulfilled. These restrictions are
formalized by path expressions described later in this
paper. From the path expression one of two database
queries may be built and executed in order to check
whether execution of the service method should be
allowed.
Service
*
ServiceMethod *
1
*
*
ServiceRequest
0..1
authorized_subjects
PathExpression
*
1
Session
target 1
*
1
Instance
principal
Figure 3: Service model
Every request issued by a client comprises one
service method. In our weblog example possible
service requests refer to coarse-grained actions of
business objects. Service methods for weblog entries
might be WeblogEntryCreate for creating a new
weblog entry, WeblogEntryRemove for deleting an
entry, WeblogEntryEditText for editing the contents of
an entry, WeblogEntryMove to move the entry from
one weblog to another, WeblogEntrySwitchView to
switch from private to public visibility or vice versa.
6. The authorization model
As explained above, access restrictions for business
applications should be linked to service methods. A
security policy should define for every service method
a corresponding access restriction. Since the data
model of business applications already contains
relationships, i.e. associations, useful to describe rolebased and discretionary requirements, the access
control model introduced here is based on navigating
these relationships in the business application’s data
model.
If we want to check whether some action is allowed
to be executed on some target object by some initiating
principal, we try to find a path between the target
object and the object representing the principal along
associations that express the security policy in effect. In
other words, access is granted, if starting from the
resource accessed navigation along one or more
predefined path via associations and properties finally
ending at the class representing the calling subject, that
is the principal from the service model, is possible.
A PathExpression defines a declarative mapping
from a given target object to a set of subjects. A
ServiceRequest with a given subject s, a target t and a
ServiceMethod
with
a
PathExpression
authorized_subjects is permitted, if the subject is an
element of the set defined by the PathExpression.
s  ServiceMethod.authorized _ subjects(t )
Access restrictions may be independent of the
target. For example, some access restrictions may
express that access is allowed for members of the
administrator group independent from the target being
accessed. In this case the authorized_subjects does not
depend on the parameter t.
The access control model consists of the following
parts (see figure 4):
Class
1
1 domain *
PathExpression 1
1 range
*
1
1 1
path
(from meta model)
1
Property
(from meta model)
*
1
Class
(from meta model)
*
*
left
*
*
Not
right
*
1
Role
tail
Edge
head
Filter
operation
value
*
Composition
*
Concat
Or
And
Figure 4: Path model
Edge: An edge is a navigation from one class via an
association denoted by a role name to another class.
Roles in object orientation are names of association
ends (rather than roles in the RBAC sense). Starting
from a concrete domain object, navigation to another
object is represented by the role name at the association
end of the class denoting the range. In case the role
name is missing, the name of the associated class can
be used instead. If the association end has cardinality 1,
then the result of the navigation will be a single object.
If the association end is denoted 0…1 then the result
may be empty. If the association end is *, 1…* or
otherwise denoted greater than one, then the result of
the navigation will be a collection of zero, one or more
objects. After a single navigation step the resulting
collection represents a set since navigation targets are
all distinct. Further navigation from a set of objects via
a second edge either results in a collection of objects or
a collection of sets of objects depending on whether
navigation starts from a single object or a set of objects
respectively. Collections of sets are implicitly flattened
to single sets with duplicates being removed.
Filter: A filter is a path expression where domain
and range objects are of the same type. By means of
filters the collection resulting from path navigation may
be constrained to a subset by restricting the range of
values of a property of the object. Filter operators may
be e.g. “equals”, “smaller than”, “greater than”,
“smaller or equal”, “greater or equal”. If the filter is
applied to a single domain object, the outcome may
either be the one-element set containing the same
object or the empty set. If the filter is applied to a set of
domain objects, the filter operator will be applied to
every element of the set.
filter ( property, operation, value)  x.
{x  property.class | operation( x, value)  true}
Concat: A concatenation connects two paths, the
head path with the tail path, to form a single longer
path. The type of the range class of the head path must
be equal to the type of the domain class of the tail path.
concat(head, tail)  x.

tail( y )
yhead ( x )
Composition: Two paths with the same target class
in the data model may be connected by “and” or “or”,
meaning that the result contains subjects identified by
both paths or at least one path respectively.
union(left , right)  x.
{ y | y  left ( x)  y  right( x)}
intersection(left , right)  x.
{ y | y  left ( x)  y  right( x)}
Not: Not takes a PathExpression p from a class
domain to a class range and yields the set of range
objects in the class range that are not member of the set
identified by p(domain).
not( p)  x.
{ y  p.range | y  p( x)}
7. Example path expressions
To give an example how to apply the above path
expressions, access restrictions on the two actions for
creating and reading objects of the WeblogEntry-class
are given below.
The access restriction for calling the service method
WeblogEntryCreate to create a new weblog entry is
e.g. given by the following constraint given in clear
text:
Creating a new weblog entry is allowed, if the
principal issuing the request is either the owner of
the weblog or member of the author group of the
weblog the weblog entry is created in.
Weblog
-id: String
-name: String
author 0..1
*
WEBLOG_AUTHOR
reader 0..1
*
Group
-id: String
-name: String
WEBLOG_READER
parent
1
*
*
weblogentrycreatepath =
concat(
edge(parent),
or(
concat(
edge(author),
edge(member)),
edge(owner)))
Executing the WeblogEntryCreate action is
allowed, if the result set includes the caller who is also
represented by an object of type person.
GROUP_MEMBER
WEBLOGENTRY
_WEBLOG
WEBLOG_OWNER
*
WeblogEntry
-text: String
-view: int
Since the ownerpath and the authorpath both have a
common sub-path, the overall path may also be
constructed by using a concatenation of an edge with a
union:
* member
Person
owner 1
-name:String
-isAnonymous: boolean
1
entryAuthor
*
WEBLOGENTRY_AUTHOR
Figure 5: Visualization of path expression
for access restriction WeblogEntryCreate
Figure 5 visualizes the path expression that must be
fulfilled for this access restriction. The WeblogEntryCreate restriction is a union set consisting of a
discretionary and a role-based path. The discretionary
path is a concatenation path of two edges (lower path in
figure 5):
The usage of filters may be shown by looking at the
access restrictions for reading the contents of a weblog
entry. The access restriction is as follows:
The contents of a weblog entry with private
visibility may be read by the entry author only. The
contents of a weblog entry with public visibility
may be read by all members of the reader group of
the weblog the weblog entry belongs to.
This access restriction constitutes an if-condition: If
the weblog entry is private then the author may read it,
otherwise members of the reader group may read it.
This if-construct may be described by a union
construct. Because a weblog entry may be either
private or public, at most one of the two sub paths will
yield a result that is not empty.
ownerpath = concat(edge(parent), edge(owner))
The role-based path concerning membership of the
author group (upper path in figure 5) is a concatenation
of three edges:
authorpath=
concat(
concat(edge(parent), edge(author)),
edge(member))
The result set of the path navigation is the union of all
person objects that are authors with the person object
representing the owner.
weblogcreatepath =
or(ownerpath, authorpath)
privatepath =
concat(
filter(view, =, PRIVATE),
edge(entryauthor))
publicpath =
concat (
not(filter(view, =, PRIVATE)),
concat(
concat(
edge(parent),
edge(reader)),
edge(member)))
weblogentryreadpath =
or(privatepath,publicpath)
8. Conclusion
This paper shows how to use a simple path
expression language to express role-based and
discretionary access control in a single, easy to
understand format. Since the access control model is
based on the object-oriented data model, which by now
can be considered a standard for building business
applications, it can be applied to a wide range of
applications. The service model is kept very simple so
that monolithic business applications as well as web
services are covered by the presented access control
model.
Besides subject-oriented access control policies like
role-based and discretionary access control, there exist
access constraints that are independent of the
requesting subject. Examples are workflows, where
access of a resource solely depends on the state of the
resource. At the moment these cases cannot be covered
by path expressions. Future work will include path
expressions in reverse order, ending at the target, in
order to also cover these resource-oriented access
control demands.
An advantage of the introduced path expressions is
that they have a simple grammar. It is easy to express
paths by OCL [6] (not shown in this paper) and
annotate the data model with according OCL
expressions to make access control policies transparent.
Path expressions have a compact notation.
Therefore it is possible to use them for mathematical
analysis. Also path expressions may be used to
automatically construct queries that may be uniformly
translated to a database queries. Also access
restrictions may be read directly from the data model.
Future work will engage in using path expressions
in an introspective framework. Then access control
restrictions may be read directly from the source code.
Also the object-oriented data model allows for some
interesting visualization possibilities for showing
access control restrictions directly on the data model.
9. References
[1] Ferraiolo, D. and Sandhu, R. and Gavrila, S. and Kuhn,
R. and Chandramouli, R., “Proposed NIST Standard for
Role-Based Access Control”, ACM Transaction on
Information and System Security, Vol. 4 (2001), No. 3, pp.
224-274
[2] Godik, S. and Moses, T. et al. “eXtensible Access
Control Markup Language (XACML), http://www.oasisopen.org/committees/tc_home.php?wg_abbrev=xacml,
February 2003
[3] Java Security Architecture,
http://java.sun.com/j2se/1.5.0/docs/api
2005)
API-Specification,
(visited February
[4] Lodderstedt, T. and Basin, D. and Doser, J., SecureUML:
A UML-Based Modeling Language for Model-Driven
Security, In: Jézéquel, J.-M., and Hussmann, H. and Cook,
S.: UML 2002 – The Unified Modeling Language. Model
Engineering, Languages, Concepts, and Tool. 5 th
International
Conference,
Dresden,
Germany,
September/October 2002. Proceedings Vol. 2460, SpringerVerlag, 2002, p. 426-441
[5] OMG, “Meta Object Facility (MOF) Specification”,
http://www.omg.org/docs/fomal/02-04-03.pdf, April 2002
[6]
OMG,
“UML
2.0
OCL
Specification”,
http://www.omg.org/docs/ptc/03-10-14.pdf, November 2003