enforcing complex access control policies in rich domain
TRANSCRIPT
Enforcing Complex Access Control Policies in Rich Domain
Applications
Gonçalo Mascarenhas Dumiense
Dissertação para obtenção do Grau de Mestre em
Engenharia Informática e de Computadores
Júri
Presidente: Doutor Nuno João Neves Mamede
Orientador: Doutor João Manuel Pinheiro Cachopo
Vogais: Doutora Maria Dulce Pedrosa Domingos
Doutor Carlos Nuno da Cruz Ribeiro
Doutor António Manuel Ferreira Rito da Silva
Setembro de 2008
AbstractDue to the high demand of functionality, the complexity of applications is constantly increasing. To tackle
this growth in complexity, programmers are adopting new development approaches. One such approach is
the Domain-Driven Design, which states that the development of applications should be centered around
the entities that compose the problem being solved by the application - the application’s domain. These
entities should be structured in what is called a domain model. Rich Domain Model (RDM) applications are
applications that present a domain model which has both a complex structure and a rich behavior.
Although RDM applications can be very useful for dealing with complex problems, they present some chal-
lenges to the enforcement of access control policies. Common approaches to enforce access control policies
give rise to code scattering and code tangling, have difficulties in expressing and enforcing complex access
control constraints that may require a high level of granularity, introduce method dependencies problems, or
lack support for delegation of rights.
In this dissertation, I propose a solution that eases the development task of enforcing access control in
applications, by solving the above problems. This solution is composed of three components: a model which
supports authorizations, amplification of privileges, and delegation of rights; a Domain Specific Language
named Domain Model Authorization Language (DMAPL) with special constructs to allow an easier specifica-
tion of complex access control policies for RDM applications; and a run time engine that enforces the specified
policy during the execution of the application.
Keywords
Access Control
Authorization
Amplification of Privileges
Delegation of Rights
Rich Domain Model Applications
i
ResumoDevido ao aumento do número de funcionalidades, a complexidade das aplicações está constantemente a
aumentar. Para lidar com esta complexidade crescente, os programadores começam a adoptar novas abor-
dagens no desenvolvimento de aplicações. Um exemplo de uma dessas abordagens é o Desenvolvimento
Orientado ao Domínio. Esta filosofia defende que o desenvolvimento de aplicações deve ser centrado nas en-
tidades que compõem o problema a ser resolvido por uma aplicação - o seu domínio. Estas entidades devem
ser estruturadas no que se chama de modelo de domínio. Aplicações de Modelos de Domínio Rico (MDR)
são aplicações que apresentam um modelo de domínio com uma estrutura complexa e com comportamento
rico.
Apesar das aplicações com MDR serem bastante úteis para lidar com problemas complexos, estas apre-
sentam alguns desafios na verificação de políticas de controlo de acesso. Abordagens comuns de controlo
de acesso dão origem a problemas relacionados com a dispersão e mistura de código com objectivos difer-
entes, apresentam limitações a expressar e verificar políticas complexas que podem exigir um alto grau de
granularidade, levam à dependência de métodos, ou não suportam delegação de direitos.
Nesta dissertação, eu proponho uma solução que facilita a tarefa de desenvolvimento de aplicações no
que respeita à verificação de controlo de acesso, ao resolver os problemas acima mencionados. Esta solução
é composta por três componentes: um modelo que suporta autorização, amplificação de privilégios e dele-
gação de direitos; uma linguagem específica de domínio designada Domain Model Authorization Language
(DMAPL) que possui uma sintaxe que permite a especificação de uma política de controlo de acesso de
uma aplicação, de uma forma simples; e um mecanismo de run-time que efectua a verificação da política
especificada durante a execução da aplicação.
Palavras-chave
Controlo de Acesso
Autorização
Amplificação de Privilégios
Delegação de Direitos
Aplicações de Domínio Rico
iii
AcknowledgementsAlthough this dissertation is labeled solely with my name as its author, many other persons have contributed
to it. Without them, I am certain that this dissertation would not be what it turned out to be. For this reason, I
would like to thank them all for their help and support.
The most important person for this dissertation’s completion was, without a doubt, my adviser Professor
João Cachopo. I would like to thank him for all our discussions, and for all his reviews, that made me think
and express myself clearly in this dissertation. The present work owes very much to him.
I would also like to thank to the members of the ESW group of INESC-ID for all the ideas that were
brought into discussion in our meetings. Although all members contribute in a way or another to the concepts
described in this dissertation, I would like to give a special thanks to Professor Dulce Domingues for her
specialized guidance in the access control area. I also want to thank João Pereira for reviewing my dissertation
and wish him the best luck in the continuation of this work.
Some of my course’s colleagues and the members of the RNL team have also contribute with enjoyable
and fruitful discussions that made re-think and deepen on some issues about this dissertation. For all of them
I am grateful.
Finally, although not contributing in a scientific way to this dissertation, the support and encouragement of
my girlfriend Andreia Castro and also of my mother and my father Isabel and António Dumiense, were time
and again indispensable for the realization of this work. For that, and all sort of other things, I thank them.
September 2008,
Gonçalo Mascarenhas Dumiense.
v
Table of Contents
Abstract i
Resumo iii
Acknowledgements v
List of Figures xi
List of Listings xiii
List of Acronyms xv
1 Introduction 1
1.1 Context: Access Control and Rich Domain Models . . . . . . . . . . . . . . . . . . . . . . . . 1
1.1.1 Rich Domain Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.1.2 Access Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Thesis Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 Notation Used . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.4 Outline of the Dissertation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2 State of the Art 5
2.1 Domain Driven Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2 Classic Access Control Works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2.1 The RBAC Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.3 Access Control in Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.4 Policy Specification Languages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3 Problem 13
3.1 Example: The Student Record Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.2 Access Control Code Scattering and Tangling . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.3 Complex Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.4 Methods Dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.5 Delegation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4 Solution Overview 23
4.1 Architecture Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.2 Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.2.1 Why a new access control model? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.2.2 Model Assumptions and Simplifications . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.3 DMAPL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.3.1 Why a new language? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.4 Run-time Engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
vii
4.5 Access Control and the Applications’ Life-cycle . . . . . . . . . . . . . . . . . . . . . . . . . . 28
5 Authorization 31
5.1 Defining authorization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.1.1 Introductory concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.1.2 Authorization Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
5.2 Specifying authorization policies using the DMAPL . . . . . . . . . . . . . . . . . . . . . . . . 34
5.3 Implementing and Enforcing Authorizations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
5.3.1 Run-time model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
5.3.2 Enforcing Authorization Decisions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
6 Amplification of Privileges 49
6.1 An Introductory Metaphor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
6.2 Amplification of Privileges Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
6.2.1 Ticket Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
6.2.2 Amplification Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
6.2.3 Tickets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
6.2.4 Security Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
6.2.5 Decision process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
6.3 Specifying Amplification of Privileges in DMAPL . . . . . . . . . . . . . . . . . . . . . . . . . . 53
6.3.1 Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
6.4 Enforcing and Implementing Amplification of Privileges . . . . . . . . . . . . . . . . . . . . . . 56
6.4.1 Run-time model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
6.4.2 Expansion and Reduction of Rights . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
6.4.3 Deciding Authorization with Tickets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
7 Delegation of Rights 63
7.1 Delegation Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
7.1.1 Delegation Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
7.1.2 Delegated Right . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
7.1.3 Delegating Rights . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
7.2 Specifying a Delegation Policy Using DMAPL . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
7.2.1 Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
7.3 Implementing Delegations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
7.3.1 Run-time model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
7.3.2 Delegating Rights . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
7.3.3 Deciding Authorization with Delegation . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
8 Validation 77
8.1 Case Study: Fénix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
8.1.1 About Fénix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
viii
8.1.2 Fénix’s Current Access Control Mechanisms . . . . . . . . . . . . . . . . . . . . . . . 78
8.1.3 How the work of this dissertation can be used in Fénix . . . . . . . . . . . . . . . . . . 80
9 Conclusion 83
9.1 Main Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
9.2 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
Bibliography 87
ix
List of Figures
2.1 A representation of the core RBAC Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2 A representation of the PBDM Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.1 A class diagram of the domain model for the student record application . . . . . . . . . . . . . 14
4.1 Application Life-cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
5.1 Class diagram of an authorization rule. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.2 Class diagram of the subject concept. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.3 Class diagram of the target concept. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.4 Class diagram of a constraint with examples of possible extensions. . . . . . . . . . . . . . . . 46
6.1 Class diagram of a ticket. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
6.2 Class diagram of an amplification rule. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
6.3 Class diagram of the security context. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
7.1 Class diagram of a delegation rule. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
7.2 Class diagram of a delegated right. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
xi
List of Listings3.1 Access control verification before methods’ invocation. . . . . . . . . . . . . . . . . . . . . . . 15
3.2 Different access control verifications before methods’ invocation. . . . . . . . . . . . . . . . . 16
3.3 Access control verifications inside methods. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.4 A possible implementation for the getAverage method of the Student Record application. . . . 20
5.1 DMAPL’s syntax for policy specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
5.2 DMAPL’s syntax for authorization rules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
5.3 DMAPL’s syntax for declaring subjects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
5.4 DMAPL’s syntax for target declarations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5.5 DMAPL’s syntax for specifying constraints. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
5.6 Cancel courses access specified in DMAPL. . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
5.7 Give grade constraint implemented in DMAPL . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
5.8 Grades access specified in DMAPL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
5.9 A possible approach to the personal data constraint. . . . . . . . . . . . . . . . . . . . . . . . 40
5.10 A more robust version of the personal information constraint. . . . . . . . . . . . . . . . . . . . 41
5.11 AccessControlUser interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.12 AccessControlFinder interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
5.13 Evaluation of constraints using the BeanShell. . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
5.14 Authorization Rules’ isValid predicate. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
5.15 CheckAccess implementation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
6.1 DMAPL’s syntax for ticket declarations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
6.2 DMAPL’s syntax for amplification rules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
6.3 Amplification of privileges specification in DMAPL. . . . . . . . . . . . . . . . . . . . . . . . . 55
6.4 A more specific amplification of privileges for the officer access to students’ average constraint. 56
6.5 Implementation of the expansion of rights operation. . . . . . . . . . . . . . . . . . . . . . . . 60
6.6 Reduction of rights operation implementation. . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
6.7 Check access operation with support for amplification of privileges. . . . . . . . . . . . . . . . 61
7.1 DMAPL’s syntax for delegation rules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
7.2 Teachers’ right to give grades specified in DMAPL. . . . . . . . . . . . . . . . . . . . . . . . . 70
7.3 Teachers’ delegation rule for the give grade right. . . . . . . . . . . . . . . . . . . . . . . . . . 70
7.4 Delegation rule with constraint and validity constraint specified. . . . . . . . . . . . . . . . . . 70
7.5 Predicate isValid for a delegated right. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
7.6 Implementation of the delegation of rights operation. . . . . . . . . . . . . . . . . . . . . . . . 75
7.7 Check access operation with support for amplification of privileges and delegations. . . . . . . 75
xiii
List of AcronymsRDM Rich Domain Model
DSL Domain Specific Language
DMAPL Domain Model Authorization Policy Language
XML eXtensible Markup Language
XACML eXtensible Access Control Markup Language
API Application Programming Interface
xv
1 Introduction
Access control has been vastly studied within the community of security researchers. Many studies have
been made on how to apply access control on numerous fields of computer science: operating and distributed
systems, databases and enterprise applications, work flows and business process modeling, are just some
examples. Due to the difference in nature of all these fields, access control has to be tackled differently from
field to field.
In this dissertation, I study the applicability of access control in the development of rich domain model
applications. The contribution of this work is to present a means that allows a correct and flexible enforcing of
access control policies in this type of applications.
In this chapter, I shall first provide a brief description, in Section 1.1, of the subject of study of this dis-
sertation, defining what I mean by access control and by rich domain models. Next, in Section 1.2 I shall
present the thesis statement of the present work. In Section 1.3 I introduce some notation that is used in this
dissertation. Finally, in Section 1.4, I present the structure of the rest of this dissertation.
1.1 Context: Access Control and Rich Domain Models
To understand the topic of this dissertation fully, two concepts must be discussed beforehand. The first is the
notion of a rich domain model whereas the second is the definition of access control. In this section, I shall
present my point of view of these two concepts.
1.1.1 Rich Domain Models
The development of successful applications is stressed by the increasing demand for more functionality. As
their functionality grows, so does their complexity. Handling the complexity of applications is one of the goals
of many software engineering approaches.
One of those approaches is called domain-driven design, [Evans, 2003]. This approach states that the
development of complex applications should be centered around the entities that compose the problem being
solved by the application - its domain. These entities should be structured in what is called a domain model.
Rich Domain Model (RDM) applications are applications that present a domain model which has both a
complex structure and a rich behavior.
Normally the implementation of an RDM results in a complex web of interconnected objects which com-
prise complex interactions between its elements.
This is what in this dissertation is considered a rich domain model. The study subject of this dissertation
is the enforcement of access control in rich domain model applications, so I shall define the concept of access
control next.
1.1.2 Access Control
Access control is the sub-discipline of computer security that deals with authorization of a certain subject to
access a given resource through a given way.
1
A subject can be defined as the active entity that requests the authorization to access a certain passive
entity, the object. A subject can access the object for different purposes. This purpose is specified by the
access type, which declares the operation that the subject wants the object for, [Gollman, 1998]. In an
operating system, an example of a subject could be either a user or a process, an object could be a file, or a
certain resource, and the access, could be read, write, or execute.
Access control can be seen as a function f that takes a tuple (S UBJECT,OBJECT, ACCES S ) as input
and produces a result of ALLOW or DENY. S UBJECT , OBJECT , and ACCES S refer to a certain subject,
object, and access mode of the set S , O, and A of all the subjects, objects, and access modes of a given
system.
Formally, the access control function f can be defined as:
f : S × O × A 7−→ ALLOW,DENY
f (s, o, a) =
ALLOW, if subject s is authorized to perform a on object o
DENY, if subject s is not authorized to perform a on object o(1.1)
The enforcement of access control policies in rich domain models has its peculiarities, that make it differ
from enforcing access control in a web service, for instance. In this dissertation I shall show in detail these
differences and how they shape the solution for the problem. But first I shall state the thesis of this dissertation.
1.2 Thesis Statement
This dissertation’s thesis is that it is possible to ease developers’ task of enforcing access control in RDM
application with a proper access control system.
This system must satisfy the following requirements:
• Have enough expressive power to support complex access control constraints that can require a high
level of granularity.
• Promote compositionality and reuse.
• Support delegation of rights
• Facilitate the management of the policy, by avoiding code scattering and code tangling.
• Enable the automation of access control’s enforcement related tasks.
To show that such a system can be developed, I present in this dissertation an access control system that
satisfies all these requirements.
This solution is composed by three components: a model, a Domain Specific Language named Domain
Model Authorization Language (DMAPL) with special constructs to allow an easier specification of complex
access control policies for RDM applications, and a run time engine that enforces the specified policy during
the execution of the application.
The main concepts involved in this solution that allow the fulfillment of the above requirements are: autho-
rization, amplification of privileges, and delegation of rights. In this dissertation, I shall define these compo-
nents and show how they manifest themselves in the solution.
2
To validate my solution I provide implementation details and examples of how the components of this
solution can aid in the enforcement of access control in RDM applications. To complement this validation I
also study the applicability of this solution in a real world RDM application.
1.3 Notation Used
Throughout this dissertation I use mathematical notation to formalize some concepts. However I tried to use
widely known symbols with their respective meaning, there were some cases when I did not found a suitable
notation and so I developed my own as I describe next.
I used the following notation to describe a tuple:
a = ( f oo, bar, xpto) (1.2)
This means that a is a tuple with the components f oo, bar, and xpto. a. f oo denotes the component f oo
of tuple a.
An ordered list of elements x1, x2, . . . , xn is denoted:
< x1, x2, . . . , xn > (1.3)
For a given list L, L.last denotes the last element in that list.
1.4 Outline of the Dissertation
This dissertation is divided in nine chapters:
• Introduction. This is the present chapter, in which I introduced the subject of study for this dissertation.
I defined the underlying notions of rich domain models and access control. After this, I stated the thesis
of this dissertation. I also introduce some notation used in the rest of the dissertation.
• State of the Art. In this chapter I cover the literature and work related to the subject of this dissertation.
• Problem Definition. Chapter 3 presents various issues related to the enforcement of access control
in rich domain models. These issues are shown by means of an example. The issues raised by the
example presented are meant to illustrate and define the problem addressed by the present work.
• Solution Overview. Chapter 4 presents a high level description of the proposed solution and states the
motivations and goals behind each one of its components.
• Authorization. In this chapter I describe how the three components of the proposed solution can be
used to express authorization policies.
• Amplification of Privileges. Similarly to Chapter 5, in Chapter 6 I show how the proposed solution
supports amplification of privileges.
• Delegation of Rights. To finish the description of the proposed solution, in Chapter 7 I describe how it
supports delegation of rights.
3
• Validation. In order to validate the applicability of the proposed work, in Chapter 8, I shall present a case
study of a real world application, where I show how my work can enhance the access control support
of that application.
• Conclusion. Finally, in Chapter 9 the main contributions of this dissertation are summarized, and some
directions for future work shall be given.
4
2 State of the Art
When developing a solution for a given problem, it is always important to look for similar problems that may
provide us with the solutions for our problem, or at least give us some clues on how to achieve what we
want. This is the purpose of this chapter: to review the existent literature that is related with the work of this
dissertation, in order to extract some concepts and ideas that can be useful to accomplish my goals.
I do not intend to make an extensive review of all the existent work related to access control or rich domain
model (RDM) applications. There are certainly some works that are also related with this dissertation that
are not mentioned here. Some because the space is limited and were deliberately left out, others because I
simply do not know about them. However, all the works that inspired me and that affected my choices when
designing the solution presented in this dissertation are referred here.
I begin in Section 2.1 with a description of some work related with domain driven design, and how this
approach to software development leads to applications with RDM. Next, in Section 2.2, I present some
classic access control works that layout the base concepts for most of the access control works produced. In
Section 2.3, I discuss some literature that describes various solutions for enforcing access control policies in
applications. Finally, in Section 2.4, I describe some approaches that some authors have made for specifying
domain specific languages (DSL) to deal with access control.
2.1 Domain Driven Design
Applications in general have evolved a long way since their primordial times. In the beginning, programs were
basically developed to perform number crunching. Nowadays, programs have been attributed much more
responsibility. They need to perform tasks based on a much richer representation of the real world.
The object oriented programming paradigm appeared to deal with the increasing complexity on the appli-
cations being developed. It allows to model a given problem easily, and it also promotes reuse and abstraction
[Scott, 2000]. However, the object oriented paradigm by itself is not enough to tackle all the complexity of mod-
ern applications, especially enterprise and web applications.
Over the past two decades, a philosophy has emerged within the object-oriented development community:
the domain-driven design. Eric Evans describes it in great detail in his book [Evans, 2003]. Two premises
of domain-driven design are: (1) for most software projects, the primary focus should be on the domain and
domain logic, and, (2) complex domain designs should be based on a model.
Centering the development around the domain allows the development team to gain knowledge about the
universe of the problem being addressed. From that knowledge the team can distile the more relevant aspects
that will be embedded in the application. Concentrating on domain also promotes a common language for a
software project. It permits efficient communication inside the developers team and between developers and
domain experts.
A domain model can be seen as a set of concepts that translates the abstraction of the underlying reality
of a given problem. In [Fowler et al., 2002], Martin Fowler presents the domain model pattern for implementing
complex business logic in enterprise applications. This pattern suggests the creation of a web of intercon-
nected objects in which the objects represent meaningful entities of the real domain. This object model of
5
the domain should incorporate both behavior and data. There are two kinds of domain models. The first
type are the ones that are very similar to the database schemas, where objects are simple mappings of the
underlying database tables. In the second type, the domain model looks quite different from the database,
taking advantage of all the object oriented paradigm features, like inheritance, design patterns, and complex
webs of interconnected objects. The latter is called a rich domain model and it deals better with complex logic,
although it may be harder to map to a conventional relational database.
In a three-layered architecture that is common in this type of applications, the domain model is part of the
domain layer. To give a domain model a more distinct API, one can use the service layer pattern on top of
the domain model [Fowler et al., 2002]. This service layer functions as a point of invocation of the domain
model and can contain some control features like transactions and security. Generally the service layer is
responsible also for some application logic functionalities that are not domain specific, such as sending emails
when some action is executed. The service layer can be thick or thin depending on the functionality it entails.
With simple domain models, the service layer usually has a lot of functionality, being the main responsible for
the domain logic. By contrast, with rich domain models the service layer should be as thin as possible (only
with application logic) or even inexistent. The main disadvantage of having a service layer is that it introduces
an overhead in the development. If there is a need to extend the application, developers need to extend its
domain model and also the service layer.
In [Cachopo, 2007], Cachopo has made a valuable contribution for easing the development of RDM appli-
cations. In his work, he proposes the use of software transactional memories and a DSL called the Domain
Modeling Language (DML), so that developers can describe the domain entities and the relationships be-
tween them in a declarative way. When used with the Versioned Java Software Transactional Memory, the
DML enables developers to abstract from the relational to objects mapping that is one of the most difficult
parts of RDM development in three layered architectures.
2.2 Classic Access Control Works
As mentioned before in Chapter 1, access control is the sub-discipline of computer security which deals with
the authorization of a certain subject to access a given resource.
In [Hu et al., 2006], access control systems are seen through three abstraction layers: the policies, the
mechanisms, and the models. Policies are high level requirements that specify how the access to resources
are managed, who can access what under given circumstances, and how access decisions are made. Mech-
anisms are a more low level abstraction that implement a given policy. Between policies and mechanisms,
there are the models. Models are theoretical abstractions of the group of mechanisms that form an access
control system. They allow us to study, extract, and prove properties and limitations of those systems. As the
distinction between these concepts is important to better understand access control systems, examples for
each of them are now presented.
As mentioned before, policies are the access control requirements of a given system and deal with the
way authorization is managed within that system. There is a group of well established policies among the
security community. Those policies are:
6
• Discritionary access control policies, or DAC policies, where the owner of a given object decides the
authorization over that object.
• Mandatory access control policies, or MAC policies, where a central authority is responsible for manag-
ing all the authorization on all objects of the system. In this type of policies, the concept of ownership is
not as relevant as it is in DAC.
• Chinese wall policies are policies that deal with conflict of interests, where objects are classified into
classes of conflicting interests. Subjects can only access objects from the same class of interests.
• Role based policies are policies where the authorization is given based on certain roles that the subjects
have within a given system.
• Close or open policies, depending on whether the default action is to deny access or to allow access,
respectively. Close policies are safer, but open policies are more suitable for collaborative work.
• Information flow policies define the flows of information that can exist in a given system.
• History-based policies, in which the authorization decision is made depending on temporal factors and
past actions.
Mechanisms are low level abstractions that implement access control. Examples of the mechanisms
available worth mentioning are:
• Capabilites can be seen as keys, that is, it is something that someone has to use to gain access.
Formally speaking, capabilites are authorization tokens that designate an object and a specific set
of actions that a subject that possesses it is authorized to do over that object. In a capability-based
system, to access an object, the subject must have a capability that permits it, [Dennis and Horn, 1983].
Capabilities allow interesting properties like delegation.
• Access Control Lists are a mechanism for access control in which every object in the system has a list
of access control entries, where is specified what a subject is authorized to do to that object.
• Access Control Matrix is a generalization of the previous two. An Access control matrix is a matrix of
objects and subjects where the cells specify the authorization for a subject to that object. Each column
can be seen as an access control list for an object, while the lines represent the capabilities of each
subject.
• Labels work like tags. Every object has a tag that declares its level of secretism. Access is allowed to
objects only if a given subject has clearance to the level of secretism for which the object is labeled, or
above.
Finally, models are theoretical abstractions of access control systems. There are lots of access control
models. There are, however, a few classic ones which I present here in a summarized way.
• Bell-Lapadula is a model based on a state transition machine of security policies that describes a set of
access control rules which uses the labels mechanisms, [Lapadula et al., 1973].
• Harrison-Ruzzo-Ullman is a model that deals with integrity of access rights in the system, [Harrison
et al., 1976]. It allows policies for changing access rights and rights for the creation and deletion of both
subjects and objects. It is considered one of the most complex security models.
• Take-grant is a very popular graph based model, [Lipton and Snyder, 1977], used mostly on relational
7
databases. A subject can access a given object if there is a path in the model’s graph that takes it to the
object. There are four basic operations: create, creates a path to a new object, take, creates a shortcut
between existing objects, grant creates a path between two existing objects, and remove that deletes a
path.
• RBAC is a widely used model mainly due to its expressive power, scalability and ease of administration.
This model is mostly used for role-based policies but other policies can be enforced as well. In the
RBAC model there are five basic elements: users, roles, objects, operations, and permissions. Users
have roles, which are associated with permissions. Permissions allow or deny certain operations for a
given object. Due to its popularity and its importance, I will go into further details with this model.
2.2.1 The RBAC Model
There have been many attempts to define a role based authorization model, however the establishment of a
standard RBAC model only appeared in 2001. In [Ferraiolo et al., 2001], ideas from previously and frequently
used role based authorization models are unified in order to define the standard RBAC.
The RBAC standard defines the following core components: users, objects, roles, operations, and per-
missions. A user is typically a human being, but it can also be a machine, a network, or an agent, also. A
role represents a certain function within the context of an organization with some semantic association with
authorization. A permission is the representation of the authorization to perform operations among RBAC
protected objects. The operation is something that is executed by the user and that can affect the objects.
Finally, the objects are entities that contain or receive information. There is a relation between user and role,
user assignment (UA), that expresses the attribution of a role to a given user. Roles are associated with per-
missions with a relation of permission assignment (PA). Permissions represent associations between objects
and operations.
Figure 2.1 illustrates the relationships that exist between the core RBAC components. Note that in Fig-
ure 2.1 there is a component named session. This component represents the mapping between a user and
an activated subset of roles that are assigned to the user.
In organizations it is common to have lines of authority and responsibility. For instance, an army’s general
shares common permissions with his soldiers, because he is also a soldier. He can enter the soldier’s bar-
racks, he has permission to fire a weapon, and so on, just like every other soldier. However a soldier cannot
open the general office desk’s drawers, that is a right that only the general has. So, the role of the general
User Role Permission
Operation ObjectSession
1
0..*
userSessions
0..* 0..*UA
0..*
0..*
sessionRoles
0..* 0..*PA
0..*
1..*
allows
0..*
1..*
over
Figure 2.1: A representation of the core RBAC Model
8
contains the same permission as the soldier’s role, but the contrary is not true. These lines of responsibility
and authority can be represented as an hierarchy of roles.
The Hierarchical RBAC model is a model very similar, to the core RBAC model, with the addition of hierar-
chies. A hierarchy of roles can be defined by the inheritance relation among roles: if role r1 as all permissions
of role r2 and all users of r1 are also users of r2, then it is said that r1 inherits r2. So, this model adds another
relation to the previous model, the Role Hierarchy (RH), that is a relation between roles. The compositional
aspect of Hierachical RBAC eases the handling of complexity among roles within an organization.
The RBAC standard also defines a third RBAC model, the Constrained RBAC, that adds separation of
duties to the RBAC model. More details of this model, as well as formal definitions of the models presented
above are available in [Ferraiolo et al., 2001].
2.2.1.1 Delegation in the RBAC Model
Some extensions have been proposed in order to extend the RBAC model. A particular interesting extension
for the purposes of this work is the Permission Based Delegation Model (PBDM) [Zhang et al., 2003]. The
PBDM adds delegation to the standard RBAC model. The main idea of the PBDM is to create one or more
temporary delegation roles and assign permissions or roles to them. So, besides regular roles, the PBDM,
also contains the component of delegation roles, the relation of user assignment delegation (UAD), and the
relation of permission assignment delegation (PAD). Figure 2.2 gives a representation of the PBDM.
Having established the theoretical basis about access control, giving empahsis on the RBAC model, I am
now going to focus on the use of access control on applications’ development.
2.3 Access Control in Applications
After reviewing the more general and classic works in the access control field, I shall now delve deeper for a
more specific topic that relates to access control in applications. By applications I mean Web Applications,
Web Services and the object oriented paradigm in general.
Starting with language support for one of the most popular object oriented languages - Java - the Java
Authentication and Authorization Service (JAAS) [Lai et al., 1999] provides authentication and authorization
features for Java applications. It provides an abstraction layer that simplifies the implementation of authenti-
cation mechanisms in Java programs. As for authorization, JAAS provides components that allow developers
to specify access control rules for sensitive resources within an application in a programmatical way. One of
the flaws that has been referred for JAAS is the lack of dynamic flexibility in applications and the work needed
for configurations, [Oaks, 1998; Zenida et al., 2006].
Another alternative for access control enforcement in Java applications, has been the use of aspect ori-
ented approaches, [Viega et al., 2001]. Aspect oriented programming is a programming paradigm that ex-
plicitly promotes separation of concerns. It allows that the various aspects of an application like persistence
and access control may be defined in an orthogonal manner from the application’s code. For Java, AspectJ,
[Kiczales et al., 2001], is the most popular aspect framework. In [Zhang et al., 2005] the authors propose an
aspect oriented technique for supporting access control in the modeling of Web Applications.
9
User Role Permission
Operation ObjectSession
Delegation
1
0..*
userSessions
0..*
0..*
UAD
0..*
0..*
PAD
0..* 0..*UA
0..*
0..*
sessionRoles
0..* 0..*PA
0..*
1..*
allows
0..*
1..*
over
Figure 2.2: A representation of the PBDM Model
An interesting work that combines both JAAS and aspect oriented approach is the Zás framework, [Zenida
et al., 2006]. Zás aims at resolving the problems of configuration and flexibility of standard JAAS. One notable
aspect of this work is how it handles the need of bypassing access control in object oriented programs. I shall
address this problem later in Chapter 3 and mention the mechanism used by Zás.
An earlier approach for access control in Java applications is described in [Pandey and Hashii, 1999]. In
this paper, authors propose a way to enforce an access control policy in Java by the means of a declarative
policy language and a set of code transformation.
In the field of Web Applications development there are also many works relating to access control. For
instance, in [Bauer et al., 2002], the author proposes a system based on proof-carrying authorizations, i.e.,
the system has an underlying logic which is used to derive proofs in order to make access control decisions.
In [Kojarski and Lorenz, 2003] the authors present the WebJinn, a domain-driven web development frame-
work that aims at resolving the problems of code scattering and tangling. For this, the authors proposed two
models: the XP model that uses extension points to control code tangling, and the DDD model that, using the
XP model aims at resolving the code tangling and scattering problems. Both of these models are specified
using XML.
A very popular framework for Web Application security is the Acegi Security framework, [Acegi, 2008],
that is part of the Spring framework, [Spring, 2008]. In the vast list of Acegi features are notable: the domain
object instance security support, that provides an ACL mechanism for enforcing instance level security; the
after invocation security that allows security to be enforced on objects returned by methods; the flexibility to
secure data at bean level without the need of adding security code to those beans.
Access control is also a very important concern in Web Services. In [Burt et al., 2003] and [Emig et al.,
2007], the authors propose different run-time models that are used to enforce access control in Web Service
environments. In the model proposed in [Emig et al., 2007] the authors aimed at the compositionality and
orchestration of access control policies in Web Services, whereas in [Burt et al., 2003] the goal was to address
issues related with expression of access control requirements in a component environment. For this, the
10
authors proposed a platform independent model that can be used in domain models.
Still in the field of Web Services, [Sterne et al., 1999] presents some interesting concepts to deal with
scalability issues in access control while still providing fine grained decisions. One way to achieve this is to
provide several levels of indirection in authorization policies. For the users it uses the concept of roles already
defined in this chapter. The novelty is a similar approach to methods. In this work the authors define the
concept of type that is a way to group methods with an indirection layer. This way, policies can be defined in
term of roles and types and access control decisions can be made in terms of users and methods in a very
scalable way, i.e., with few access control declarations for complex applications.
Finally, in object oriented databases research, there are also some interesting concepts for access control
for the object-oriented paradigm. One work that I think it is worth mentioning is [Rabitti et al., 1991]. In this
work the author proposes an authorization model for object-oriented databases. A relevant part of this work is
the way the authors approached the need to override previously stated authorization rules in object oriented
systems, as I shall describe in Chapter 3. [Rabitti et al., 1991] introduces the concepts of weak and strong
authorizations to deal with this problem. Weak authorizations can be overridden whereas strong authorization
can never be overridden.
2.4 Policy Specification Languages
Many authors proposed DSL’s for specifying access control policies. The motivations and the concepts in-
volved in each one of them varies and originates different languages.
In [Scott and Sharp, 2002] the authors argue that security is too critical to leave up to individual program-
mers. As so, they propose the development of tools and techniques that remove as many security-related
responsibilities as possible from developers shoulders. One of those proposals is the Security Policy Descrip-
tion Language (SPDL) that is used to specify validation constraints of users input to web applications. This
language can be used to automatically generate the skeleton code that will then serve as the base for the
web applications.
Still in the field of Web Applications, the Software Engineering Research Group of Delft University is
developing a DSL for buidling Web Applications, the WebDSL. One of the problems approached by this
project involves the access control of those applications. So an extension to the WebDSL for specifying
access control in Web Applications, in a declarative way is described in [Groenewegen and Visser, 2008].
With this extension it is possible to declare which rules should be verified before each execution of an action
in a Web Application declared using the WebDSL.
With a different purpose from the above mentioned languages, the SPL, [da Cruz Ribeiro et al., 2001], is
a language that aims at expressing complex security policies of organizations within a single description. This
permits that there is only one policy specification over the whole organization. The SPL is able to express
concepts of permission and prohibition and also some forms of obligation. One of the goals of the SPL is
to address the problem of conflicting policies. It does this by using a tree structure in which the policy is
organized and that is inherently free of conflicts by using the AND and OR operators.
The OASIS standards organization introduced the eXtensible Access Control Markup Language (XACML),
11
[Moses, 2003], which is an XML based language to define access control policies. By having XML tags as
the basis of this language, it provides an extremely flexible language for expressing access control policies
that depend virtually on any sort of information for taking its decision. XACML enables the use of arbitrary
attributes in policies, role-based access control, security labels, time/date-based policies, indexable policies,
"deny" policies, and dynamic policies – all without requiring changes to the applications that use XACML.
A more general purpose language, but that has a strong security foundation, is the E programming lan-
guage, [Miller, 2006]. E is an objected-oriented programming language with secure distributed computing in
mind. The E language and its standard library employ a capability-based design philosophy in order to help
programmers build secure software and to enable software components to co-operate even if they don not
fully trust each other. In E, object references serve as capabilities, hence capabilities add no computational or
conceptual overhead costs. The language syntax is designed to be easy for people to audit for security flaws.
For more information on E and on the object-capability concept please refer to [Miller et al., 2003].
Finally, the Ponder language, [Damianou et al., 2001], provides a common means of specifying security
policies that can be mapped to various platforms like firewalls, operating systems, databases or Java. It
supports four different type of policies:
• Authorization: Authorization policies define what activities subjects can perform on a set of objects.
There are positive and negative authorization rules, being the first ones to express authorization and
the latter prohibition. Authorization rules can also be used to filter the results of a given action.
• Refrain: Refrain policies define the actions that subjects must not perform on target objects. This
type of policy is used when negative authorization rules are inappropriate when the objects cannot be
protected, and so, refrain policies are enforced by the subjects.
• Obligation: The purpose of this policy is to specify what subjects are obliged to do when certain events
are triggered.
• Delegation: This type of policy is used to control how rights can be delegated between subjects. Ponder
addresses the problem of cascade delegation of rights by requiring the specification of the maximum
number of cascading delegation allowed. Again, delegation rules can also be positive or negative,
where the first declare the right to delegate and the latter the prohibition to do it.
Besides these basic policies, Ponder allows the composition of policies in groups, roles, relationships and
management structures.
Ponder also presents an object model to represent a specified policy during run time and, this way, support
and enforce the policy in the desired targets, [Dulay et al., 2001]
12
3 ProblemAs mentioned before in Chapter 1, RDM applications have specific requirements for an effective enforcement
of access control. In this section, I shall show some of these requirements with the help of an example and
aim at the definition of the problem underlying this dissertation.
In Section 3.1, I shall present an example that will serve to illustrate in this chapter, as well as throughout
the remainder of this dissertation, some of the problems of enforcing access control policies in RDM applica-
tions. Next, in Section 3.2 I present one of those problems that is related to access control code scattering
and tangling within the application. As it was also mentioned in Chapter 1, describing how to enforce complex
constraints is one of the objectives of this dissertation. So, in Section 3.3, I shall show why some constraints
can be so problematic. Section 3.4 introduces a problem that is typical in object oriented applications, and
consequently in rich domain model applications, that is the dependency between methods in an object ori-
ented application. Finally in Section 3.5, I shall define the problem of delegation and the requirements it poses
to the development of an access control system.
3.1 Example: The Student Record Application
To expose some of the issues approached by this dissertation more clearly, I shall introduce a simple, yet,
rich example. This example and the problems it poses are based on a real RDM application that is deployed
and running at the time of writing of this dissertation. This application is called Fénix and I shall describe it in
detail in Chapter 8.
The domain of this example is a university’s student record. The application considered for this domain
allows the editing of a student’s grade record in a university. The main functionalities of this application are:
• Retrieve information from a student’s record
• Add grades to students’ records
• Discard grades from students’ records, when they wish to cancel a course.
Let us consider that a student record is composed by personal information about the student, plus his
academic curriculum, which is composed by all the courses’ grades that the student attended during his
degree and that he did not cancel. Every course has a grade. Another relevant part of a student’s record is
his average.
Apart from students, there are also teachers and administrative officers that are responsible for the ma-
nipulation of students’ records. Teachers and officers also have personal information.
A possible domain model for this application is depicted in Figure 3.1.
To use the system, a user must authenticate through an authentication mechanism that is considered
secure. This authentication mechanism creates an object of the type User in the application session that is
associated with the person who is authenticating in the system. An instance of the class user is associated
with one or more roles. The role assignment is also done through the authentication mechanism.
To ensure confidentiality and integrity of the students’ record data, some authorization constraints must
be defined. For this example, let us consider the following:
1. A student can see his own grades, but cannot see other students’ grades.
13
studentNumber: int
getAverage()
giveGrade()
cancelCourse()
Student
officerNumber: int
Officer
teacherNumber: int
Teacher
idNumber: Integer
name: String
getIdNumber()
Person
userName: String
User
roleName: String
Role
grade: int
Grade
courseName: String
Course
person 1
user 1
authenticated as
person 0..1
student
1
is
person 0..1
officer 1
is
person 0..1
teacher
1
is
grades 1
student 0..*
has
course
0..*
grades
1has
courses 1..*
teachers 0..*
teaches
roles
0..*
users
1..*has
Figure 3.1: A class diagram of the domain model for the student record application
14
2. Teachers can see all their students’ grades.
3. Officers may see student’s average, but they cannot see the specific grades of a student.
4. The personal data is private to each person.
5. Teachers can give grades only if they teach the corresponding course.
6. Only officers can cancel courses.
7. Teachers can delegate the responsibility of giving grades to officers.
For simplicity, let us assume also that a completed course for a student is one for which a teacher has
already given a grade. In a similar way, canceling a course is equivalent to removing a grade from a student.
Now that the example has been exposed, I shall address the problems related to access control in this
example.
3.2 Access Control Code Scattering and Tangling
The first problems that I shall explain are related to code scattering and tangling. These problems have been
addressed by other authors like [Kojarski and Lorenz, 2003]. The code scattering refers to problems related to
code of a specific concern of an application, like access control, transactionality, or persistence, that becomes
scattered through all the application, making it hard to manage the correspondent concern. The code tangling
refers to the problem that arises when code from these type of concerns, that are orthogonal to the application
logic, become embedded in that logic creating a dependency between the code of the logic and that concern.
I shall now present examples of these problems.
In normal, three-layered enterprise applications, the presentation layer invokes operations from the domain
layer. A natural way to place the access control verifications would be between the presentation and domain
layer. This way, before an invocation of a protected operation, a developer would place the access control
verification. Listing 3.1 exemplifies this approach.
For this example, as well as the following, consider that the operation user_has_access? denotes the
necessary operations needed to compute if a user really has access to perform the following actions.
This coarse grained approach to access control is good when applications’ requirements can be nicely
mapped into use cases performed by the presentation layer. Besides that, this approach permits the grouping
of access control verifications by operations, which could lead to better performance, than if we had one
DomainObject o = DomainLayer.getObject();
if(user_has_access?)
o.doSomething();
o.doSomethingElse();
else
throw new AccessControlException();
Listing 3.1: Access control verification before methods’ invocation.
15
verification by operation.
However, when the protected operations have different rules for granting access to their execution, this
approach leads to an explosion of access control verifications. Consider Listing 3.2, where doSomething and
doSomethingElse have different access control rules that allow its execution.
As the access control requirements for executing doSomething and doSomethingElse can be different I
signaled that difference with the _2 suffix in the name of the user_has_access? operation.
As it is shown by the example, now every protected method execution has to be preceded by an access
control verification. This brings two disadvantages: 1) access control code begins to pop up within the domain
logic (code tangling), and 2) if the same method is invoked in two different parts of the application, the access
control code is repeated (leading to code scattering). So, it is clear that this type of approach is not much
useful when dealing with growing complexity because it does not allow developers to reuse code.
A different approach would be to place the access control verification inside each operation. This brings
the advantage of promoting encapsulation by making the verification a responsibility of each operation. Con-
sider Listing 3.3. With that approach access control verifications are encapsulated within each method pro-
moting reuse in the invocation of such methods. However equal verifications would still be duplicated between
methods. Again, with this approach, access control code is still scattered and tangled with other application
concerns.
A service layer that invoked services, which would be filtered using the Intercepting Filter Pattern, [Luiz
et al., 2004], could be implemented in order to gather all the access control verifications in filters, avoiding
this code scattering. However this approach has two problems: first, it would shape the application into a
service oriented application as opposed to the rich domain model (RDM) application, which besides other
advantages, allows to tackle complexity better, and, second, the implementation of access control verification
with filters would not provide the necessary granularity needed to express and enforce complex constraints,
as I shall show next.
DomainObject o = DomainLayer.getObject();
if(!user_has_access?)
throw new AccessControlException();
o.doSomething();
if(!user_has_access_2?)
throw new AccessControlException()
o.doSomethingElse();
Listing 3.2: Different access control verifications before methods’ invocation.
16
class C extends DomainObject
...
void doSomething() throws AccessControlException
if(user_has_access?)
throw new AccessControlException();
/* Do logic */
void doSomethingElse() throws AccessControlException
if(!user_has_access_2?)
throw new AccessControlException();
/* Do logic */
Listing 3.3: Access control verifications inside methods.
3.3 Complex Constraints
The access control function presented in Chapter 1:
f (s, o, a) =
ALLOW, if subject s is authorized to perform a on object o
DENY, if subject s is not authorized to perform a on object o
shows that in order to enforce an access control policy, function f needs three arguments: a subject, an
object, and an access control type. So, one of the first things that needs to be addressed when enforcing
some kind of access control is to define what their subjects, objects, and access types are going to be.
A natural approach to define an access control system that uses the object oriented paradigm, would be to
consider each class a different object, and each method a different access control type. This way, an access
control verification would take the tuple (S UBJECT,CLAS S ,MET HOD) and if S UBJECT was allowed to
perform MET HOD of CLAS S , then the access would be granted. Several authors like [Rabitti et al., 1991]
use this type of definition.
As it was referred in Chapter 2, role based access control is very useful when dealing with roles that
subjects can have within an organization. As such, consider that each S UBJECT has one or more roles.
Now, consider the constraint 6 of the Student Record Application: Only officers can cancel courses. With
the access control model suggested above, the following formulation expresses this constraint:
f (s, S tudent, cancelCourse) =
ALLOW, if s has role OFFICER
DENY, otherwise(3.1)
This model is good enough to express this type of constraints where the decision of whether or not the
access should be granted is based solely on the role that a user possesses and the type of action it needs to
perform over an object.
17
However, if more granularity is needed to express more complex constraints, this is not enough. Consider
for instance constraint 1: A student can see his own grades, but cannot see other students’ grades. In this
case, following the same logic as in Equation (3.1), the following formulation is obtained:
f (s, S tudent, getGrade) =
ALLOW, if s has role S TUDENT
DENY, otherwise(3.2)
With this formulation, what is being expressed is that if a given subject s has the role S TUDENT , then
it can perform the getGrade operation, over any object of the class Student. In this case it is not enough
to know if the subject has the role S TUDENT or not. It is needed to perform the verification at the objects’
instance level. So the tuple (S UBJECT,CLAS S ,MET HOD) is not enough. In some way, the access control
decision must depend on the receiver of MET HOD. A possible approach would be like the one that is shown
in the following formulation:
f (s, S tudent, getGrade, i) =
ALLOW, if s has role S TUDENT ∧ s ≡ i
DENY, otherwise(3.3)
where the set i denotes an object instance of the application, and the operation ≡ expresses that the
objects denoted by its arguments, must correspond to the same instance.
Note that, due to the large number of object instances in a RDM application, specifying explicitly all the
object’s instances that a subject can access, besides being impractical, is impossible to do statically. The
importance of statically specifying these object’s instances is that it is needed to state the policy before the
application is running, and not the other way around, running the application and then selecting the instances.
So, a way to statically reason about object instances in an access control decision must be present in an
access control system for rich domain models.
Another important aspect is the relationship between the object’s instances of the model. Consider con-
straint 2: Teachers can see all their students’ grades. In this constraint, the comparison of equality between
object instances is not enough, because we need a way to verify if the subject is the teacher of that object’s
instance, i.e., if there is a relationship of teaches between the subject and the object.
A possible way to deal with these problems is to introduce the concept of access control predicates. In
order to allow expressive predicates, these should take the subject and a list of object instances as arguments
and evaluate the result, based on these arguments.
However, as it happened with object instances, if the predicates are not expressive enough, or do not
promote reuse, the number of predicates needed in an RDM can be extremely large, hence difficulting the
manageability of the global access control policy.
Finally, there is one last constraint exemplified in the Student Record application that is peculiar by itself.
The constraint in question is the constraint 4: The personal data is private to each person. The property of
a method of being a method that retrieves personal data can be common to many methods. For instance,
the idNumber of a person is something personal, so the method getIdNumber should be considered by this
constraint. However, a grade can also be seen as something that is personal to a student. So, the method
getGrades is also a method that should be considered by this constraint.
18
Thus, an access control system for RDM applications should support this type of method classification, to
simplify the manageability of the global policy by reducing the number of rules needed to express the access
control constraints.
3.4 Methods Dependencies
A typical situation that occurs when enforcing access control in object oriented applications is when a given
method calls another method that has access control constraints attached to it.
For instance, consider the constraint 3: Officers may see student’s average, but they cannot see the
specific grades of a student, and the specification for the class Student in Listing 3.4.
In this example, the method getAverage depends of the method getGrades, because it needs this latter
method’s result in order to perform its own computation. The method getAverage can be accessed by
officers. However, for the method getGrades a user must be either a student or a teacher in order to execute
it. A problem arises when deciding what should the access control decision be for the method getAverage
and for the getGrades method.
In order to better explain this problem I shall provide an abstract formulation for this problem. Consider
two methods m1 and m2, and a user u. Method m1 invokes m2. User u does not have permission to access m2
but it has permission to access m1. How should the access control decision go in this situation?
There are two possible semantics, both valid for addressing this problem. The first one is to assume
that as user u does not have enough privileges to complete the operations that m1 comprises, access to m1
should be denied. The other is to assume that the access control constraints attached to method m2 can be
temporarily overridden, to allow the completion of the execution of method m1.
Although the first semantics can be considered more secure, it does not support the necessary flexibility
needed in RDM applications, because new methods cannot be added without reviewing lower layer methods’
constraints. This way, the lower layer methods would dictate the global policy. Even in the most complex RDM
applications, there can be cases where this is the needed semantics. However, it is very complex to manage
an RDM policy just this way.
The second semantics must rely on some sort of mechanism that allows the policy to be temporarily
ignored. Although it can be considered less secure, it is much more flexible. This type of solution is well
studied in computer security, by the name of amplification of privileges, and is widely used in current computer
systems.
There are three possible approaches for addressing the method dependency problem with amplification
of privileges:
• If user u has been given access to method m1, then it should also be given, automatically, access to the
methods that m1 execution comprises. This is the approach used by ZÁS [Zenida et al., 2006]. However,
this approach suffers from being too permissive and for not allowing the amplification of privileges to be
done in a controlled way. For instance, if, by mistake, a third method m3 is invoked in the method body
of m1, then m3 is going to be automatically invoked without any access control constraint verification,
because user u was also given automatically access to all methods that m1 needed during its execution.
19
class Student extends DomainObject
HashSet<Grade> grades;
...
public double getAverage()
if(getGradeCount() == 0)
return 0;
double average = 0;
for(Grade grade : this.getGrades())
average += grade.getGrade();
return average /= getGradeCount();
public Set<Grade> getGrades()
/* Only students and teachers can access */
return this.grades;
Listing 3.4: A possible implementation for the getAverage method of the Student Record application.
• Another approach is to explicitly specify through what methods can a method be invoked. For instance,
besides the constraint of method m2 another constraint would be added in which it was stated that if
the invocation was started from method m1, then the access would be granted. This approach has the
advantage that it is explicitly stated which access control verifications can be overridden. However, it
suffers from not being compositional because the addition of new methods imply the revision of lower
layer methods, difficulting a compositional development.
• A final approach consists in declaring in method m1 which access control verifications should be over-
ridden in order for it to complete its execution. This way, it is possible to develop a fourth method m4
that depends on method m1 (i.e., it invokes m1), without having to review m1 or m2 access control con-
straints. This happens because, each method is responsible for overriding its specific access control
verifications. Besides that, by explicitly stating which constraints should be overridden, it mitigates the
problem of the first approach: granting access to a method by accident.
The last approach is the most suitable for RDM applications due to its compositional characteristics.
Thus, an access control system for this type of applications should provide a mechanism that allows these
compositional amplification of privileges’ semantics.
3.5 Delegation
Often, delegation of rights is a requirement for RDM applications, because it provides the application with a
flexibility that the user of the application possesses when performing his real life tasks outside of the applica-
20
tion. In cases where delegation of rights is not supported by the application, users try to force this flexibility
by sharing passwords or authentication credentials that is by itself a very serious security problem.
The delegation of rights from one subject to another has two components: a static, and a run-time one.
The static component of delegation in an access control system expresses the rules that control the delegation
flow. In other words, it defines what can be delegated from who to whom under what circumstances, and for
how long. This component however, is not enough by itself. The actual delegation only occurs when a subject
delegates the right to do something, to another subject, which only happens during run time.
Due to this run time nature of delegation, in order for a system to support delegation it must allow its
representation of the access control policy to change in run time. A delegation of a right is nothing more than
saying that the user that is granted the right, now has the right to do something else that was not able to do in
the first place. This is why, delegation comprises the alteration of the policy representation in run time.
This run time requirement render many traditional approaches to access control in applications useless,
because most of them use as a base for their policy representation static development artifacts, like source
code. Using static development artifacts for implementing access control provides the flexibility and expres-
siveness that is needed for many access control constraints. However it does not allow that application to
easily support delegation of rights.
Other issues arise when dealing with delegation of rights, when those rights are defined by means of
predicates. As I shown in Section 3.3, these predicates are needed in order to express complex access
control constraints in rich domain applications. However, this approach difficults the task of delegation.
Consider, for instance, constraint 7 of the Student Record application: teachers can delegate the respon-
sibility of giving grades to officers. When a teacher delegates the right to give grades to an officer, it should
delegate exactly the right that she has, nothing more and nothing less. So, as a teacher can give grades only
to courses she teaches, when she delegates that right to an officer, the officer can give grades only to the
courses that she was a teacher of.
The precision of this constraint is hard to accomplish when the right is delegated, because if the access
control decision depended on a predicate that tested the teaches relationship of the subject, this predicate
will never be true for an officer. For this reason the process for evaluating predicates should be different for
delegations.
The run time entity that supports delegation should have the flexibility needed to ensure the policy’s modifi-
cations and the proper evaluation of predicates. These are the main challenges when dealing with delegation
of rights in RDM applications.
21
4 Solution Overview
In Chapter 3 I defined the problem that access control enforcement poses in RDM applications. Namely I
discussed the problems related with code scattering and code tangling, complex constraints, method depen-
dencies, and delegation of rights. In this chapter, and in the rest of this dissertation, I shall introduce a solution
to those problems. That solution consists in a mix of a new access control model, a Domain Specific Lan-
guage (DSL) named Domain Model Authorization Policy Language (DMAPL), and an access control engine,
all tailored specifically for RDM applications.
In this chapter, I shall explain the overall architecture of the solution, and go into detail on why I believe
that this solution is appropriate for RDM applications. In Section 4.1, I shall discuss the top level architecture
of the solution presented. Then, I shall describe the solution’s components. In Section 4.2, I motivate the
need of a new access control model and discuss some specific assumptions and simplifications that can be
done when developing an access control model for RDM applications. Next, in Section 4.3, I motivate the
need of a DSL to describe access control features of an application and state the principal objectives that I
try to accomplish with the creation of this language. Section 4.4, presents the properties and goals I want to
achieve with the run-time engine. Finally, in Section 4.5, I explain how the whole solution fits in the application
life-cycle, and explain how it aids in the development of an RDM application.
4.1 Architecture Overview
The problems described in Chapter 3 are very different in nature. For instance, the problem of code scattering
and code tangling is a programming related problem, whereas the complex constraints problem deals with the
expressiveness of an underlying access control model. The solution that I propose in this dissertation has to
tackle these different types of problems, so it consists in three distinct parts: an access control model, a DSL,
and a run-time engine for computing access control decisions during the execution of an RDM application.
The access control model gives developers an abstract framework with which they can conceive and
reason about an access control policy. Problems posed by expressiveness issues when dealing with complex
constraints should be addressed by this model. Apart from that, the model supports the features needed to
deal with the requisites of RDM applications, like delegation and amplification of privileges.
The DMAPL provides a way to aid in the task of specifying and maintaining an auditable access control
policy, based on the access control model. This DSL has the same expressiveness of the model when dealing
with complex constraints.
With the policy expressed in a formal language, specifically tailored to the domain of RDM applications,
developers can use and create tools that automate most of the work involved with the enforcement of the
policy in the application. One of this tasks is the placement of the access control verifications, within the code
of the application, through code injection, which can be automatically done. For all this, the DMAPL aids in
the mitigation of the code scattering and tangling problem.
In order to support some run-time features, as delegations and amplifications of privileges, these verifica-
tions cannot be static. They should consist on the invocation of some run-time entity that keeps track of the
global state of the policy. This is where the third part of the solution enters, the engine. The engine is the
23
run-time entity responsible for the enforcement of the policy described with the DMAPL. For that, the engine
loads the policy and creates a run-time representation of that policy, using the model’s concepts.
These are the three components that make the high level architecture of the solution proposed in this
dissertation. I shall now explain the reasons and goals that motivate each individual part of this solution.
4.2 Model
4.2.1 Why a new access control model?
As defined in Chapter 1, a model is a theoretical abstraction of mechanisms that form an access control
system. Many authors have made valuable contributions, by proposing access control models that can deal
with various access control problems, like the RBAC model [Ferraiolo et al., 2001] or the Harrison-Ruzzo-
Ullman [Harrison et al., 1976].
However, to the extent of my knowledge, there is not a work that addresses the problem of how to enforce
an access control policy on complex applications, from a software engineering perspective. That is, how
can developers reason, specify, and enforce an access policy while developing an application, without that
interfering with the development of the core features of that application. Although there are some development
frameworks based on theoretical works that come close to this objective, none of them, that I am aware, are
tailored for an RDM, where there is the need to handle very complex business logic, and on which, it is
foreseeable that the access control constraints have the peculiarities described in Chapter 3.
This is why I opted to develop a new access control model on which I could incorporate the concepts that
I identified as needed when dealing with enforcing access control in an RDM.
Note that, although some principles of the model could be used in other areas different from the RDM
applications, my main objective when developing this model was to make it fit to these kind of applications,
in detriment of supporting any other areas. One design feature that exemplifies this, is, for instance, the fact
that the resources this model is conceived to protect are specifically the execution of methods in an RDM,
as I shall explain ahead. Possibly, the model could be used to protect system calls in an operating system,
or execution of queries in a database system, however that is not the scope of this dissertation nor the main
goal that guided the development of the model.
The goals that I was pursuing when developing this model were:
• Expressiveness: One of the problem introduced in Chapter 3 was the need of correctly expressing and
enforcing complex constraints. With this model, I want to address that problem by giving it enough
expressive power to cover constraints with various degrees of granularity. Apart from the granularity
issue, I also want the model to be expressive enough to express constraints that can be verified only in
run-time (e.g.: if a given object instance has a given property).
• Compositionality: A constant problem that RDM developers face is the ever growing complexity of an
application. One way to deal with this problem is to make the applications composable, i.e., allow future
features of the application to use already developed ones. This way, the application can grow without
the effort of repetitive tasks. In order to enforce an access control policy in an RDM application, the
same principle should be followed. This is why I want the model to be composable, i.e., that access
24
control rules do not have to be repeated in order to support a different application feature, and can rely
on already defined rules.
• Delegation of rights: As mentioned before, delegation is a desired feature in RDM applications, which
many times cannot be easily developed due to limitations of the access control system used. By sup-
porting the delegation of rights in the model, I aim to make this feature easy to implement.
• Uniformization: There is a number of concepts and features scattered through different access control
models that are useful in RDM applications, such as the notion of roles, amplification of privileges, or
delegation of rights. To facilitate the task of developers, I just want to use one model that incorporates
all the needed concepts.
Having defined the motivation and goals of the model, I shall now introduce a bit more of the model, by
stating its assumptions and simplifications.
4.2.2 Model Assumptions and Simplifications
Due to the specificities of RDM applications and the goals of the desired model, some assumptions and
simplifications can be drawn in order to guide the development of such model.
Assumption 1 The intent of this model is not to be developer proof, i.e., the model is not designed for taking
into account bad intentioned developers which try to subvert the system. Those type of programmers could
subvert the system whenever they wanted, because they are developing that same application and can make
it do whatever they want. What I want, however, is that the concepts provided by the model help programmers
avoid accidental errors in the design of an access control policy.
Assumption 2 RDM development uses many of the concepts of the object oriented programming paradigm.
One such concept is encapsulation which states that the access to any attribute of an object, should be done
by the methods of that object. For this reason, any read or write of an object state should have a correspondent
method. So, I consider that in an RDM resources that require access control are solely the execution of its
methods.
Thus, the concept of resource on the proposed model corresponds to the concept of the execution of a
method invoked by a given user, on a receiver object, and with determined arguments.
Assumption 3 In an RDM, many times the operations needed to perform an access control verifications are
also used on other contexts of the application. For this reason, I do not intend to provide a way in the model
to create this type of operations, as I assume that these operations should be in the domain’s logic. If they
are not present in the RDM, then they can be added, because they could be later re-used on other parts of
the application.
4.3 DMAPL
An access control model provides the abstract concepts with which access control policies can be conceived
on a mental level. In order to implement that policy on a real application, the policy has to be specified on
some formal language that can be either the correspondent programming language on which the application
25
is being developed, or a DSL. For the proposed solution, I opted for the latter, and created a declarative
language that I named: Domain Model Authorization Policy Language, or DMAPL for short.
4.3.1 Why a new language?
As mentioned before, when it comes down to specifying and implementing an access control policy in an
application, developers have to rely on the constructions provided by mainstream programming languages.
For simple applications, most of the times, that is enough. However, when dealing with RDM applications, that
is definetly not enough, due to the high degree of complexity that these applications reach. Also, by relying
on mainstream programming languages’ constructs, the access control policy becomes scattered through all
the application and tangled within the business logic code of the application, leading to the code scattering
and code tangling problem mentioned in Chapter 3.
For these reasons, when conceiving the proposed solution, I chose to provide developers with a DSL with
which they could express an access control policy. This DSL has specially designed constructs that fit the
mental model that developers use to reason about that policy.
Introducing a DSL for the specification of a policy also brings additional advantages. By having a devel-
opment artifact solely dedicated to the specification of the access control policy, different from the one used
to specify business logic, avoids the problem of code scattering and tangling. The existence of a formal lan-
guage in which the access control policy is specified allows the development of tools that can automate tasks
that, otherwise, would have to be performed by developers. This way, not only it accelerates the development
process, as it also makes the whole process less error prone.
These were the main motivations for the creation of the DMAPL. From them, I drew the following goals:
• Expressiveness: The DMAPL should have the same expressive power of the proposed model. This
means that the language must support the specification of all the concepts of the model, such as
amplification of privileges and delegations.
• Compositionality: Like it happened with the model, one of the main drivers in the creation of the DMAPL
is to allow developers to handle the complexity that an RDM application may present. In order to do this,
the specification of an access control policy with the DMAPL should follow the compositionality principle
by allowing new additions to the policy to be specified in terms of already existing items in the policy.
• Human Readable: There are many application development frameworks that provide a tag-based lan-
guage, like XML, to allow developers to specify the application’s access control policy. Despite of allow-
ing an easy development of tools, tag-based languages difficult the task of reviewing the specified policy
by humans, and can be error prone. This is why I want the DMAPL to be a human readable language,
that can be easily understood by humans in order to reduce specification errors, and facilitate the task
of reviewing.
• Enable automation: Although favoring humans over machines, I also want the language to enable the
development of tools that automate some tasks. One of these tasks is the placement of access control
verifications in the application code, although other tasks can be possible to automate also like the
verification of policy properties, for instance. To accomplish this, the language has to have a formal
grammar.
26
To finalize the motivations behind the creation of the DMAPL, I want to add that the existence of such a
DSL, also enables a separation of concerns between the development of the application logic and the access
control policy. This facilitates the existence of a development team’s member that is responsible only for the
development of the access control policy. Besides the clear accountability advantage, this approach allows
that a sensible aspect, such as access control, can be handled by a dedicated expert, instead of application’s
logic developers. Note that, despite the fact that it enables such team structure, it does not forbids more agile
teams, where developers are responsible for all areas of the application development.
4.4 Run-time Engine
The last part of the solution is the run-time engine, which is responsible for performing access control decision
proccess during the application’s execution, based on a policy specified with the DMAPL.
The motivations behind the creation of this engine are directly related to the goals I want it to accomplish,
which are:
• Run-time realization of the model: The engine main purpose is to provide a run-time representation of
the concepts of the model, in order to enable the enforcement of policies described in terms of those
concepts. So, for every concept described in the model, the engine should provide a correspondent
run-time representation. This representation should then be populated in run-time taking the policy
described with the DMAPL as input. The achievement of this goal allows the accomplishment of the two
following goals.
• Dynamism: Having run-time entities that describe a policy, allows the policy to change dynamically
during the execution of the program. This has two advantages: 1) it allows to support the dynamic
aspects of an access control policy like delegation, and 2) it allows a policy to be replaced by a new one,
without having to rebuild all the application, and possibly even during the execution of the application,
which enables, in critical situations, corrections to the policy to be made on the fly. The proposed engine
should support this feature.
• Modular verifications: With the representation of policy elements in run-time, the access control verifi-
cations can be reduced to the invocation of a method that queries that representation in order to see if
the access is to be granted or denied. This way it is possible to vary the implementation of the access
control verifications without altering anything else.
When developing the engine, I made it for Java applications only. Whereas this is not a goal, nor a limitation
of the solution, I made this decision for two reasons: 1) because Java is a general purpose programming
language that was developed around the object oriented paradigm, which, as stated previously, is a common
paradigm for creating RDM applications; and 2) because between other existing mainstream object oriented
languages, Java is very popular in the development of enterprise applications, which are the applications that
due to their complexity are good candidates to be RDM applications.
For these reasons, all the implementation details given in this dissertation are shown in the Java program-
ming language. Note, however, that implementations in other mainstream languages are possible, although
not covered in the present work.
27
4.5 Access Control and the Applications’ Life-cycle
As mentioned before, the proposed solution has to be tailored to RDMs’ development. This three-component
architecture permits the solution to fit an RDM application life-cycle.
Every application life-cycle, no matter what methodology is used, has four distinct phases: requirements’
specifications, development, testing, and maintenance. From an access control perspective, the proposed
solution provides aids in each one of them:
• Requirements’ specifications: In the first phase of an application life-cycle, besides the features that the
application needs to have, the qualities that the application should present are also considered. Access
control, fits in this latter type of requirements. The model provides a mental framework in which the
stakeholders can reason and discuss these requirements in an objective and precise way.
• Development : After the access control requisites have been established, an access control policy can
be derived. The DMAPL provides developers with a language that can be used to specify that policy,
without interfering with other application code. Then, by using the DMAPL compiler and the engine’s
API, developers can automatically enforce the specified policy in the application, with little effort, and
with low margins for errors.
• Testing and maintenance: By having the access control policy specified declaratively in only one place
- the DMAPL specification - this solution aids in the testing and maintenance of the access control
requisites of the applications. The uniform and formal specification of the policy, using the DMAPL,
enables the development of tools that can perform automatic testing of certain conditions of the policy.
Apart from that, by having the access control policy specified in only one place, facilitates its auditability.
Figure 4.1 summarizes how the solution helps developers in the various phases of the applications’ life-
cycle.
Now that I have laid out the solution from a high level perspective, introducing the motivations, assump-
tions, and goals behind its main components, I shall describe those components in detail: I shall define the
model, describe the syntax and semantics of the DMAPL, and provide implementation details of the engine.
In the next three chapters of this dissertation, I do this by approaching each component from the model’s
concepts perspective: authorizations, amplification of privileges, and delegation.
So, in each of the following three chapters, I follow the following structure:
• Model: In this section, I define the correspondent concept based on an abstract model.
• DMAPL : Having defined the concept, I show how to specify that concept in a formal policy using the
DMAPL language.
• Engine: Finally, I present implementation details on how the engine supports the correspondent con-
cept.
28
Requirements’
Specifications
DevelopmentMaintenance
Testing
Model Concepts
DMAPL
Verification Injection
Automation Tools
Auditable Policy
Automation Tools
Figure 4.1: Application Life-cycle
29
5 AuthorizationA basilar concept of any access control policy is without a doubt, the notion of authorization. Generaly
speaking, authorization defines which subjects have access to given resources when certain circumstances
are met. This is the topic of discussion of this chapter, where I describe what authorization represents in the
proposed solution.
For that, in Section 5.1, I formally define the notion of authorization by starting to expose the proposed
model. Next, in Section 5.2, I introduce the DMAPL language constructions that are used to specify an
authorization policy. In this section I also show some examples of usage of the DMAPL to specify the con-
straints introduced by the Student Record application in Chapter 3. Finally, in Section 5.3, I discuss some
implementation details of the proposed engine to handle the concept of authorization rules.
5.1 Defining authorization
In order to establish an abstract framework, I first have to define some notions that are orthogonal to all the
concepts in the model. I shall introduce them in the following subsection.
5.1.1 Introductory concepts
The object of study of this dissertation are RDM applications. Although a definition of RDM was given in
Chapter 1, for the purpose of defining an abstract model, I shall now give an abstract definition of this concept.
An RDM application APP is a tuple:
APP = (U,O,M) (5.1)
where U is a set of users of the application APP, O is the set of objects that exist during the execution of
the application, and M is its set of methods.
As defined before, the resources that are due to be protected by an access control policy in an RDM
application, are only its methods’ executions. A method execution ω is a tuple:
ω = (MET HOD, rcv, args) (5.2)
MET HOD ∈ M, rcv ∈ O, args ⊂ O
where, m is a method, rcv is the method’s execution receiver, i.e., an object that performs method m, and
args is a set of objects that are passed as arguments to the execution of method m. The set of all method
executions ω that are possible in an application APP is denoted Ω.
Having defined the resources considered by the model, I shall now define how the resources are protected.
For that I introduce the notion of rule.
A rule r is an entity that states if the access to a given method’s executioon ω is to be permitted or denied,
for a given user u. There are different types of rules that address different types of permission or prohibition.
They are: positive and negative authorization rules, amplification rules, positive and negative delegation rules,
and delegated rights. These rules shall be defined ahead in this dissertation.
31
Rules are grouped in policies. An access control policy P is defined as a tuple:
P = (AUT H+, AUT H−, AMP,DELEG+,DELEG−,DELEGR) (5.3)
where AUT H+ and AUT H− are sets of positive and negative authorization rules respectively, AMP is a
set of amplification rules, DELEG+ and DELEG− are sets of positive and negative delegation rules respec-
tively, and DELEGR denotes the set of all delegated rights. Note that all elements of tuple P can assume the
value ∅ (empty), in which case the policy does not have elements of the corresponding type.
With these concepts, I can now define the notion of access control in the proposed model. Similar to the
general access control definition given in Chapter 1, by Equation (1.1), access control is a function φ:
φ(u, ω) =
ALLOW, if ∃r ∈ P that permits user u to execute ω
DENY, otherwise(5.4)
This function it not rigourosly defined, but I shall define it in a formal way ahead.
5.1.2 Authorization Rules
As it was stated in the previous section, a rule is what ultimately defines what the access control decision
should be. An authorization rule is the simplest type of rule, as it directly states if a given user can access a
given resource under certain circumstances.
Before formally defining an authorization rule, I first want to define the concepts of S UBJECT and
T ARGET , as they are needed for the definition of that rule.
A S UBJECT is an entity that denotes a set of users from U. The relation between a S UBJECT and a
user u is given by a subject assignment. Formally, a subject assignment σ is a tuple:
σ = (S UBJECT,US ERS ) ∈ Σ (5.5)
S UBJECT ∈ S ,US ERS ⊆ U
where S represents the set that contains all the subjects and Σ denotes the set that contains all the subject
assignments.
Similar to the concept of S UBJECT is the concept of T ARGET . A T ARGET is an entity that denotes a
set of methods from M. Likewise, a target assignment is the relation that defines which T ARGETs refer to
which methods. Formally, a target assignment τ is a tuple
τ = (T ARGET,MET HODS ) ∈ Γ (5.6)
T ARGET ∈ T,MET HODS ⊆ M
where T represents the set that contains all targets and Γ the set of all target assignments.
With the concepts of S UBJECT and T ARGET I can now define authorization rule as a tuple
auth = (S UBJECTS ,T ARGETS , α), (5.7)
32
where S UBJECTS is a set of subjects, and T ARGETS is set of targets, as they were previously defined,
and α is a predicate that takes as input a user u and a method execution ω.
Authorization rules express which subjects have access to which targets under the conditions expressed
by the predicate α. As mentioned before, a policy can have both positive, P.AUT H+, and negative authoriza-
tion rules, P.AUT H−. Positive authorization rules are the ones that express that authorization can be granted,
whereas negative authorization rules forbid that authorization to be granted.
I shall now explain how are authorization rules evaluated.
Considering US S (u) to be the set of the assigned subjects to a given user u
US S (u) = s ∈ S : ∃σ∈Σ(s = σ.S UBJECT ∧ u ∈ σ.US ERS ) (5.8)
and MTS (m) the set of targets that a given method m corresponds to
MTS (m) = t ∈ T : ∃τ∈Γ(t = τ.T ARGET ∧ m ∈ τ.MET HODS ) (5.9)
an authorization rule r matches a given user u executing ω if the following predicate evaluates to true.
matches(u, ω, r) =
TRUE
if r.S UBJECT ∈ US S (u)∧
r.T ARGET ∈ MTS (ω.MET HOD),
FALS E otherwise.
(5.10)
When a given authorization rule r matches a user u executing ω and r’s predicate, α(u, ω), evaluates to
true, then the rule is valid to (u, ω). The predicate valid(u, ω, r) is then defined as:
valid(u, ω, r) =
TRUE if matches(u, ω, r) ∧ r.α(u, ω)
FALS E otherwise.(5.11)
The evaluation of the access control function is given by the following definition of function φ
φ(u, ω) =
ALLOW,
if ∃r1 ∈ P.AUT H+ : valid(u, ω, r1)∧
@r2 ∈ P.AUT H− : valid(u, ω, r2)
DENY, otherwise
(5.12)
There are a few remarks to be made about the presented conceptualization of an authorization rule as
described above.
The use of S UBJECT and T ARGET entities to define an authorization rule creates a decoupling between
the rule and an application, which brings a number of advantages that contribute to the achievement of the
model’s goals.
The S UBJECT creates a separation between the rules and the users to which it applies that greatly eases
the management of a policy, because it allows the number of users to vary without the need to be constantly
modifying its rules. This was one of the reasons of why the RBAC model turned out to become so popular.
As for the T ARGET , it also creates a separation between the rules and the methods of an application.
This also allows the application to evolve and grow without the need of redefining the existent rules. The use
33
of a T ARGET as a building block to the construction of an application’s access control policy contributes to
the compositionality of the model.
The predicate α of an authorization rule makes an authorization rule to be valid only under circumstances
that may be not directly related to a user or a method’s execution. This permits the expressive power of a rule
to be greater than normal access control model that only take into account the user and the resource being
accessed.
To accomplish the goal of minimizing accidental errors that can lead to an access control breach, I opted
to follow an approach where, whenever in doubt, forbid. For that reason, if there is a positive authorization
rule that allows a subject to access a target, but there is a negative authorization rule that forbids, the access
should be denied. For the same reason, if no valid positive rule is found, although there is no valid negative
rule to forbid, the access is also denied.
5.2 Specifying authorization policies using the DMAPL
In Chapter 4 I presented the motivations behind creating a DSL to specify an access control policy for an RDM
application. In this section, I shall begin to introduce the DMAPL by showing how it can be used to specify an
authorization rule as it was defined in the previous section.
To present the syntax of the DMAPL I shall use a context-free grammar and the notation that is used in
the Java Language Specification [Gosling et al., 2005].
The objective of the DMAPL is to specify an access control policy. So the goal symbol of the DMAPL
syntactic grammar is the nonterminal symbol PolicySpecification presented in Listing 5.1.
As it can be seen, a PolicySpecification is a sequence of zero or more rule declarations. As was stated
in the previous section, there are different types of rules and each one has its own specific declaration con-
struction. In this chapter I shall describe how to specify authorization rules only.
Listing 5.2 hows the grammar rules for declaring an authorization rule.
An authorization rule declaration has an optional name that allows references to it in other rules of the
policy. The notion of authorization rule in the proposed model comprises two types of authorization rules:
positive authorization rules and negative authorization rules. In the DMAPL, an authorization rule is positive
if it is declared with the keyword allow, and negative if the keyword deny is used instead.
In the definition given in the previous section, an authorization rule has three components: subjects,
targets, and a constraint. The body of an authorization rule contains these three components, also.
Listing 5.3shows the syntax to specify a set of subjects of an authorization rule.
Different subject specifications in the same authorization rule are separated by commas. An individual
user in the application can be specified as a subject by using the keyword user followed by an identifier that
univocally identifies that user.
However, this construct does not explores all the expressive power of the concept of S UBJECT as it
only denotes one user. To denote a group of users that share a common responsibility in an application, the
construct role subject should be used. This construct is composed by the keyword role and an identifier that
univocally identifies that group of users in the application.
34
PolicySpecification
RuleDeclListopt
RuleDeclList
RuleDecl
RuleDeclList RuleDecl
RuleDecl
AuthRuleDecl
TicketDecl
AmpRuleDecl
DelegRuleDecl
Listing 5.1: DMAPL’s syntax for policy specification
AuthRuleDecl
RuleNameopt AuthRuleType AuthRuleBody
RuleName
QualifiedName :
AuthRuleType
allow
deny
AuthRuleBody
SubjectDeclList to TargetDeclList ConstraintDeclopt
Listing 5.2: DMAPL’s syntax for authorization rules.
35
SubjectDeclList
SubjectDecl
SubjectDeclList, SubjectDecl
SubjecDecl
UserSubjectDecl
RoleSubjectDecl
all
UserSubjectDecl
user Identifier
RoleSubjectDecl
role Identifier
Listing 5.3: DMAPL’s syntax for declaring subjects.
The keyword all denotes all users of a given application.
The second component of an authorization rule is the target. Listing 5.4 shows the grammar rules to
specify a target.
As it happened with the declaration of a list of subjects, a list of targets is specified using commas to
separate each target declaration. A target can be declared as being a method, or an annotation.
To declare a target as a method, the full signature of the method must be used, in order to distinguish
between methods with the same name. In Java, the mainstream language considered in this dissertation, the
signature of a method is composed by the full name of the class from which the method belongs to, including
its package name, the name of the method, and a list of the method’s argument’s type. In the DMAPL, a
target denoting a method of an application is specified in the same way, except that the list of arguments of a
method’s signature can contain optional names to refer to those arguments in the constraint part of the rule,
as I shall explain ahead.
Although some times the method granularity is desired when declaring a target of an authorization rule,
if that was the only existent level of granularity it would not allow a decoupling between the rule and the
application method’s. As referred in the previous section, one advantage of the T ARGET entity is that it
allows the access control policy’s rules and the application to evolve separately, due to the indirection that this
concept creates.
In the DMAPL, the mechanism used to create the decoupling between a target and the methods of an
RDM is the use of Java annotations. When a given authorization rule makes sense in a group of semantically
related methods, an annotation can be created and used on those methods. This way, the annotation presents
a mechanism to denote a semantic group of methods. This annotations can then be used to specify a target
that denotes that same group.
For this, the construct annotation target should be used. This construct is very simple, as it is only
36
TargetDeclList
TargetDecl
TargetDeclList, TargetDecl
TargetDecl
MethodTargetDecl
AnnotationTargetDecl
MethodTargetDecl
QualifiedName . Identifier (ParameterList)
ParameterList
Parameter
ParameterList, Parameter
Parameter
QualifiedName Identifieropt
AnnotationTargetDecl
@Identifier
Listing 5.4: DMAPL’s syntax for target declarations.
37
constituted by the symbol @ followed by an identifier that corresponds to the name of the desired annotation.
Although the proposed solution uses Java annotations, it does not mean that it is totally dependent of this
mechanism or Java itself because of this. In fact, any mechanism of tagging a method could be used. As a
last resource, the tagging mechanism can be based on language’s comments.
Finally, the last part of an authorization rule is the constraint. The constraint represents the predicate
α defined in the previous section. Listing 5.5 shows the grammar rules for the ConstraintDecl non-terminal
symbol.
The specification of a constraint is very simple: it is a Java expression between brackets that evaluates
to the boolean values true or false. In this Java expression however, there are a few reserved keyword
and identifiers that can be used. The keyword user denotes the user whom the authorization rule is going to
be evaluated against. The keyword receiver denotes the object that is executing the method that triggered
the evaluation of the expression. Finally, all the names used in the specification of the signature of a method
can also be used in this expression, and will evaluate to the objects that were passed as arguments to the
corresponding method.
Note the expressive power that this construction allows. The evaluation of an authorization rule not only
depends on a subject or a target, but also on a condition expressed in a mainstream programming language,
that can address run-time entities like a user who is executing a method, the arguments that were passed to
that method, the receiver of the method, and also the global state of the execution of the RDM through static
methods. Constraint expressions can also use predicates implemented in the RDM.
To make the presented syntax and semantic more clear, I shall now present some examples of use, using
the Student Record application introduced in Chapter 3.
Consider the following access control constraints, previously stated for the Student Record application:
• A student can see his own grades, but cannot see other students’ grades.
• Teachers can see all their students’ grades.
• The personal data is private to each person.
• Teachers can only give their courses grades.
• Only officers can cancel courses.
From these constraints, it can be infered that there are three groups of users that share a common re-
sponsibility in the application. These groups, or roles, are: Student, Teacher, and Officer. These are the
roles that are going to be considered in the next examples.
Starting by the last constraint that states that the task of canceling courses is only authorized to users that
are part of the group of users that have the responsibility of being officers, an authorization rule that expresses
this constraint, can be specified using DMAPL as Listing 5.6 shows. This rule expresses that a user that has
the officer role, can be allowed to execute the method cancelCourse, of the Student class. If no other
ConstraintDecl
where BooleanJavaExpression
Listing 5.5: DMAPL’s syntax for specifying constraints.
38
rule is specified that allows the execution of this method, then only officers are able to cancel courses.
This is a very simple rule, because it does not have a specification of a constraint. It does not need one
because what is wanted to be accomplished with this policy rule is to allow an officer to cancel a student’s
course independently of the circumstances. It does not matter who the officer is, nor the student, not even the
relationship between them.
However, the same does not happen for the task of giving a grade to a student. In that case, the policy
desired is not to allow any teacher to give any grade to any student. Just the teachers who teach a given
course can give a grade of that course to a student. Listing 5.7 shows this constraint specified with an
authorization rule in DMAPL. In this rule, it is stated that users with the role Teacher can perform the method
giveGrade, over objects of the class Student. However, the authorization should be only granted if the
teacher that is related to that user is a teacher of the course that is passed to that method. Considering that
the predicate teachesCourse(Course course) evaluates to true only if a teacher is a teacher of course,
the rule is only valid to teachers in that situation.
Note that this predicate certainly can have other uses apart from access control, as it can be used in
the logic of the application. This illustrates why, in an RDM application, an access control policy may take
advantage from the use of the domain methods to express complex policy constraints.
As for the access of a student’s grade Listing 5.8 illustrates how the corresponding constraints can be
expressed in DMAPL. The rule StudentGradeAccess gives authorization to all users who have the role of
Student to perform the method getGrades, whenever the user’s person is the same as the person related
with the student that corresponds to the method’s receiver. This way the policy’s goal is accomplished.
In the case of TeachersGradeAcces the scope of the rule is reduced to the group of teachers that taught
a course to the student in question. That is ensured by the teachesStudent(Student student) predicate,
which again, as it can be useful for the application logic, should be implemented in the RDM.
On both of these rules, notice the use of the keyword receiver to denote the run-time object instance
that corresponds to the receiver of the method from the rule.
Finally, to illustrate the use of annotations as targets for authorization rules, consider the constraint for ac-
cessing personal information. Suppose that the methods that manipulate personal data, which are considered
private, are the following methods of the class Person: getAddress and getIdNumber.
Listing 5.9 illustrates an authorization rule in DMAPL that can be used to enforce the desired policy.
Although this rule expresses the pretended policy, it suffers from the problem of having to be re-written if, for
instance, a method getPersonalSecret is added to the application and is also to be considered a personal
information that can be accessed only by the person to whom that information belongs.
A more robust approach would be to create an annotation @Personal and annotate all the methods that
Off icersCancelCourseAccess :
allow role O f f i c e r
to s tudent record . Student . cancelCourse ( Course course , Student s tudent )
Listing 5.6: Cancel courses access specified in DMAPL.
39
GiveGradeAccess :
allow role Teacher
to s tudent record . Student . giveGrade ( Course course , i n t grade )
where user . getPerson ( ) . getTeacher ( ) . teachesCourse ( course )
Listing 5.7: Give grade constraint implemented in DMAPL
StudentsGradeAccess :
allow role Student
to s tudent record . Student . getGrades ( )
where user . getPerson ( ) == receiver . getPerson ( )
TeachersGradeAccess :
allow role Teacher
to s tudent record . Student . getGrades ( )
where user . getPerson ( ) . getTeacher ( ) . teachesStudent ( receiver )
Listing 5.8: Grades access specified in DMAPL.
Personal InfoAccess :
allow a l l
to s tudent record . Person . getAddress ( ) ,
su tdent record . Person . getIdNumber ( )
where user . getPerson ( ) == receiver
Listing 5.9: A possible approach to the personal data constraint.
40
manipulate personal information with that. This way Section 5.2 shows a more robust way of expressing the
desired rule.
Whenever a new method that manipulates personal information is added to the application, the only thing
needed to be done is to annotate it with @Personal, whereas the authorization rule remains the same and
still maintains the desired effect.
Note that in the above rule declaration it is assumed that the receiver’s class of all the methods annotated
with @Personal implement the method getPerson. As was stated before, the annotations are meant to group
methods that share a semantic meaning. In this case, the annotation denotes a group of methods that deal
with personal information, so it is fair to assume those methods’ receivers should have some relation with an
instance of the class Person. This way, the requirement of having a method that permits to reach that person
seems a fair one considering the advantages that come from it.
The existence of this semantic meta-information about methods does not only allows the access control
policy to be more manageable, but can also be used in other contexts of the application. Other field where
these annotations can be used is, for instance, when dealing with automatic presentation generation for the
application. The generating engine can use this semantic information about methods to produce the correct
output layout for a given method.
5.3 Implementing and Enforcing Authorizations
The enforcement of an access control policy described with the DMAPL, using the concepts described in this
chapter, is the task of the run-time engine. For that, as mentioned in Chapter 4, those concepts need to have a
run-time representation. In this section, I shall introduce how to implement an engine capable of enforcing an
access control policy, using the Java programming language and the object oriented programming paradigm.
5.3.1 Run-time model
To begin, consider the class diagram depicted in Figure 5.1, that shows an authorization rule. An authorization
rule contains at least one Subject, one or more Targets, and can or cannot have a Constraint.
5.3.1.1 Subject
To support the two kinds of subject specification provided by the DMAPL, the engine should also have two
type of subjects: the RoleSubject and the UserSubject.
Personal InfoAccess :
allow a l l
to @Personal
where user . getPerson ( ) == receiver . getPerson ( )
Listing 5.10: A more robust version of the personal information constraint.
41
isValid
AuthorizationRule
TargetSubject
Constraint
0..1
1..* 1..*
Figure 5.1: Class diagram of an authorization rule.
To make the engine independent of the underlying application, the class that represents a role in the
engine, should be different from the class that represents a role in a given application. This is accomplished
by introducing an interface AccessControlRole. This way RoleSubjects use this interface to refer to roles,
while developers are free to specify a role class that makes sense to the application in cause. All that is
needed to do is that the class in question implements the AccessControlRole interface.
In a similar way, a UserSubject also needs to denote a user object in the application. To allow a sepa-
ration of concepts between the type of users manipulated by the engine and by the application, the interface
AccessControlUser should be used. Listing 5.11 shows the declaration of this interface. Again, the class
that corresponds to the notion of user in the application should implement the AccessControlUser interface.
This interface imposes a method hasRole. This method is used by the engine, to verify if the user in question
has a certain role.
The attribution of roles to users is exterior to the engine, and is left to developers and application main-
tainers. However, it is sub-intended that there exists a relation between users and roles in the application.
For the engine to be able to find which instances correspond to the users and roles specified in DMAPL,
developers have to implement an AccessControlFinder. Listing 5.12 shows the declaration of the interface
for an AccessControlFinder. This is the entity responsible to convert user ids and role names in specific
user and role instances. So it should contain two methods: getUserById that returns an AccessControlUser
instance that corresponds to a given user id, and getRoleByName that returns an AccessControlRole which
corresponds to a given role name.
When evaluating authorization rules, it is necessary to check if a given user matches a rule’s subject.
That is the function of the predicate matches(AccessControlUser user). A specific implementation of this
predicate is needed for the UserSubject and RoleSubject. In the UserSubject, it is only needed to verify
public interface AccessControlUser
public boolean hasRole(AccessControlRole role);
Listing 5.11: AccessControlUser interface.
42
public interface AccessControlFinder
public AccessControlUser getUserById(String uid);
public AccessControlRole getRoleByName(String roleName);
Listing 5.12: AccessControlFinder interface.
if the user refered by the subject is the same as the user passed as argument. For the RoleSubject the
vefirication should be done using the hasRole for that user, with the role refered by the subject.
Figure 5.2 shows the class diagram of the classes that relate to subjects’ representation.
5.3.1.2 Targets
A Target also can also be of two types: MethodTarget or AnnotationTarget. As mentioned before, a
MethodTarget denotes a method, which in Java can be univocaly identified by its signature. So an object of
the class MethodTarget has to keep information of the method class’s package name, the name of the class
to which the method belongs, the method name, a list of arguments. As for the AnnotationTarget the only
necessary identifier is the annotation name. The class diagram for these classes is depicted in Figure 5.3
Note the existence of the matches predicate again. As it happened with subjects, this predicate is nec-
essary when evaluating authorization rules. As defined in the model, the objective is to deal with methods’
executions. So to verify if a method execution, corresponds to a given target the matches predicate should
receive as arguments the name of the method, the receiver of the method, and an array of objects that are
the arguments passed to that methods’ execution.
In the case of a MethodTarget the operation matches checks if the class of the receiver, the method
name, and the type of the arguments passed, are the same as the ones specified by the target. In the case
of the AnnotationTarget it is verified if the method in question possesses the annotation in question.
5.3.1.3 Constraints
The class that represents a constraint must be able to compute the result of the predicate denoted by that
constraint. So, the class Constraint has a string that represents the Java expression predicate specified
using the DMAPL, and the method evaluate that performs the computation of that expression. For that, the
BeanShell can be used [Niemeyer, 2008]. From the BeanShell user’s manual:
BeanShell is a small, free, embeddable Java source interpreter with object scripting language features.
BeanShell executes standard Java statements and expressions but also extends Java into the scripting do-
main with common scripting language conventions and syntax.
Due to these scripting features, the use of the BeanShell allows the verification of access control predi-
cates that perform domain operations, without all the hassle of type verification. It also enables the modifica-
tion of predicates in run-time, contributing to the dynamism of the engine.
To ensure that the evaluation of the constraint expression happens with the proper values for its variables
the class EvaluationEnv provides a way to associate name with values. This association is done through an
43
matches
UserSubject
matches
RoleSubject
AccessControlRoleAccessControlUser
User Role
matches
Subject
implements implements
*has
1 1
Figure 5.2: Class diagram of the subject concept.
className
method
matches
MethodTarget
type
name
Argument
annotation
matches
AnnotationTarget
matches
Target
*
arguments
has
Figure 5.3: Class diagram of the target concept.
44
EvaluationVar that is simply an object with a name and a reference to another object.
Before calling the evaluate method an EvaluationEnv should be created in order to give the corre-
sponding values to the variables user, receiver, and the arguments names of the receiver.
The operation evaluate, only has to get the values from this kind of environment and then populate the
BeanShell environment to the execution of the Constraint’s expression. Listing 5.13 illustrates this operation.
By considering that a constraint class is an evaluator of its own constraint expression also allows future
extensions to the constraint expressions used in the DMAPL. The only thing that is needed is to define a
subtype of constraint that implements the evaluate method with the proper interpreter. Figure 5.4 illustrate
some possible examples.
Having defined the various components of an authorization rule, I shall now discuss the implementation
of the operation isValid. As defined in Section 5.1, an authorization rule is valid for a for a given user
and method execution, if the user and the method match the subject and target of the rule, and if the pred-
icate of the rule evaluates to true. Listing 5.14 illustrates an implementation of this operation for the class
AuthorizationRule. Note the use of the EvaluationEnv constructor. This constructor receives an user as
the first argument, an object as the second, an array of objects as the third, and finally a list of strings. The
first argument is automatically associated with the user string in that environment, and the second with the
string receiver. As for the third and fourth arguments, it is created an EvaluationVar with the name of the
string on index i of the list passed as argument and that name is associated with the value of the object on
position i of the array. This way it is ensured that the constraint expressions are evaluated with the proper
values.
As defined in Section 5.1, an authorization rule is part of a policy. The class PolicyContainer is the
entity that implements the concept of a policy P.
To represent the elements of the tuple that represent a policy, a PolicyContainer has seven types of
collections: two for positive and authorization rules, another for amplification rules, another two for positive
and negative delegation rules, and a seventh for delegated rights.
The policy container is also responsible for all the manipulation of the global policy. Namely:
• The addition and removal of rules.
public boolean evaluate(EvaluationEnv env) throws
ConstraintEvaluationException
bsh.Interpreter interpreter = new Interpreter();
try
for(EvaluationVar var : EvaluationEnv.getVariables())
interpreter.set(var.getName(), var.getValue());
return (Boolean) interpreter.eval(this.constraintExpression);
catch (Exception ex) throw new ConstraintEvaluationException(ex);
Listing 5.13: Evaluation of constraints using the BeanShell.
45
JavaConstraint LispConstraint CConstraint . . .
expression
checkConstraint()
Constraint
Figure 5.4: Class diagram of a constraint with examples of possible extensions.
boolean isValid(AccessControlUser user, String methodName ,
Object receiver, Object[] arguments)
if(this.getSubject().matches(user) &&
this.getTarget().matches(methodName , receiver, arguments))
if((Constraint cons = this.getConstraint()) == null) return true;
else
EvaluationEnv env = new EvaluationEnv(user, receiver, arguments ,
this.getTarget().getArgumentNames());
return cons.evaluate(user, receiver, arguments);
return false;
Listing 5.14: Authorization Rules’ isValid predicate.
46
• The retrieval of rules that affect a given subject or a given target.
• Answer to queries that relate to a certain aspect of the global policy.
This last responsibility can be used by the RDM if information about the access control policy is needed
to accomplish some type of functionality, as for instance to draw a proper graphical interface given the access
control constraints that apply to a given situation.
It is also worth mentioning that the policy container is a singleton entity, that is, there must be only one
instance of this entity in all the application. This allows the application to know exactly where the policy can
be found and avoids different policies to coexist in the application.
5.3.2 Enforcing Authorization Decisions
After exposing the components that relate authorization rules, I can now explain how they are used in the
enforcement of an access control policy in an application.
In order to decide if authorization should be granted for a given execution of a method an operation,
checkAccess, should be added to the beginning of a methods’ execution in order to compute the decision
as defined by function φ. For that, the operation checkAccess receives as arguments a user, the name of a
method, the receiver of the method, and an array of arguments passed to that method. If after the execution
of the checkAccess operation, the access is granted, then the execution of the method should continue
as normal. On the other hand, if the access is denied then the operation should throw an access control
exception.
This is the general idea of how to enforce a policy in a given method. However, which methods should
perform the operation checkAccess? Two approaches are possible:
• Check in all methods: Performing the checkAccess operation on all methods of the RDM ensures that
no matter what the specification of the DMAPL policy is, all the methods shall check the policy before
proceeding their execution. Because of the semantic of function φ this approach obliges the policy to
be very detailed and cover the exact behaviour to adopt in all methods, which for very large application,
can become unmanageable.
• Check only in methods specified in the DMAPL : As all the methods that are affected by a policy, and
should be protected are specified in the DMAPL, the checkAccess verification can be placed only on
those methods, considering that the other methods should be public. Although this approach removes
some flexibility from modifying a policy in run-time, because not all the methods perform this verification,
it can increase the overall performance of the application because the verification is only performed
where it is really needed.
I opted for the second approach because I think that when dealing with RDM, manageability is more
important then the flexibility of totally re-writing a policy.
The task of placing the checkAccess operation in the beginning of the methods can be automated using
code injection techniques like Javassist [Chiba, 1998]. This automation helps to eliminate the errors where
developers forgot to put access control verifications in the body of a method.
Listing 5.15 shows the implementation of operation checkAccess. The operation checkAccess follows
47
the semantics of function φ. Access is granted if no negative authorization is found valid, and at least one
positive authorization rule is valid for the execution in question.
I have already laid out the elements of the engine that relate with enforcing authorizations, and I have
discussed how are the access control verifications placed in the application. However I still need to explain
how is the user that is using the application is located.
Related to this questions is the notion of access control session. An AccessControlSession is a class
with three static methods: beginAccessControl(AccessControlUser user), endAccessControl, and
getUserInSession. After a user has authenticated in the application the corresponding AccessControlUser
should be created, and the access control session should be initialized with the method beginAccessControl.
This method stores the user in a thread local variable. So, whenever the getUserInSession method is in-
voked, the correspondent user to the current thread is returned. When the user is about to leave the ap-
plication, the endAccessControl method should be invoked to clear the thread local variable. The object
AccessControlSession also stores other kind of information about the user as I shall discuss in the follow-
ing chapter.
void checkAccess(User u, String m, Object r, Object[] args)
for(AuthorizationRule r : PolicyContainer.getNegAuthPolicy())
if(r.isValid(u, m, r, args)) throw new AccessControlException();
for(AuthorizationRule r : PolicyContainer.getPosAuthPolicy())
if(r.isValid(u, m, r, args)) return;
throw new AccessControlException();
Listing 5.15: CheckAccess implementation.
48
6 Amplification of Privileges
To improve access control’s flexibility, it is necessary to provide a way to temporally override previously estab-
lished access control rules. One way to achieve this without loss of security is through controlled amplification
of privileges. In Chapter 2, I showed some works that approached amplification of privileges with a variety of
solutions. In the solution presented in this dissertation, I opted for an approach based on authorization tickets.
The concept of tickets has already been used with wide success in authentication and authorization systems
such as Kerberos [Steiner and Schiller, 1988].
In this chapter, I shall define a mechanism of amplification of privileges based on tickets. I start in Sec-
tion 6.1 by presenting a metaphor to illustrate the concept of amplification of privileges and the basic idea
behind the use of tickets. Then, in Section 6.2 I formally define a ticket and introduce a new type of rule: the
amplification rule. I also show how these two entities fit the authorization model described in Chapter 5. Sec-
tion 6.3 introduces the DMAPL’s syntax and semantics for specifying a policy with amplification of privileges,
and shows an example of use. Finally, in Section 6.4, I explain how to support amplification of rights in the
access control run-time engine.
6.1 An Introductory Metaphor
The main idea behind the approach followed to handle amplification of privileges can be explained with a
simple metaphor.
Consider a social event, for instance. In this type of events there is a defined list of invited guests that is
normally composed by VIPs. These guests are all entitled to access the social event. The guest list, which
can be viewed as an authorization policy, states that they have that right.
Sometimes, the organizers of the social event, in order to increase the revenues of a social event, and at
the same time, increase the number of participants in the event, opt to sell tickets to regular people. People
who buy a ticket can then attend the social event, although they were not on the guest list. By buying a ticket
to a social event, people are amplifying their rights. The entity that permits this, is the ticket, which states that
its owner has the right to go the event.
An important notion about tickets, is that not all tickets for a given event provide the same rights. For
instance, a ticket won in a radio contest may give the owner the right to take a free drink, whereas a ticket
bought at the social event entrance, does not.
It is also worth noting that this amplification of rights has a temporary nature. After handling the ticket at the
event’s reception, when the person leaves the event, she can not go back in because she does not possess
the ticket anymore. A guest however, can enter and leave how many times she wants because the guest list
states that as long as a person has a given identity that is on the guest list, she has the right to be at the
event. This nuance illustrates that with authorization, access control decisions are made considering identity,
whereas with tickets the access control decisions are made through the possession of something. This allows
to have a very flexible access control policy, because it is not needed to state exactly which identities are
entitled to something.
49
6.2 Amplification of Privileges Model
I shall now explain how can amplification of privileges be achieved for a user during a method execution ω,
in order to ensure that the user possesses the right privileges to perform ω, with the notion of tickets as
described in the above metaphor. For that, at least three concepts must be defined: the concept of ticket type,
ticket, and amplification rule.
A ticket type is the entity that is responsible to describe a generic right that a user may possess over
the course of an application’s execution, although it may not have been stated previously with authorization
rules. The ticket type is what defines the resources that a user who possess a ticket of that type may access.
Consider the analogy in real life with tickets for a movie session or for a football match. As they are different
types of tickets, they provide access to different type of resources.
The specific instances of a given ticket type are called tickets. A ticket is the association of a ticket type
with a state. This state, that is set during the creation of a ticket, enables access control decision to be made
based on information relating ticket creation’s circumstances. This way, tickets created at different times, for
different users, in different circumstances can provide different rights. It is like the difference of a ticket won in
the radio contest that gave its owner the right of having a free drink, or the tickets bought at the entrance that
did not provided this right.
Finally, amplification rules are a special type of policy rules that state when does a user should receive a
ticket of a specific ticket type.
In the next subsections I present a formalization for these ideas.
6.2.1 Ticket Type
Formally, a ticketType is a tuple
ticketType = (T ARGETS , β) (6.1)
where T ARGETS is a set of targets as defined in Chapter 5, and β is a predicate that receives as argu-
ments a method’s execution ω, and a set of objects args. Υ denotes the set of all ticket types.
The purpose of a ticketType is to describe the right that a user may possess to access a given set of
resources. Those resources are denoted by T ARGETS component of a ticketType.
As with authorization rules, a ticket type tt matches a given methods’ execution ω, if the following predicate
evaluates to true:
ticketTypeMatches(ω, tt) =
TRUE if tt.T ARGET ∈ MTS (ω.MET HOD),
FALS E otherwise.(6.2)
The predicate β states under which circumstances the right expressed by a ticket type can be consider to
be valid. I shall provide a detailed explanation for the function of this predicate later in this section.
50
6.2.2 Amplification Rules
In order to maintain the overall security of the system, amplification of rights must be due to specified policy
rules. These rules are the amplification rules.
An amplification rule, amp, is a tuple:
amp = (S UBJECTS ,T ARGETS ,T ICKETS ) (6.3)
The function of the amplification rule is to state where in the execution of the RDM application are the
rights to be amplified. This means that the amplification rule expresses which tickets should be given to which
users, when a user executes a certain method.
So, in the above tuple, S UBJECT defines a subject to whom the rule applies, T ARGET denotes to which
method’s execution the rule applies to and T ICKETS specify the set of ticketTypes that the user should
receive. The methods to which the rights of a user are being amplified, are stated in the tickets that are
attributed due to an amplification rule, and depend of the ticketTypes specified.
An amplification rule r matches a given user u executing ω if the predicate matchesAmpli f ication evaluates
to true, as defined in the following equation:
matchesAmpli f ication(u, ω, r) =
TRUE
if r.S UBJECT ∈ US S (u)∧
r.T ARGET ∈ MTS (ω.MET HOD),
FALS E otherwise.
(6.4)
6.2.3 Tickets
Having defined the concepts of ticket type and amplification rule, I can now describe how tickets are instanti-
ated, based on amplification rules.
A ticket instance, or simply ticket, is a tuple
ticket = (TYPE,T ICKET ARGS ) (6.5)
T ICKET ARGS ⊂ O
where type is a specific ticketType and T ICKET ARGS are a set of objects that define the state of the
ticket.
There can be many tickets to access the same resource, but those tickets can have differences between
them. Recovering the social event’s tickets metaphor, tickets can be emitted at different times and with that
information, provide different types of access. It is this type of information that the T ICKET ARGS component
of a ticket intends to capture. This information can then be used in the evaluation of the predicate β defined
by the ticket’s type.
As mentioned before the predicate β states the circumstances that need to be met for allowing the owner
of the ticket to have access to the T ARGET defined by the ticket’s type. These circumstances can depend
not only on the method being executed, but also on state information of the ticket present in T ICKET ARGS .
51
A ticket t is then valid for a given method’s execution, if the following predicate evaluates to true:
validT icket(ω, t) =
TRUE
if matchesT icketType(ω, t.TYPE)∧
t.TYPE.β(ω, t.T ICKET ARGS )
FALS E otherwise.
(6.6)
The instantiation of tickets based on an amplification rule r originates the set T I(r) described in Equa-
tion (6.7)
T I(r) = t ∈ T : ∃ticketType∈Υt.TYPE = ticketType ∧ ticketType ∈ r.T ICKETS (6.7)
6.2.4 Security Context
As mentioned in Section 6.1, the important thing about tickets when it comes to access control decisions is
the notion of possession. As I also mentioned while describing the metaphor for this model, the possession
of tickets is temporary. In the context of this dissertation, the duration of an amplification of privileges is the
same as a method’s execution. A security context S C(u, ω) is the entity that holds all the tickets that a given
user u possesses during a certain method execution ω.
So far, a method execution as been seen as being an isolated element. However that does not happen in
real applications. The flow of execution of an application depends on invocation of methods by other methods.
This originates what is called the execution context of a given application.
The execution context is a list of method executions < ω0, ω1, . . . , ωn >. ω0 denotes the main method of
the application. ω1 denotes the method that the main method invoked and that originated all the methods’
execution ω2, . . . , ωn−1 that resulted in the invocation of the currently executing method wn.
A method’s execution ω can then be re-defined in order to incorporate this notion of invocation context. A
method execution ωn is a tuple:
ωn = (m, rcv, args,Ω∗) (6.8)
m ∈ M, rcv ∈ O, args ⊂ O
where Ω∗ is the execution context of method ωn, i.e., is the list < ω0, ω1, . . . , ωn−1 >.
With the definition of execution context, it is now possible to formally define the security context in an
inductive way as follows:
S C(u, ω0) = ∅
S C(u, ωn) = S C(u, ω.Ω ∗ .last) ∪ T I(r), (6.9)
∀r∈P.AMPmatchesAmpli f ication(u, ωn, r)
As it can be seen, the security context varies with the execution context of an application. This way, it is
ensured that when for a given method execution ω an amplification is required, the security context is updated
52
with the proper tickets. After that execution, the security context no longer contains the correspondent tickets
and so, the user loses the amplified rights.
6.2.5 Decision process
As mentioned in the beginning of the present chapter, the purpose of amplification of rights is to provide
flexibility through the override of previously stated authorization policy. This way, a redefinition of the access
control function φ is needed in order to incorporate this possibility.
Consider, the following definition of φ′:
φ′(u, ω) =
ALLOW,
if (∃r1 ∈ P.AUT H+ : valid(u, ω, r1)∨
∃t ∈ S C(u, ω) : validT icket(ω, t))∧
@r2 ∈ P.AUT H− : valid(u, ω, r2)
DENY, otherwise
(6.10)
With this definition, the function φ′, besides considering authorization rules to decide the execution of
method ω, also checks the existence of tickets in the user’s security context that are valid to that given
method.
Note that, this way a policy that denied the access to a given method execution ω by the inexistence of
valid positive authorization rules can be overriden. However, the same does not happen when valid negative
authorization rules exist. If forbidness could also be overridden the security of the overall policy would be
reduced because that way, there was no way to ensure absolute protection of a given resource. That is why I
opted to not allow tickets to override negative authorization rules.
Through this process the amplification of privileges is controlled by amplification rules providing the model
with some flexibility but still ensuring security constraints.
6.3 Specifying Amplification of Privileges in DMAPL
After the conceptualization, in the previous section, of amplification of privileges, I shall now continue to
describe the syntax and semantics of the DMAPL. I shall show and explain this language’s constructs that
can be used to specify a policy with amplification of privileges in an RDM application.
To begin with, consider Listing 6.1 that shows the DMAPL grammar’s rule for the ticket declaration.
A ticket declaration starts with the keyword ticket followed by a name for the ticket. This allows the same
ticket to be referred in different amplification rules. A parameter list follows the name of the ticket.
This list declares which are the objects that make the T ICKET ARGS component of a ticket, as described
in Section 6.2. The parameters declared on that list are the objects that provide information about the ticket’s
creation. This information can then be used in the constraint declaration.
The ticket body is constituted by the keyword to followed by a list of targets declaration and an optional
constraint declaration. The targets specified in the target declaration define to which targets the ticket provides
access to. The constraint of a ticket expresses under what circumstances the ticket is valid, allowing the
access to the ticket’s target. In this constraint’s expression the keyword user has the same meaning as in
53
TicketDeclaration
ticket TicketName (ParametersList) TicketBody
TicketBody
to TargetDeclarations ConstraintDeclarationopt
TicketName
QualifiedName
Listing 6.1: DMAPL’s syntax for ticket declarations.
authorization rules. The keyword receiver denotes the receiver object, of the methods denoted by target.
The parameters’ names of the target’s methods can also be used in this constraint’s expression, as in the
authorization rules, as well as the tickets own parameters. This way, tickets’ validity can depend not only
on the person who possess it, but also on the state of the receiver of the method denoted by target, the
parameters that are passed to that method’s execution, and also on the arguments that were passed to
the ticket on its creation, allowing a great granularity for tickets, and the whole amplification of privileges
mechanism.
The DMAPL’s syntax for declaring amplification rules is given in Listing 6.2.
An amplification rule can have an optional name so that it may be referred to in other rules. The body of an
amplification rule starts with the keyword on followed by a target declaration, an optional subject declaration,
and a sequence of ticket invocations separated by commas.
The target specified in the target declaration states which methods should provide tickets to a user, in
order to amplify the user’s privileges to access other targets. These other targets are specified by the tickets
themself.
The tickets are attributed only to the users denoted by the subjects declared in the SubjectsDecl part of
the rule. If the tickets should be attributed to anybody, then the keyword all should be used.
The last part of the amplification rule’s body consists in a list of tickets that should be attributed on the
execution of the rule’s target to the specified subjects. The ticket list is a sequence of one or more ticket
invocation, where it is specified each ticket that should be given and a list of arguments that should be passed
to the ticket. The ticket arguments can be the receivers and arguments of the targets of the corresponding
amplification rules.
6.3.1 Example
To better explain how the proposed amplification of privileges mechanism works, I shall now give an example.
Consider the access control constraint of the Student Record application, described in Chapter 3, that
stated the officers access to a student’s average:
• Officers can only see student’s average, without having direct access to the specific grades of a student.
As explained in Chapter 3, a student’s average is calculated through the method getAverage from the
54
AmpRuleDecl
RuleNameopt AmpRuleBody
AmpRuleBody
on TargetDeclList give SubjectDeclList TicketInvocationList
TicketInvocationList
TicketInvocation
TicketInvocationList, TicketInvocation
TicketInvocation
ticket TicketName ( ArgumentList )
ArgumentList
Identifier
ArgumentList , Identifier
Listing 6.2: DMAPL’s syntax for amplification rules.
class Student. Giving to an officer the authorization to execute the method getAverage is not enough. As
there is no authorization rule that allows officers to access a student’s grades, when, in the computation of
the student’s average, the grades are needed to be accessed, the access is denied for a user with the role of
an officer.
It is then needed to specify that, although under normal circumstances, an officer should not be granted
access to a student’s grades, during the execution of the getAverage method, this right should be provided.
This calls for an amplification of privileges rule that provides a ticket to access a student’s grades for the
execution of the getAverage method. Listing 6.3 shows a possible amplification rule for implementing this
constraint.
The ticket gradeTicket gives access to whoever possesses it to execute the method getGrade of the
class Grade. The OfficerAverageAccess rule specifies that, during the execution of the method getAverage,
the ticket gradeTicket should be given to officers.
t i c k e t gradeTicket ( )
to s tudent record . Grade . getGrade ( )
Off icerAverageAccess :
on s tudent record . Student . getAverage ( )
give role o f f i c e r t i c k e t gradeTicket ( )
Listing 6.3: Amplification of privileges specification in DMAPL.
55
Although this rule satisfies the desired requirement, the ticket gradeTicket provides access to all grades
from all students. This way, when an officer executes the method getAverage for a student, let’s call her
Alice, the officer is gaining privileges to access the grades of all other students, including Bob. If the body
of the getAverage is correct, and accesses only the grades of the student that it corresponds to, then there
should be no trouble. However, to make the policy more robust, and independent of the correctness of the
getAverage method, a more specific rule should be used, such as the one exemplified in Listing 6.4.
With this rule, the access to a student’s grade, through the ticket gradeTicket, is granted only if the grade
in question belongs to the student, which average was being computed when that ticket was given.
Notice that this way the rule is no longer dependent of the correctness of the method specification, as the
ticket is valid only for a specific user.
This exemplifies the expressive power of the amplification rules. Another important aspect of these rules,
is how they can help developers to correctly enforce an access control policy in a compositional manner.
Amplification rules and tickets allow the definition of a self contained access control policy for a given method
m. This way, if method m depends on method m1 to complete its execution, and method m1 is protected
by some authorization rule, it is possible to specify that during the execution of method m, m1 should be
accessible through an amplification rule with a corresponding ticket. When developing other methods that
use method m, the policy does not need to be altered. This greatly simplifies the development of features in
RDM applications.
6.4 Enforcing and Implementing Amplification of Privileges
In order to support the amplification of privileges mechanism presented in this chapter, the engine must be
expanded. Besides the support for authorization, it also needs to have a run-time representation of tickets and
amplification rules, and operations that implement the expansion and reduction of rights functions presented
in Section 6.2. As this operation depends on the notion of security context, an entity that supports this concept
is also needed. Finally, the method checkAccess presented in Chapter 5 needs to be updated in order to
support this new mechanism. In the rest of this section, I shall discuss the implementation for all this.
t i c k e t gradeTicket ( Student s tudent )
to s tudent record . Grade . getGrade ( )
where receiver . getStudent ( ) == student
Off icerAverageAccess :
on s tudent record . Student . getAverage ( )
give role o f f i c e r t i c k e t gradeTicket ( receiver )
Listing 6.4: A more specific amplification of privileges for the officer access to students’ average constraint.
56
6.4.1 Run-time model
6.4.1.1 Ticket
As mentioned before a run-time representation of a ticket is needed. A ticket can be represented by the class
Ticket as described in the class diagram of Figure 6.1.
A ticket, as described in Section 6.2, has three components: a target, a constraint, and a list of arguments.
The target and the constraint are represented by objects of the class Target and Constraint respectively,
as described in Chapter 5. The list of arguments is represented by the relation arguments where an object
of the class TicketArgument has a name and an object that corresponds to the value of that argument. The
name of a TicketArgument is used to refer to its value, in the expression of the Constraint when it is being
evaluated.
The method isValid is a predicate that states when a ticket is valid for a given user accessing a deter-
mined target. As defined in Section 6.2, to determine a validity of the ticket is necessary to check if the target
matches the method being executed and if the constraint of the ticket evaluates to true.
6.4.1.2 Amplification Rule
An amplification rule, can be implemented by a class AmplificationRule as depicted in the class diagram
of Figure 6.2. This class, contains a target and a subject to which the rule corresponds as described earlier
in this chapter. In order to provide the correct tickets, when it is supposed to, an AmplificationRule also
contains a list of ticket factories that implement the Prototype pattern [Gamma et al., 1995]. When an object
of the class Ticket needs to be created, the method makeTicket is used, which invokes the method clone
of the class ticket. This originates a copy of the desired ticket, which then can be initialized with the desired
values through the method init.
The operation matches of an amplification rule is responsible to indicate if that rule corresponds to a given
user and method execution. Its implementation is similar to the operation of the same name of the class
AuthorizationRule.
init
isValid
Ticket
String name
Object value
TicketArgument
Constraint
Target
1..*
0..1
arguments
*
Figure 6.1: Class diagram of a ticket.
57
matches
AmplificationRule
makeTicket
TicketPrototype
ConstraintSubject
Target
*
1..* *
1..*
0..1
Figure 6.2: Class diagram of an amplification rule.
6.4.1.3 Security Context
In order to maintain, in an organized way, the tickets that a given user has, a structure is needed. In the
proposed model, that structure was defined as the security context.
To implement a security context in a way that make the implementation of the operations to expand and
reduce rights more simple, a stack structure can be used. This stack stores all the current tickets that a user
has in a given moment.
To allow batch add and removal of tickets, the security context holds ticket frames, instead of single tickets.
A ticket frame, is a set of tickets that are created and stored, at the same moment in the security context.
Whenever a ticket is to be added to the security context, a new ticket frame is created, and all the tickets
that are related by having the same creation time are added to that ticket frame. That ticket frame is then
pushed into the security context. When a given ticket frame is no longer needed, it is simply popped out of
the security context.
A security context is related to a user executing the application. As discussed in Chapter 5, the object
AccessControlSession is used to store information about the user that is executing the application, and
consequently the methods protected by a policy. So, it is foreseeable that the security context should be
stored on the AccessControlSession correspondent of a given user interaction. The security context is
automatically initialized whenever a session begins.
Figure 6.3 shows a class diagram for the implementation of a security context. The SecurityContext
class, must provide operations that allow queries about the existence of a given ticket in any ticket frame
the security context contains. The operation getTicket implement this feature. This operation receives a
method execution (method name, receiver, and arguments) and searches in all the ticket frames for a ticket
with a corresponding target. If it finds one, it returns it, otherwise returns null.
In order to guarantee the LIFO semantics associated with a stack structure, the methods push and pop
add and remove an element from the top of the stack, respectively.
58
getTicket()
push()
pop()
SecurityContext
TicketFrameAccessControlSession
AccessControlUser Ticket
1
1
*11
*
Figure 6.3: Class diagram of the security context.
6.4.2 Expansion and Reduction of Rights
As mentioned in the model description, in order to amplify the privileges of a given user during a method
execution, an expansion of rights operation is needed. This operation checks all the amplification rules to see
if any matches a given user and method execution. If such rule is found, then the tickets of that amplification
rule should be inserted into that user’s security context. Listing 6.5 shows the implementation of that operation.
The operation expandRights receives as input a user, and the elements of a method execution. The search
for an amplification rule that matches the given user and method, is equivalent to the search of finding an
authorization rule, as explained in Chapter 3. When a rule is found, their factories produce the corresponding
tickets, that are then initialized with the receiver and arguments of the method being executed. As mentioned
before, this allows the tickets to store the information referent to the object for which the ticket was given, and
will allow the ticket constraints to reason about that information. The produced tickets are then inserted in a
ticket frame that is then pushed to the correspondent security context.
The expandRights operation, should be invoked after the checkAccess operation described in Chapter 5.
This ensures that the amplification of privileges for a method m, only occurs for users that have access to
that method. Besides that, this operation, should be executed immediately after checkAccess in order to
guarantee that no method instruction that needs a certain privilege, is executed without a user’s rights have
been amplified accordingly.
As it happened with the checkAccess invocation the expandRights can also be placed automatically in
the right place, from the DMAPL specification using code injection. The methods that are denoted by targets
for amplification rules should all be injected with an invocation for the expandRights.
The semantics associated with amplification of privileges in the proposed solution implies that this ampli-
fication only lasts as long as a method is executing. So, before a method terminates, the inverse operation,
should be performed. To reduce the rights of a given user, after the execution of a method that granted that
user with additional rights, the only thing that needs to be done is to remove the corresponding ticket frame.
Due to the LIFO semantics of the security context implementation explained above, the reduceRights op-
eration is just a single instruction to pop the top of the stack, as showed in Listing 6.6. Code injection using
Javassist also allows to place the invocation to this operation in the correct place automatically.
59
void expandRights(User u, String m, Object receiver , Object[] args)
for(AmplificationRule r : Policy.getAmplificationPolicy())
if(r.matches(u, m, receiver , args))
TicketFrame frame = new TicketFrame();
for(TicketPrototype ticketFactory : r.getTickets())
Ticket ticket = ticketFactory.clone();
ticket.init(receiver , args);
frame.add(ticket);
Session.getSecurityContext().push(frame);
Listing 6.5: Implementation of the expansion of rights operation.
reduceRights()
Session.getSecurityContext().pop();
Listing 6.6: Reduction of rights operation implementation.
6.4.3 Deciding Authorization with Tickets
In order to cope with amplification of privileges, the authorization decision operation checkAccess needs to
be updated as the function φ′.
Authorization to execute a given method, should be granted by two distinct ways: 1) through an authoriza-
tion rule, with the same criteria as before, or 2) by the existence of a valid ticket in the user’s security context
that refers to that method.
The modifications in the checkAccess algorithm are denoted in Listing 6.7. The authorization rules of the
policy are swept in search for a rule that fits the user and the method that are passed as input. When no
rule is found that meets such criteria, then the SecurityContext is searched in order to check if there is a valid
ticket to the method in question. When such ticket is found, the access is granted through that ticket.
If no positive authorization rule, or no ticket is found, then the access is denied for the reasons explained
in Chapter 5. It is worth mentioning again, that a negative authorization rule has precedence over either a
ticket or a positive authorization rule.
60
void checkAccess(User u, String m, Object r, Object[] args)
for(AuthorizationRule r : PolicyContainer.getNegAuthPolicy())
if(r.isValid(u, m, r, args)) throw new AccessControlException();
for(AuthorizationRule r : PolicyContainer.getPosAuthPolicy())
if(r.isValid(u, m, r, args)) return;
Ticket ticket = Session.getSecurityContext().getTicket(m, r, args)
if(ticket != null && ticket.isValid(u, m, r, args))
return;
throw new AccessControlException();
Listing 6.7: Check access operation with support for amplification of privileges.
61
7 Delegation of RightsOne of the goals of the proposed solution is to support delegation of rights. As was stated in Chapter 3,
delegation has two dimensions: a static one, where the delegation policy is expressed, stating what is allowed
to be delegated, and a dynamic one, that results from the effective delegation of a right from a user to another.
In this chapter I shall approach both of these dimensions and explain how the proposed solution model
supports both of them.
As in the previous chapters, I begin in Section 7.1 with a formal abstraction of the concepts involved in
delegation of rights. Then, in Section 7.2 I finish the description of the syntax and semantics of the DMAPL,
by introducing this language’s constructs that allow it to express a policy with delegation of rights. Finally,
in Section 7.3 I continue the description of the run-time engine’s implementation in Java, to show how it can
support delegation of rights and provide an API for developers to incorporate delegation of rights in their
applications.
7.1 Delegation Model
As mentioned before in Chapter 3 delegation is a two dimensional problem. One is the problems related
to the specification of the delegation policy, i.e., what rights can be delegated to whom, under what circum-
stances. The other one, is how to represent a right that has been delegated, and how does this delegated
right influences the access control decision process.
I shall start to define a model for the first dimension, by introducing the concept of delegation rule. A
delegation rule is a special type of rule that states what can be delegated in a system. When a user is allowed
to delegate something to another user, i.e, there is a delegation rule that allows it, a new authorization should
be created. This new authorization is what I call a delegated right and it is how I address the second part of
the problem. A delegated right is what represents, in run time, that a certain user, the grantee, was granted a
certain right by another user, the grantor.
After describing the general idea behind the delegation of rights I shall now present a formalization for
these concepts.
7.1.1 Delegation Rule
The entity responsible for stating what rights can be delegated, is the positive delegation rule. A positive
delegation rule, deleg+, is a tuple:
deleg+ = (AUT H,GRANTOR,GRANT EE,T ARGETS , χ, λ) (7.1)
where AUT H denotes a positive authorization rule of P.AUT H+, GRANTOR and GRANT EE are subjects,
T ARGETS is set of targets, and χ and λ are predicates.
A positive delegation rule states who can delegate what to whom, under what circumstances and for how
long. The right which a delegation rule refers to, is stated by the AUT H element of a delegation rule. Note
that a right cannot be represented by a negative authorization rule, because those do not express rights, but
prohibitions.
63
GRANTOR represents a subject that expresses who can delegate the right AUT H. On the other hand,
the GRANT EE component denotes the subject that the delegation rule expresses, as being entitled to be
granted the right denoted by AUT H. The T ARGETS of a delegation rule states what subset of targets, from
the AUT H’s targets, can be delegated.
The predicate χ is a predicate that expresses under what circumstances can a delegation be performed.
The circumstance can involve some relation between the user who is delegating, the grantor, and the grantee.
So, this predicate receives two users as arguments, that denote the grantor and grantee users, respectively.
After a right has been delegated, it may be useful to control until when is the delegated right valid. A
grantor may just want to delegate a right for one hour, one day, during his vacations, until the grantee turn
18 years old, etc. The predicate λ is intended to capture this idea, i.e., it expresses what are the conditions
needed to be met for the delegated right to still be valid, after the delegation has occurred. The arguments
for the λ predicate, besides the grantor and grantee users, also contain a method execution. This method
execution corresponds to the execution of the method denoted by the T ARGETS of the delegation rule. This
allows the validity of a delegated right to depend also on the state of the execution of the target.
Sometimes it is not enough to express what can be delegated, as it is also necessary to express what is
forbidden to be delegated. This is the purpose of negative delegation rules.
A negative delegation rule, deleg− is a tuple:
deleg− = (AUT H,GRANTOR,GRANT EE,T ARGETS , χ) (7.2)
As it can be seen, the components of the negative delegation rule are the same as the positive. The only
difference is the lack of the validity predicate λ, because no right can be delegated from a negative delegation
rule. All the other components have the same meaning as in the positive delegation rule, with the exception
that the negative delegation rule expresses prohibition to delegate.
A delegation rule r is said to match a given grantor uo, grantee ue, and method m, if the following predicate
is true:
matchesDelegRule(uo, ue,m, r) =
TRUE
if r.GRANTOR ∈ US S (uo)∧
r.GRANT EE ∈ US S (ue)∧
r.T ARGET ∈ MTS (m)
FALS E otherwise.
(7.3)
A delegation rule r is said to be valid for a given grantor uo, grantee ue and method m if the following
predicate evaluates to true.
validDelegRule(uo, ue,m, r) =
TRUE
if matchesDelegRule(uo, ue,m, r)∧
r.AUT H.T ARGET ∈ MTS (m)∧
uo ∈ US S (r.AUT H.S UBJECT )∧
r.χ(uo, ue)
FALS E otherwise.
(7.4)
64
The verification of the matchesDelegRule predicate ensures that there is a delegation rule that matches the
desired delegation whereas the verification of the χ predicate ensures that the conditions for the delegation
to happen are met. However, those are not the only verifications that are done. It is also verified if the
grantor user is denoted by the subject of the corresponding authorization rule, as well as if the method being
considered is also denoted by the target of that rule.
These verifications avoids that subjects, who are not entitled to a certain right are able to delegate that
right to another user, i.e., it ensures that the grantor of a delegation rule is also a subject of the corresponding
authorization rule, and that the method whose right is being delegated is also referred by that rule.
Note that this condition could be enforced at the delegation rule level by obliging the GRANTOR and
T ARGETS of a delegation rule to be some subset of the correspondent components of the authorization rule
in question. However, this would lead to a greater dependency between the rules.
Consider a delegation rule d, that refers to an authorization a. If the GRANTOR and T ARGET of d had
to be a subset of the subjects and targets of a, then whenever a was modified, d also had to be modified.
By allowing this verification to be done only by the predicate validDelegRule the rules become independent
which facilitates the overall management of an access control policy, while still maintaining the same security
properties.
These are the concepts that address the first part of the delegation of rights problem. When a delegation
occurs, a new right is created. The entity that represent this right is the delegated right which is defined in the
following sub-section.
7.1.2 Delegated Right
A delegated right dr, created based on a positive delegation rule r is a tuple:
dr = (GRANTORu,GRANT EEu,T ARGETS , α, λ), (7.5)
GRANTORu,GRANT EEu ∈ U,
r.GRANTOR ∈ US S (GRANTORu),r.GRANT EE ∈ US S (GRANT EEu)
T ARGET ≡ r.T ARGET,α ≡ r.AUT H.α, λ ≡ r.λ
D denotes the set of all delegated rights.
A delegated right states that a user GRANTORu delegated the right to execute the methods denoted by
T ARGETS to user GRANT EEu.
As it can be seen from the above definition the users GRANTORu and GRANT EEu must be users that
were denoted by the originating delegation rule’s GRANTOR and GRANT EE correspondently. The T ARGET
components of a delegated right, as well as theλ predicate are the same as the ones of the originating
authorization rule.
The predicate α of a delegated right serves the same purpose of the predicate of an authorization rule: it
states the circumstances under which GRANT EEu should be allowed to access T ARGET . There is however
a detail with this predicate that I shall explain ahead.
65
A delegated right dr matches a given user u and method execution ω if the predicate matchesDelegRight
evaluates to true as defined in the following equation:
matchesDelegRight(u, ω, dr) =
TRUE
if dr.GRANT EEu = u∧
r.T ARGET ∈ MTS (ω.MET HOD)
FALS E otherwise.
(7.6)
As it is emphasized by this definition, a delegation right refers only to a single user rather than a subject.
This is because delegation of rights happens just between users.
A delegated right dr is valid for a given user u, and method execution ω if the predicate validDelegRight
evaluates to true as defined in the following equation:
validDelegRight(u, ω, dr) =
TRUE
if matchesDelegRight(u, ω, dr)∧
dr.λ(dr.GRANTOR, u, ω)∧
dr.α(dr.GRANTOR, ω)
FALS E otherwise.
(7.7)
As it is shown by the above definition, three conditions must be met in order for a delegated right to be
valid for a given user u during method execution ω:
1. It has to match the user and target of the delegated right.
2. The validity predicate λ needs to be verified for the user u, the delegated right’s grantor, and the method
execution ω.
3. The α predicate needs to evaluate to true for the delegated right’s grantor and method execution ω.
This last item call for more explanation. In a regular authorization rule, it makes sense that the predicate α
depends on the state of the user who is trying to execute method ω. In a delegated right, however, the same
principle does not apply. This is because the predicate α, in a delegated right, is the same of the authorization
rule from the positive delegation rule which originated it. In the authorization rule, the predicate α had a
certain meaning for that rule’s S UBJECT . In a delegated right, as the GRANT EEu element has nothing
to do with the original S UBJECT the predicate would most probably just evaluate to FALS E. This makes
sense because under no circumstances would a user not denoted by an authorization rule’s S UBJECT , be
valid for a method execution ω that matched that rule’s T ARGET . The delegated right’s α can, however, be
verified against the grantor of the right because it was original denoted by the authorization rule’s S UBJECT .
This way, the GRANT EEu is granted with an equivalent right of the original owner of that right, because the
predicate α will only evaluate to TRUE when it would for the grantor of the right.
7.1.3 Delegating Rights
Having defined the concepts of delegation rule and delegated right, I can now define the function that creates
a delegated right based on a delegation rule. This operation represents the intent of a grantor to delegate a
right he has, to execute a given method m, to another user. The function that defines this operation is denoted
by the greek letter δ and is given by the following equation:
66
δ(uo, ue,m) =
(uo, ue,T ARGET, α, λ)
if ∃r1 ∈ P.DELEG+ : validDelegRule(uo, ue,m, r1)∧
@r2 ∈ P.DELEG− : validDelegRule(u, ω,m, r2)∧
T ARGET = r1.T ARGET, α = r1.AUT H.α, λ = r1.λ
∅, otherwise
(7.8)
So, for a delegation of rights to happen, it has to exist a valid positive delegation rule that allows it, and
there must not be a negative one that denies it. Once again, negative rules have precedence over positive
ones to improve the overall security as discussed in Chapter 5. When such a rule exists, a delegated right is
created, referring the users in question, and the T ARGET and validity predicate λ of that rule. The predicate
α of the authorization rule referred by the positive authorization rule is also passed to the newly created
delegated right. The new delegated right should then be placed in the correspondent policy’s component
P.DELEGR.
Delegated rights should also be considered when evaluating an access control decision. So the function
φ′ defined previously should be reviewed in order to incorporate this feature.
Consider the definition of φ′′:
φ′′(u, ω) =
ALLOW
if (∃r1 ∈ P.AUT H+ : valid(u, ω, r1)∨
∃t ∈ S C(u) : validT icket(ω, t)∨
∃dr ∈ P.DELEGR : validDelegRight(u, ω, dr))∧
@r2 ∈ P.AUT H− : valid(u, ω, r2)
DENY otherwise.
(7.9)
With this new definition of function φ′, access can also be allowed to a user u to perform method execution
ω if that user was granted that right. If there is a valid negative authorization rule that forbids this execution by
this user, then it still has precedence over the right that was delegated. This way it is ensured that a prohibition
is absolute and cannot be violated in an application. This way, although there is some flexibility available for
access control specifications, security can still be enforced on top of everything.
7.2 Specifying a Delegation Policy Using DMAPL
In this section I continue to expose the syntax and semantic of the DMAPL by presenting this language’s
constructs to express a delegation policy. The DMAPL addresses only the first part of delegation of rights,
i.e., the static part where it is stated what can or cannot be delegated, as the delegation of a right itself only
happens during run-time, and so, this is a problem addressed by the run-time engine.
To support the specification of a delegation policy, the DMAPL provides a syntax, and corresponding
semantics, to declare a delegation rule, either positive or negative. Listing 7.1 shows the DMAPL grammar
for this type of rule’s declaration
A rule declaration starts by an optional name. This name identifies the delegation rule and enables its
reference. As explained in Section 7.1, a delegation rule can be either positive or negative. A positive
delegation rule is declared with the keywords allow delegation of, whereas a negative authorization rule
67
DelegRuleDecl
RuleNameopt DelegRuleTypeDecl
DelegRuleTypeDecl
PosDelegRuleDecl
NegDelegRuleDecl
PosDelegRuleDecl
allow delegation of DelegRuleBody ValidityConstraintDeclopt
NegDelegRuleDecl
deny delegation of DelegRuleBody
DelegRuleBody
Identifier GrantorsDeclopt GranteesDecl TargetDeclListopt ConstraintDeclopt
GrantorsDecl
grantor SubjectDeclList
GranteeDecl
grantee SubjectDeclList
ValidityConstraintDecl
validity BooleanJavaExpression
Listing 7.1: DMAPL’s syntax for delegation rules.
68
is declared with the keywords deny delegation of. This facilitates the understanding of the rule. Both rules
are then followed by the body of a delegation rule, that is common to both. In the case of positive delegation
rules an optional validity constraint can be declared.
The body of a delegation rule is constituted by an identifier, followed by optional grantors declaration, a
grantees declaration, an optional list of targets, and an optional constraint.
The identifier must correspond to a name of a positive authorization rule and it states which right the
delegation rule refers to.
The declaration of the grantors of a rule begins with the keyword grantor and is followed by a list of
subject declarations. These are the subjects that can be considered grantors of the right denoted by Identifier.
When the declaration of grantors is omitted, then it is considered that all the subjects of the authorization rule
referred by the delegation rule can be considered as grantors of that right. If the declaration of grantor is
present then, when the rule is evaluated it is checked if the grantor subjects correspond to the subjects of the
authorization rule in question, as discussed in Section 7.1.
The declaration of the grantees begins with the keyword grantee and is followed by a list of subject
declarations. These are the subjects to which the right considered by the delegation rule can be delegated.
Following the grantees declaration, there is an optional target declaration that, again, follows the semantic
discussed in Section 7.1.
A delegation rule’s constraint follows the same rules as a normal constraint, except that instead of the
keyword user the keywords grantor and grantee should be used. grantor denotes the user that is trying
to delegate a right to another user, denoted by grantee, when the rule is being evaluated. The keyword
receiver as well as the name of the targets methods’ parameters cannot be used in this constraint specifica-
tion because they have no meaning when deciding over a delegation rule. They just make sense when there
is a domain method executing and that is not the case when a delegation is happening, as I shall discuss in
the following section.
For the validity constraint of positive delegation rule, the same rules of a constraint declaration applies. The
available keywords are: grantee, grantor, receiver and the targets method’s parameters. This keywords
have the same meaning as defined before.
7.2.1 Example
For a better understanding of the syntax and semantics of a delegation rule, I shall now give an example
based on the Student Record application described in Chapter 3.
One of the requisites of the application was that it supported delegation of rights. The application’s policy
stated that teachers were allowed to delegate the right of giving grades to students as was stated in the
constraint:
• Teachers can delegate the responsibility of giving grades to officers.
To specify this policy’s clause, considering the right specified in Listing 7.2, a delegation rule like the one
in Listing 7.3 could be used.
This delegation rule states that teachers are allowed to delegate the right, to execute that rule’s target, to
69
GiveGradeAccess :
allow role Teacher
to s tudent record . Student . giveGrade ( Course course , i n t grade )
where user . getPerson ( ) . getTeacher ( ) . teachesCourse ( course )
Listing 7.2: Teachers’ right to give grades specified in DMAPL.
TeachersGiveGradeDeleg :
allow delegation of GiveGradeAccess
grantor role Teacher
grantee role O f f i c e r
Listing 7.3: Teachers’ delegation rule for the give grade right.
Officers. As mentioned in Section 7.1, the authorization rule’s constraint should be evaluated with the keyword
user as being the teacher that granted the right. This way, when a teacher, delegates the right to give grades,
it only allows the grantee, in this case, an officer, to give grades to the same students that the teacher would
be able to give grades to. In this case, it only allows the officer to give grades to the teachers’ students.
Consider now that it was desired that the delegation should be permitted only when a teacher was on
vacation and the delegation is to last only as long as the teacher is on vacation. Consider the existence of
a predicate isOnVacation on the class Teacher of the student records application that evaluates to true if
that teacher is on vacation. Listing 7.4 shows a way to declare this policy using the DMAPL.
In this new version of the delegation rule the constraint and the validity constraint are both specified. Their
expressions evaluates to true every time the teacher delegating the right is on vacation. This means that the
delegation can happen only when the teacher is on vacation, and the officer that was granted this right can
give grades only while the teacher remains on vacation. Notice the specification of the grantor and target of
the delegation rule and how they match the corresponding rule’s subject and target respectively.
TeacherGiveGradeOnVacationDeleg :
allow delegation of GiveGradeAccess
grantor role Teacher
grantee role O f f i c e r
to s tudent record . Student . giveGrade ( Course course , i n t grade )
where grantor . getPerson ( ) . getTeacher ( ) . isOnVacat ion ( )
val id grantor . getPerson ( ) . getTeacher ( ) . isOnVacat ion ( )
Listing 7.4: Delegation rule with constraint and validity constraint specified.
70
7.3 Implementing Delegations
To finish the description of the implementation of the proposed engine, I shall now specify what are the run-
time entities and operations that are needed to incorporate in order to make the engine capable of handling
with delegations.
7.3.1 Run-time model
In order to support delegation of rights two run-time representations must exist: delegation rules and del-
egated rights. The first one represents a policy rule that states what can be delegated, as mentioned in
Section 7.1. On the other hand, delegated rights result from the delegation of a right from a user to another,
based on an authorization rule, as described in that section also.
7.3.1.1 Delegation Rule
Delegation rules can be represented with a class DelegationRule as it is shown in Figure 7.1.
A DelegationRule is an abstract class that represents a delegation rule. An instance of a delega-
tion rule can be of one of its two subtypes: PosDelegRule that represents a positive delegation rule, or a
NegDelegRule that represents a negative delegation rule. The AuthorizationRule referenced by a dele-
gation rule represents the right in cause for that rule, as explained before. The class DelegationRule, and
subsequently its subclasses, has two relations with the class Subject: one that denotes the grantor and the
other the grantee. Both the grantor and grantee components of a delegation rule are regular subjects, so
there is no need for creating a dedicated class for those concepts. The Constraint of a delegation rule
represents the conditions that need to be met for that rule to be considered valid. It represents the χ predicate
defined in Section 7.1. As defined in Chapter 5, a constraint can receive multiple arguments, so it can cope
with the χ predicate’s arguments: the users that represent the grantor and the grantee respectively. In the
case of a positive delegation rule, a second predicate is needed, the validity predicate that states for how
long a delegation is valid. Again, as there are no significant differences in behavior, the implementation of this
predicate can also be based on the Constraint class.
DelegationRule ConstraintAuthorizationRule
Subject
constraint,validity 0..2
grantor,grantee
2
1
Figure 7.1: Class diagram of a delegation rule.
71
Note that, in the case of either the grantee or the target of a delegation rule, have not been specified, the
subject and target of the correspondent authorization rule are considered.
The isValid predicate for a delegation rule is the same whether it is a positive delegation rule or a
negative one. This predicate receives the grantee and grantor users, and checks if the rule matches both of
them. If so, in the cases that a Constraint exists, this constraint is checked against both users. If it evaluates
to true, then it returns true. If no constraint is specified and the rule matches both users, the predicate returns
true. If the users do not match the rule, or the constraint evaluates to false, then false is returned.
7.3.1.2 Delegated Right
A delegated right can be seen as a subtype of an authorization rule. As an authorization rule, a delegated right
also expresses permission to execute a given target by a given subject, under certain conditions. The main
differences between a delegated right and an authorization rule are at the level of subjects and constraints.
The subject of a delegated right, the grantee, is a specific user (and not a generic subject), and, besides
that, a delegated right has reference to another specific user, the grantor. At the level of constraints, besides
the circumstances constraint that exists in regular authorization rules, a delegated right possesses another
constraint, that is the validity constraint.
This conceptual and structural similarities, suggest that delegated rights can be implemented as a sub-
class of an authorization rule. Figure 7.2 shows a class diagram for this implementation. The Target,
Subject, and Constraint components of a delegated right are all inherited from the authorization rule. Note
that the Subject of a delegated right represents the grantee, which is always going to be of the UserSubject
type. Besides this elements a delegated right also has reference to another UserSubject that represents the
grantor, and a second instance of Constraint that represents the validity predicate.
The isValid predicate has a different meaning in an authorization rule and on a delegated right. List-
ing 7.5 shows the implementation of the isValid predicate for a delegated right. As it can be seen, although
there are similarities between this predicate and the one of the authorization rule, there are two main dif-
ferences: the constraint is checked using the grantor as the user, for the reasons explained in Section 7.1,
and after that an additional constraint is verified, the validity constraint. Note the use of the EvaluationEnv
method createVar to declare the variables with the names of grantor and the grantee.
DelegatedRight UserSubjectConstraint
AuthorizationRule
grantorvalidity
Figure 7.2: Class diagram of a delegated right.
72
isValid(AccessControlUser user, String methodName , Object receiver ,
Object[] args)
if(this.getSubject().matches(user) &&
this.getTarget().matches(methodName , receiver, args))
if((Constraint cons = this.getConstraint()) == null) return true;
else
EvaluationEnv env = new EvaluationEnv(this.getGrantor().getUser(),
receiver, args,
this.getTarget().getArgumentNames())
if(cons.evaluate(env))
if((Constraint val = this.getValidity()) == null) return true;
else
env.addVariable(‘‘grantee’’, this.getGrantee().getUser());
env.addVariable(‘‘grantor’’, this.getGrantor().getUser());
return val.evaluate(env);
return false;
Listing 7.5: Predicate isValid for a delegated right.
73
7.3.2 Delegating Rights
The action of delegating a right corresponds to the creation of a delegated right based on a delegation rule.
Listing 7.6 shows an implementation of the delegateRight method. The code is self explanatory, if the
delegation rule is valid for the grantor and grantee in question, and if it is a positive delegation rule then a
new delegated right is created. This newly created delegated right is then populated with the correspondent
references to the grantor and grantee. The delegation rule provides the validity constraint, and if specified,
the target for the delegated right. Otherwise, is the correspondent authorization rule that prodives the target.
In all cases, the circumstancial constraint is extracted from the authorization rule.
Note that this action has to be triggered by an use case of the application. In this use case, all the
delegations that are permitted to a user are shown to her. The list of permitted delegations can be extracted
from the authorization rules related to the existent delegation rules. After selecting the desired right to be
delegated, the user triggers the execution of the operation delegateRight.
The inverse operation of delegation, the revocation of delegated rights simply corresponds to the removal
of the correspondent delegated right from the PolicyContainer.
7.3.3 Deciding Authorization with Delegation
The final part of the delegation of rights is when the access control decision is about to be made. If the
user has a delegated right that allows the execution of a certain method then, based on that delegated right,
access should be granted. Of course it is still needed to verify all the conditions for normal user access.
So, the operation checkAccess must be updated to cope with delegation of rights. Listing 7.7 shows the
implementation of this operation after this update. The algorithm still maintains its original concepts: if no
negative delegation rule is found that forbids the user to execute the method in question, then the positive
authorization rules and tickets in the ticket context are searched. If the user still has not been granted access,
then the delegated rights are swept in search for one that is valid for the user in question. When one is
found the access is granted. On the other hand, if nothing is found that allows the user to execute the current
method, the access is denied.
74
delegateRight(User grantee, User grantor,
DelegationRule d) throws DelegationNotPermittedException
if(d.isValid(grantee, grantor))
if(PolicyContainer.getNegDelegationPolicy().contains(d))
throw new DelegationNotPermittedException();
DelegatedRight dr = new DelegatedRight();
dr.setGrantor(new UserSubject(grantor));
dr.setSubject(new UserSubject(grantee));
dr.setValidity(d.getValidity);
dr.setConstraint(d.getAuthRule().getConstraint());
if(d.getTarget() != null) dr.setTarget(d.getTarget());
else dr.getTarget(d.getAuthRule().getTarget());
return;
throw new DelegationNotPermittedException();
Listing 7.6: Implementation of the delegation of rights operation.
void checkAccess(User u, String m, Object r, Object[] args)
for(AuthorizationRule r : PolicyContainer.getNegAuthPolicy())
if(r.isValid(u, m, r, args)) throw new AccessControlException();
for(AuthorizationRule r : PolicyContainer.getPosAuthPolicy())
if(r.isValid(u, m, r, args)) return;
Ticket ticket = Session.getSecurityContext().
getTicket(m, r, args)
if(ticket != null && ticket.isValid(u, m, r, args))
return;
for(DelegatedRight dr : PolicyContainer.getDelegatedRights())
if(dr.isValid(u, m, r, args)) return;
throw new AccessControlException();
Listing 7.7: Check access operation with support for amplification of privileges and delegations.
75
8 Validation
In Chapter 3 of this dissertation I introduced the problems of enforcing access control policies in RDM applica-
tions. From Chapter 4 to Chapter 7 I proposed a solution to those problems and discussed an implementation
of that solution. In this chapter, I validate the proposed solution by showing how it can solve the current access
control problems of a real RDM application.
This chapter has only one section that is dedicated to describe the Fénix application, which mechanisms
it has to handle access control, and how the work presented in this dissertation can be used to improve the
access control of this application.
8.1 Case Study: Fénix
The real RDM application that I use as a way to validate the work proposed in this dissertation is the Fénix
system [FénixEdu, 2005]. Fénix is an open source web application aimed at integrating all the aspects
linked with the management of a university campus: from administrative tasks such as room management,
to students tasks such as students’ course enrollment, and even to teachers tasks as course’s webpage
creation. Due to its enormous set of functionalities and importance, I consider that Fénix is an application that
can be used to study how the proposals in this work can affect this and other real-life applications.
8.1.1 About Fénix
Fénix was a project started at Instituto Superior Técnico (IST) in 2001. Its original goal then was to ease
the creation and management of web pages for the IST’s courses. During the next years the scope of the
project became broader by starting to replace some legacy applications that were becoming hard to maintain.
Those legacy applications were used by the IST’s employees to do a variety of campus management work,
so when those functionalities were integrated in the Fénix system, it became an indispensable application for
all: administrative staff, teachers, and students.
Now with a large set of functionalities for campus management, implemented current technology, the
project started to interest other universities and the deployment outside the IST began. There were even
some companies that specialized in the deployment of the application. Currently, several universities have a
deployment of Fénix.
The Fénix development team at IST is composed by senior developers and undergraduate students. The
senior developers are programmers with a degree in software engineer or similar, whereas the undergraduate
students are generally final-year students from a software engineer degree that work half-time in the develop-
ment of this application, generally during one year. So, this development team has a high level of turnaround
along the years, which makes it depend on agile methodologies.
Fénix is a web application that uses a mix of industry standard and in-house developed technology. It
is written in Java and uses the Apache’s Java web container Tomcat, [Tomcat, 2008]. As it is common in
regular Web Applications, Fénix follows a three-layered architecture. Next I present the main components of
the Fénix architecture for each layer.
77
• Presentation layer : This layer is responsible for the user interaction with the application. It receives
instructions from a user and triggers the correspondent domain actions of the application. When those
actions complete, it is also the responsibility of the presentation layer to present the results of the
operations to the user. This layer follows the Model View Controller (MVC) architecture,[Gamma et al.,
1995], and uses the Struts,[Struts, 2008], framework to implement it.
• Business logic layer : This is the layer responsible for the computation of the Fénix domain operations.
This layer started as being service oriented, using the Transaction Script Pattern, [Fowler et al., 2002],
where each service implemented one functionality. The services of this layer invoked the persistence
layer methods to access the domain objects in order to perform the desired computation. The data and
behavior of domain objects were, this way, separated. More recently, the architecture of the system
changed towards a domain driven approach, as described in [Cachopo, 2007]. Presently this layer is
constituted by a complex web of interconnected objects that contain both data and behavior of the do-
main entities that the system tries to capture. This way Fénix has become an RDM application, with
a thin application layer. The specification of the domain entities and the relationships between them is
done using the Domain Modeling Language (DML) that compiles to Java so that developers can still
use all the IDE’s features. The work of Cachopo also introduced the concept of software transactional
memories to the Fénix development. With the integration of the Java Software Transactional Memory
and the DML, all the domain objects are automatically persistent and transactional, which greatly re-
duces the development effort of an RDM application. Before the introduction of this technology, Fénix
relied on the Berserk, [Luiz et al., 2004], framework to delimit the transactionality of its services. This
framework allowed the specification of filters that could be executed before and after the execution of
a service, where most of the access control verifications of the system were placed. With the shift of
paradigm, those filters had to be replaced with other access control mechanisms. Note however, that
due to the enormous amount of code and functionality that the system possesses, there are still some
parts of the application that are implemented with the old services architecture.
• Persistence layer : Finally, this is the layer responsible for keeping the domain objects persistent. As
mentioned before, this persistence can be automatically assured by the code generated by the DML,
which makes this the most simple layer of all in terms of development. The underlying database man-
agement software is the relational database MySQL and the object mapping tool used by the DML
compiler is the OJB framework,[OJB, 2008].
8.1.2 Fénix’s Current Access Control Mechanisms
Due to the broad range of Fénix’s functionalities, some of which crucial to the normal functioning of IST, and
the different type of users of this system, from students to the direction board of the institute, Fénix has to ad-
dress highly complex security requirements. The system uses encryption to store, send, and receive data to
users in a confidential way, when such is needed. To ensure the identity of its users, it uses a Central Authen-
tication System (CAS), [JA-SIG, 2008]. For access control however, there are currently different mechanisms
present in Fénix to guarantee this security requirement.
The lack of a single access control solution in the system is related with the fact that the system has never
78
stabilized its development. So, as new technologies and paradigms were being implemented in Fénix, the
access control solution used depended on the authorization mechanism provided by the used technologies.
This resulted in a code scattering problem because presently, it is very hard to track what is the access control
policy for the system.
In his work [Malheiro, 2007], Henrique Malheiro systematically approached and described the access
control mechanisms existing in Fénix. I shall now summarize that work.
• Service Level Access Control: In the previous service oriented architecture of Fénix, all its operations
were encapsulated by services. Those services were supported by the Berserk framework which, with
an implementation of the Intercepting Filter Pattern, provides a way to wrap a service invocation with
filters that can express pre and post conditions for the service to finish correctly. This allows developers
to create filters that checked if the user in the current session had the right privileges to invoke a given
service. As most of the Fénix functionalities were implemented in these services, enforcing access
control at the service filter level was a good way to cover almost all the actions that users could do on
the system. Besides that, filters could be re-used, composed, and presented a nice approach to deal
with code scattering and tangling problems. However, filters do not provide the necessary granularity for
RDM applications. Consider for instance a service that invokes n methods, but only one of them, which
is invoked inside an if clause has some access control requirements. It does not makes much sense
to wrap the whole service with a filter that verifies if the user can execute that method. One example
that shows this is to consider that the method is inside an if clause. The user could probably execute
the whole service without executing that particular method. However, if a filter was used in that service,
the access could be denied to that user.
• Method Level Access Control: In order to cope with the granularity limitation of service filters, a mech-
anism to specify access control at the method level was devised. Developers declare which conditions
are needed to be met for a given method to execute in predicates that implement a given interface.
Then they annotate the desired methods with a predetermined annotation, and a code weaving tool
injects the code necessary to invoke the predicate in the correspondent methods marked with annota-
tions. This approach is much more close to the RDM paradigm, allows the enforcement of a very fine
grained access control policy, and still addresses the code tangling and scattering problems. However,
this approach also has its share of problems. The development effort increases with this strategy, due
to the large number of methods to annotate, as well as to the equally large number of predicates that is
also needed to develop.
• Functionality Level Access Control: The evolution of Fénix led to the appearance of a functionality
model, which pretended to represent all the functionalities available in the system and organize them
in a tree structure. Besides other problems, like functionalities’ presentation, this model also tried to
address access control with the concept of availability policy. This policy states which users can ac-
cess a given functionality. Being more related to the presentation layer, this concept of functionality
availability permits the creation of a user interface, that depends on authorization, i.e., it is displayed to
the user only what she has permission to do. The specification of which functionalities are available to
which users is done using a group language, which allows the declaration of criteria that constitute the
79
requirements for a user to be in a given group. This way, the groups can vary dynamically, depending
on the properties of the users. The tree structure of functionalities provides this model with a composi-
tionability that is desired in RDM applications like Fénix. As it happened with services, access control
at the functionality level, provides a good way to address the operations that a user can perform in a
system. However, there is still little use of this model in the system, and the group language used by it
has a limited expressive power, when compared with general purpose languages that are used by the
other approaches.
• Infrastructural Level Access Control: In spite of being a web application, Fénix can enforce access
control at the level of the requests it receives from its clients. This is done using the Struts features to
declare filters for URL patterns. Every time a client requests an operation that comprises a filtered URL,
an access control verification can be done, which results in a good protection at this level. However,
specifying an access control policy from a complex application using solely URL patterns can become
quickly unmanageable, or result only in a very coarse granularity policy. This is why in Fénix these filters
are used only in very specific contexts.
• Implicit Access Control: Apart from the access control verifications specified with the previously stated
mechanisms, there are also some access control verifications introduced by programmers in various
parts of the code of the applications. The most common are verifications in Struts actions, in JSPs, and
in object’s code. This type of approach to access control is, by far, the worst, because it consists on
ad-hoc verifications that definitely results in code tangling and code scattering.
As it can be seen, there are various types of access control enforcement in the Fénix application, and
although some present certain advantages they also have certain limitations. However, the biggest problem
with all these approaches, is that there is not one that is used systematically over the whole system because
there is none that satisfies all developers needs. So, although the system uses a range of strategies that
individually avoid code scattering, by using this mix of strategies, the access control code starts to become
scattered between the specific development artifacts comprised by each strategy. Apart from that, there is no
support in none of this approaches to delegation of rights or amplification of privileges. As discussed before,
these are features fundamental for RDM applications.
8.1.3 How the work of this dissertation can be used in Fénix
After describing the evolving context of the Fénix application and its various mechanisms for access control,
I shall now show how the solution proposed in this dissertation can be used to improve the Fénix access
control and mitigate some of its current problems.
To begin, and as I mentioned previously, Fénix is suffering from a code scattering problem that results
from the lack of a solution that is systematically applied through all the application. This code scattering has
reached the point that the underlying access control policy has became almost hidden which greatly difficults
the task of auditing it. The proposals in this dissertation provide a way to specify complex access control
policy using a single development artifact, which could help solving these problems. By having all the access
control rules specified in one place it is possible to analise and review all the aspects related with this concern.
Besides the functionalities availability, all the other mechanisms do not allow the compositionality needed
80
for RDM applications. Even the service filters, although compositional between them, do not provide a real
advantage in this field, because it does not contribute to the compositionality of the RDM. In the proposed
solution, the amplification of rights mechanisms enables the compositional development of the RDM while
maintaining a correct access control enforcement. The main advantage over the functionalities availability
is that the proposed solution allows the specification of access control rules at a domain level, not directly
related with users’ operations, but with the domain behavior.
All the discussed mechanisms involved some sort of programatic effort to implement a given access con-
trol verification. Most of the time, developers had to declare a new class with a new filter, a new predicate, or
a new group. In the majority of those classes’ code, there would be a invocation to get the user in session,
and others to get the roles it possessed. With the introduction of a declarative language like the DMAPL, this
development effort is reduced, because this language’s constructs are specialized for the declaration of nor-
mal access control verifications, whereas the Java programming language is not. This relieves programmers
from repetitive work and let them concentrate on what is more important.
None of the existent mechanisms provide a way to delegate rights between users. As mentioned in
Chapter 3, the lack of this access control feature can lead to more serious security problems, like identity
sharing by users. With the proposed solution, Fénix would have, almost automatically, delegation support
which would enhance users’ flexibility. Another important aspect that the proposed solution enables, and
that is still not present in Fénix, is the possibility to dynamically change the access control policy without
re-deployment. All the existent mechanisms are static and do not provide this type of feature.
To finish this discussion, I also want to show that opting by this dissertation’s proposed solution, besides
the above mentioned advantages, developers do not lose expressive power facing the current options. For
that, I shall explain the general idea on how to migrate from the current mechanisms utilization, to the approach
proposed, when such is possible. When that migration is not directly available, I state why it cannot happen.
The scope of this discussion is not to provide a step by step description of how the proposed solution can
be integrated in the system and replacing the existing mechanisms, as that would probably be a work with
many more pages than this dissertation. What I want is to show what are the main changes that existent
implementation has to go through.
• Service Filters: The existing services in Fénix, use the methods of the domain objects. So, enforcing the
access control at the methods level with authorization rules denoting the same subject and additional
constraints verifications as the correspondent service filters automatically guarantees that the service
will execute with the proper access control. Due to their coarse granularity, the enforcement of access
control at the service filters level can sometimes be desired. However, with the proposed solution, the
option to enforce a coarse grained access control is still available. Services are still methods, and so
they can be defined as targets using the DMAPL. This way an access control policy can be devised
using solely access control verifications at the service level. With this explanation, I hope to make clear
that from an access control perspective, service filters do not bring any additional advantage versus the
proposed solution. They do not provide the same granularity as the proposed solution, but the latter
can still be used at the filters’ granularity.
• Method Predicates: The specification of access control rules in predicates is actually the closest of
81
the existing approaches to the proposed solution. So the transition from this type of strategy, to the
proposed solution is very simple, as they can be replaced with equivalent authorization rules. Those
rule should have, as target the annotated methods for a given predicate, the correspondent subject, and
the constraint should consist on the predicates’ verification.
• Functionality Availability: Functionalities addresses other problems besides access control. Their main
purpose is to address presentation issues, that are not in the scope of this work. The access control
mechanism resulting from functionality availability, should be seen as a complement to this dissertation’s
solution, because they deal with access control at different levels. However, I can argue that every group
specification can be declared also as an authorization rule, and that although it is not needed to have a
group specification for every authorization rule, an authorization rule should exist for every group. This
way, it is ensured that the domain layer is protected, independently of the presentation layer protection.
• Infra-structural Filters: This type of access control cannot be address by the proposed solution because
it is highly oriented to Web Applications, which is not necessarily the main target for the proposals of
this dissertation.
• Implicit Access Control: This approach to access control, although providing complementary protection,
should be eliminated. In cases where those verifications are not redundant they should be replaced with
an explicit authorization rule.
To close this chapter it is worth mentioning that, although the integration in the Fénix application of the
solution proposed in this dissertation has not started, there are plans to do so when the solution’s implemen-
tation reaches a more stable stage of development. Meanwhile, there are already applications developed
inside IST, that use the solution proposed in this dissertation.
One example is the Fénix’s feature request application FEARS. At the time of this writing, this application
was still not released as it is still being developed. However, one interesting result that could be observed was
that the decisions of the access control policy for the application were postponed and became independent
of the applications development. This was possible due to the high level of separation of concerns that the
proposed solution provided.
82
9 Conclusion
I close this dissertation with the present chapter, where I summarize what I believe to be the main contributions
of my work. I also want to leave in this last chapter some ideas and directions for future work.
9.1 Main Contributions
Throughout this dissertation, I presented the problems related to the enforcement of complex access control
policies in RDM applications. To solve those problems I proposed a solution and described an implementation
of that solution. I finally discussed how my proposals could enhance the enforcement of an access control
policy for a real RDM application, as a way to complement the validation of the solution.
So, the primary contribution of the presented work is to provide a way for developers to conceptualize,
specify, and enforce the necessary access control policies in their RDM applications, in a way that fits the
specific needs of those applications. As I discussed before, this implies that developers can do it using
compositional approaches to development, that allows them to tackle domain complexity, and that re-utilization
can also be used to aid in this task. Another important aspect related to this is that my solution contributes to
the reduction of code scattering and code tangling within complex applications.
However, there were also other features that the described solution enabled, and that I believe contribute
for improving the way access control is handled when developing RDM applications. Namely:
• The use of a DSL such as the DMAPL simplifies the task of specifying an access control policy because
it spares developers from the task of creating and configuring the mechanisms necessary to implement
such policy. With the DMAPL, developers have to worry only about the necessary information needed
to declare an access control policy, such as what are the resources that should be protected, who can
gain access to them or what conditions must be met. The model itself provides developers with a mental
model that will help them think about access control.
• By offering a mechanism that supports delegation of rights I hope to contribute to the dissemination
of this feature in RDM applications. Whereas it could be hard to support such feature with existing
methodologies, my solution eases its implementation, enabling developers to present this option to
users with little development overhead . Besides the flexibility improvements it provides, it can also help
to reduce the number of security problems related with authentication credential sharing.
• Most of the processes involved in the implementation of an access control policy, using the proposals
of this dissertation, are performed automatically. This contributes for a faster development of these
policies as well as it reduces human errors.
• The dynamic aspects of the proposed solution enable a desired quality in applications: applications
that can be updated without the need of being reinitialized. This hot-swap characteristic becomes more
important as the availability requirements of applications grow.
• The incorporation of all these features in a single access control solution contributes to the uniformiza-
tion of access control technologies within a system. As it was seen on the Fénix case study, the lack of
a uniform access control leads to code scattering and manageability problems.
83
9.2 Future Work
Every work should provide directions for further development. Although the work presented in this dissertation
is self contained, I want to terminate this text stating which areas can be explored by future research and
development with the ground this work laid out.
Note that it is impossible to conceive every direction of investigation that can be related to my solution, but
these are the points that I would delve into if I had the opportunity to do it after the present work.
• Although I described a possible implementation for the engine proposed in this dissertation, it was not
my goal in this work to provide the most efficient version of this implementation. This is mostly due to
the balance that should be achieved between efficiency and expressiveness. For instance, the rules in
the PolicyContainer could be indexed by targets or by subjects in order to accelerate the process of
finding a valid rule for each verification. However, this would limit the expressiveness of subjects and
targets to fully defined ones, as opposed to possible regular expressions that could be used to denote
for instance all methods of a given class. These two directions: the efficiency of the engine and the
expressiveness of the DMAPL should be approached in future works in order to find the best solution
for RDM applications.
• Related to the topic of the engine’s efficiency, the integration of the engine with other RDM development
platforms like the JVSTM presented in [Cachopo, 2007] could be explored. I believe that interesting
synergies could be obtained from the JVSTM’s transactions verification with access control verifications.
In the JVSTM, during each transaction all the objects that are accessed for reading and for writing are
logged. When the transaction ends, the JVSTM looks for conflicts in these logs and determine if the
transaction should abort or commit. As the user’s interactions with an RDM application using the JVSTM
are all done transactionally, it could be used the same mechanism to log what methods were executed
during a user’s transaction, and at the end of it, make the needed access control verifications. If no
access control restriction was violated, then the transaction could commit, otherwise it would abort, and
the system would return to the state it was, as if the user had not done anything. This postpone of the
access control verifications to the end of the transaction can bring performance advantages because
no matter how many times a method was executed, the access control verification is only done once.
Using the approach proposed in this dissertation, if a method that has an access control verification
attached to it is executed numerous times by the same user, in a cycle for instance, the number of
access control verifications grows to the number of executions, which can hurt the overall performance
of the application.
• It is important to study if the presented DMAPL constructs are enough for developers to express their
policies, or if additional constructs and additional extensions to the language should be inserted in order
to make it richer and more fit for RDM applications. For instance, Martin Fowler described the Party
pattern [Fowler, 1997] for expressing organizational structures. Can these concepts be introduced in
the DMAPL in order to make it more declarative? If so, should they replace the role subject specification
or should they be an alternative to that? Can the existence of regular expressions to denote subjects
and targets in the DMAPL bring additional advantages to developers? These type of questions can be
84
answered only after a dedicated study for it.
• Whereas delegation of rights was approached in this dissertation, it was not mentioned how to handle
cascade delegation of rights, i.e., how to deal with the delegation of delegated rights. The lack of this
feature is due to the lack of practical knowledge on what are the most intuitive ways to specify such
a policy, and in what cases should it be used. Although authors like [Damianou et al., 2001] used in
their Ponder policy language a number to denote the number of times a rule could be re-delegated, this
approach did not seem the most natural way to do it, so I opted to leave the question open to future
research.
To end this dissertation I would like to state that in my opinion, the work presented here will almost certainly
suffer modifications as developers begin to use it, and begin to define additional requirements for it. This way,
I think it will be very interesting to monitor how will developers use the solution provided. Will they declare high
level and more abstract authorization rules, or will they prefer to use one rule per method? Which application
types are more fit to use the first and the latter approach? Will developers rely heavily on amplification rules,
such that it will make sense to build entire policies based only on this type of rules? Are policies going to have
more positive, or more negative rules? Time shall provide us with the answer to these questions, so let us
wait and follow the evolution of these proposals.
85
Bibliography
Acegi. Acegi security system for spring. 2008. Homepage: http://acegisecurity.sourceforge.net.
Bauer, L., Schneider, M. A., and Felten, E. W. A general and flexible access-control system for the web. In
Proceedings of the 11th USENIX Security Symposium, pages 93–108. USENIX Association, Berkeley, CA,
USA, 2002.
Burt, C. C., Bryant, B. R., Raje, R. R., Olson, A., and Auguston, M. Model driven security: Unification of
authorization models for fine-grain access control. In EDOC ’03: Proceedings of the 7th International
Conference on Enterprise Distributed Object Computing, page 159. IEEE Computer Society, Washington,
DC, USA, 2003.
Cachopo, J. Development of Rich Domain Models with Atomic Actions. Instituto Superior Técnico, 2007.
Chiba, S. Document number gc23-3893-00. available from http://sp.unige.ch/doc/ibm/pe/pe mpl subref.ps.z.
1998.
da Cruz Ribeiro, C. N., da Cruz Marnôto Zúquete, A. V., Ferreira, P., and Guedes, P. J. T. Spl: An access
control language for security policies with complex constraints. In Network and Distributed System Security
Symposium (NDSS’01), pages 89–107. Internet Society, 2001.
Damianou, N., Dulay, N., Lupu, E., and Sloman, M. The ponder policy specification language. In POLICY
’01: Proceedings of the International Workshop on Policies for Distributed Systems and Networks, pages
18–38. Springer-Verlag, London, UK, 2001.
Dennis, J. and Horn, E. V. Programming semantics for multiprogrammed computations. Commun. ACM,
volume 26(1):pages 29–35, 1983.
Dulay, N., Lupu, E., Sloman, M., and Damianou, N. A policy deployment model for the ponder language.
In Proc. IEEE/IFIP International Symposium on Integrated Network Management (IM’2001, pages 14–18.
2001.
Emig, C., Brandt, F., Abeck, S., Biermann, J., and Klarl, H. An access control metamodel for web service-
oriented architecture. In ICSEA ’07: Proceedings of the International Conference on Software Engineering
Advances, page 57. IEEE Computer Society, Washington, DC, USA, 2007.
Evans, E. Domain-Driven Design: Tacking Complexity In the Heart of Software. Addison-Wesley Longman
Publishing Co., Inc., Boston, MA, USA, 2003.
Ferraiolo, D., Sandhu, R., and Kuhn, D. Proposed nist standard for role-based access control. ACM Trans.
Inf. Syst. Secur., volume 4(3):pages 224–274, 2001.
Fowler, M. Analysis patterns: reusable objects models. Addison-Wesley Longman Publishing Co., Inc.,
Boston, MA, USA, 1997.
Fowler, M., Rice, D., Foemmel, M., Hieatt, E., Mee, R., and Stafford, R. Patterns of Enterprise Application
Architecture. Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA, 2002.
FénixEdu. Fénixedu. 2005. Homepage: http://fenixedu.sourceforge.net.
Gamma, E., Helm, R., Johnson, R., and Vlissides, J. Design patterns: elements of reusable object-oriented
software. Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA, 1995.
Gollman, D. Computer Security. John Wiley and Sons, 1998.
87
Gosling, J., Joy, B., and Steele, G. L. The Java Language Specification. Addison-Wesley Longman Publishing
Co., Inc., Boston, MA, USA, 2005.
Groenewegen, D. and Visser, E. Declarative access control for webdsl: Combining language integration and
separation of concerns. In International Conference on Web Engineering (ICWE’08). IEEE, 2008.
Harrison, M. A., Ruzzo, W. L., and Ullman, J. D. Protection in operating systems. Commun. ACM, vol-
ume 19(8):pages 461–471, 1976.
Hu, V., Ferraiolo, D., and Kuhn, R. Assessment of access control systems. Interagency Report 7316, Nation
Institute of Standarts and Technology, 2006.
JA-SIG. Central authentication system. 2008. Homepage: http://www.ja-sig.org/products/cas/.
Kiczales, G., Hilsdale, E., Hugunin, J., Kersten, M., Palm, J., and Griswold, W. G. An overview of aspectj.
In ECOOP ’01: Proceedings of the 15th European Conference on Object-Oriented Programming, pages
327–353. Springer-Verlag, London, UK, 2001.
Kojarski, S. and Lorenz, D. H. Domain driven web development with webjinn. In OOPSLA ’03: Companion
of the 18th annual ACM SIGPLAN conference on Object-oriented programming, systems, languages, and
applications, pages 53–65. ACM, New York, NY, USA, 2003.
Lai, C., Gong, L., Koved, L., Nadalin, A., and Schemers, R. User authentication and authorization in the
java(tm) platform. In ACSAC ’99: Proceedings of the 15th Annual Computer Security Applications Confer-
ence, page 285. IEEE Computer Society, Washington, DC, USA, 1999.
Lapadula, L., Lapadula, L., and Bell, D. E. Secure computer systems: Mathematical foundations. 1973.
Lipton, R. J. and Snyder, L. A linear time algorithm for deciding subject security. J. ACM, volume 24(3):pages
455–464, 1977.
Luiz, G., Zúquete, A., and Silva, A. R. Berserk: A simple and flexible access control solution for service-
oriented architectures. In IADIS International Conference WWW/Internet, pages 622–630. 2004.
Malheiro, H. G. Controlo de acesso no sistema fénix, 2007. Unpublished Master Thesis.
Miller, M. S. Robust Composition: Towards a Unified Approach to Access Control and Concurrency Control.
Ph.D. thesis, Johns Hopkins University, Baltimore, Maryland, USA, 2006.
Miller, M. S., Miller, M. S., Shapiro, J. S., Shapiro, J. S., and Laboratories, H. P. Paradigm regained: Abstraction
mechanisms for access control. In In 8th Asian Computing Science Conference (ASIAN03, pages 224–242.
2003.
Moses, T. eXtensible Access Control Markup Language (XACML) version 1.0. Technical report, OASIS, 2003.
Niemeyer, P. Beanshell: Lightweight scripting for java. 2008. Homepage: http://www.beanshell.org/.
Oaks, S. Java security. O’Reilly & Associates, Inc., Sebastopol, CA, USA, 1998.
OJB. Object/relational bridge - ojb. 2008. Homepage: http://db.apache.org/ojb.
Pandey, R. and Hashii, B. Providing fine-grained access control for java programs. In ECOOP ’99: Proceed-
ings of the 13th European Conference on Object-Oriented Programming, pages 449–473. Springer-Verlag,
London, UK, 1999.
Rabitti, F., Bertino, E., Kim, W., and Woelk, D. A model of authorization for next-generation database systems.
ACM Trans. Database Syst., volume 16(1):pages 88–131, 1991.
88
Scott, D. and Sharp, R. Developing secure web applications. IEEE Internet Computing, volume 6(6):pages
38–45, 2002.
Scott, M. L. Programming language pragmatics. Morgan Kaufmann Publishers Inc., San Francisco, CA, USA,
2000.
Spring. Spring framework. 2008. Homepage: http://www.springframework.org.
Steiner, J. G. and Schiller, J. I. Kerberos: An authentication service for open network systems. In in Usenix
Conference Proceedings, pages 191–202. 1988.
Sterne, D. F., Tally, G. W., McDonell, C. D., Sherman, D. L., Sames, D. L., Pasturel, P. X., and Sebes, E. J.
Scalable access control for distributed object systems. In SSYM’99: Proceedings of the 8th conference on
USENIX Security Symposium, pages 16–16. USENIX Association, Berkeley, CA, USA, 1999.
Struts, A. Struts. 2008. Homepage: http://struts.apache.org.
Tomcat, A. Tomcat java web container. 2008. Homepage: http://tomcat.apache.org.
Viega, J., Bloch, J., and Chandra, P. Applying aspect-oriented programming to security. Cutter IT Journal,
volume 14(14):pages 31–39, 2001.
Zenida, P., de Sequeira, M. M., Henriques, D., and Serrão, C. Zás - aspect-oriented authorization services.
In ICSOFT (1), pages 46–54. 2006.
Zhang, G., Baurmeister, H., Koch, N., and Knapp, A. Aspect-oriented modeling of access control in web
applications. In 6th International Workshop Aspect Oriented Modeling. Chicago, USA, 2005.
Zhang, X., Oh, S., and Sandhu, R. Pbdm: a flexible delegation model in rbac. In SACMAT ’03: Proceedings
of the eighth ACM symposium on Access control models and technologies, pages 149–157. ACM, New
York, NY, USA, 2003.
89