Uniform and Modular Context-Based Access Control for ...aspect orientation. We found that the...

KATHOLIEKE UNIVERSITEIT LEUVEN

FACULTEIT INGENIEURSWETENSCHAPPENDEPARTEMENT COMPUTERWETENSCHAPPENAFDELING INFORMATICACelestijnenlaan 200A — B-3001 Leuven

Uniform and Modular Context-Based Access Control for Software

Applications

Promotoren :

Prof. Dr. ir. F. PIESSENS

Prof. Dr. ir. P. VERBAETEN

Proefschrift voorgedragen tot

het behalen van het doctoraat

in de ingenieurswetenschappen

door

Tine VERHANNEMAN

Maart 2007

KATHOLIEKE UNIVERSITEIT LEUVEN

FACULTEIT INGENIEURSWETENSCHAPPENDEPARTEMENT COMPUTERWETENSCHAPPENAFDELING INFORMATICACelestijnenlaan 200A — B-3001 Leuven

Uniform and Modular Context-Based Access Control for Software

Applications

Jury :

Prof. G. De Roeck , voorzitter

Prof. F. Piessens, promotor

Prof. P. Verbaeten, promotor

Prof. W. Joosen

Prof. E. Duval

Prof. B. Van den Bosch

Prof. J. Ligatti (University of South Florida, USA)

Dr. B. De Win

Proefschrift voorgedragen tot

het behalen van het doctoraat

in de ingenieurswetenschappen

door

Tine VERHANNEMAN

U.D.C. 681.3∗D46

Maart 2007

c©Katholieke Universiteit Leuven – Faculteit IngenieurswetenschappenArenbergkasteel, B-3001 Heverlee (Belgium)

Alle rechten voorbehouden. Niets uit deze uitgave mag worden vermenigvuldigden/of openbaar gemaakt worden door middel van druk, fotocopie, microfilm,elektronisch of op welke andere wijze ook zonder voorafgaande schriftelijke toe-stemming van de uitgever.

All rights reserved. No part of the publication may be reproduced in any formby print, photoprint, microfilm or any other means without written permissionfrom the publisher.

D/2007/7515/12ISBN 978-90-5682-780-9

Abstract

The trend of an increased computerization in our society manifests itself, forinstance, in the development of e-government and e-health applications. Not onlydoes an increased computerization fulfill the promise of an improved automationand efficiency, it also entails a greater risk for abuse on a larger scale. Thisabuse can be prevented by enforcing that software applications are used correctly.This correct use is specified by means of a policy that captures when accessto an asset should be granted or denied. This policy should be enforced bymeans of access control. The sensitivity of the data that is processed by theseapplications is usually so high that access should be restricted to a minimumnumber of authorized users. The enforcement of an expressive policy becomeseven more crucial, as organizations increasingly open up their infrastructure tooutsiders, such as customers and suppliers. To enforce expressive access policies,an access technology should support context-based access control by accountingfor context information when taking access decisions. This context informationmay, for instance, include information concerning the state of the application, aswell as the circumstances in which access to a sensitive resource is sought.

Due to the complexity and scale of contemporary software systems, the inte-gration of context-based access control constitutes a major engineering challenge.It is hard to obtain a uniform access control enforcement in (the large numberof) applications that are deployed within an organization. This uniformity iseven more jeopardized as access control evolves. Technologies should supportevolution of access control, because the adaptability of policies and accesscontrol enforcement is a prerequisite to respond adequately to changing andnew requirements. Based on an assessment of state-of-the-art access controltechnologies, we found that these technologies fail to reconcile these requirementsbecause they fail to modularize the enforcement of context-based policies.

The solution that we propose, can be described in terms of two contributions,namely (1) the definition of the concepts access interface and view connector and(2) the development of an access control service.

An access interface enables a uniform and centralized enforcement of a context-based access policy in a number of applications by representing a domain model

i

ii

that provides the information that is needed to formulate the access policy. Itdoes this in terms of the abstractions that are common for access control, namelyprincipal, object and action. For each application, a view connector is written tobind this access interface to the application.

Secondly, based on these concepts we have developed an access controlservice that modularizes the enforcement of context-based policies by means ofaspect orientation. We found that the support that Aspect-Oriented SoftwareDevelopment (AOSD) provides to modularize crosscutting concerns is useful andnecessary to modularize the access control concern. This finding was substantiatedby the development of two prototypes, respectively based on the aspect-orientedframework Java Aspect Components and the aspect-oriented language CaesarJ.

As a third contribution, an extensive list of evaluation criteria has been drawnup that can be used to evaluate access control technologies. Based on these criteria,an assessment has been made of the proposed approach.

Acknowledgements

In retrospect, the most rewarding aspect to me is that this project crosscutsso many interesting research domains. This project started with listing thesecurity requirements of the health care application domain, and ended up here,on this joinpoint of software and security engineering, access control policies andtechnologies, programming languages and middleware. For me, this has been atruly enriching experience, which would not have been possible without the helpof many people.

I am especially thankful to my advisor Prof. Frank Piessens who helped me totake the hurdles. I greatly appreciate his never-failing optimism and enthusiasmwith which he guided me on a daily basis, and I will not forget how he counteredmy doubts with his everlasting motto “no risk, no fun!”.

I am also grateful to Prof. Pierre Verbaeten for critically reviewing this thesis.Prof. Wouter Joosen’s insights helped me to position this work in a broaderperspective; Thank you for leading the way. I would like to express my gratitudeto Prof. Erik Duval for his constructive feedback.

This project builds upon the work of Dr. Bart De Win, who I would like tothank for contributing to this research, coauthoring papers, and proofreading thisthesis. I also thank Dr. Eddy Truyen for all his ideas with respect to this work,and for introducing me to aspect-oriented software development.

I would like to thank Prof. Jarred Ligatti from the University of South Floridaand Prof. Bart Van den Bosch from U.Z. Leuven for accepting to be members ofthe jury, and Prof. Guido De Roeck for chairing the jury.

I am indebted to the Institute for the Promotion of Innovation by Science andTechnology in Flanders (IWT-Vlaanderen) for funding this research.

The department has always felt like home to me, and I want to thank allmy colleagues for creating this great atmosphere. The list of people is toolong to completely enumerate here, but I would like to thank in particular myformer office mates Kris Verlaenen, Liesbeth Jaco, Jan Smans, Bert Lagaisse,Johan Gregoire, as well as Yves Younan, Frans Sanen, Thomas Heyman, Dr.Riccardo Scandariato, and the SECDAM group for the interesting research-relateddiscussions and inspiring breaks. Special thanks go to Dr. Lieven Desmet and Davy

iii

iv

Preuveneers. I would also like to thank the students who contributed to this workas part of their master’s thesis.

I am lucky to have a number of very good friends. I would like to thank themall for their continued support and all the joyful moments, such as the #ramselweekends, the weekly tennis shots, the cw2002 gatherings and so much more.Finally, I would like to thank my parents and my brother Dries for their supportand encouragements.

Tine VerhannemanMarch 2007

Contents

Contents v

List of Figures ix

List of Acronyms xi

1 Introduction 11.1 Access Control Challenges for Contemporary Distributed Applications 11.2 Separation of Concerns for Access Control Enforcement . . . . . . 31.3 Overview of the Chapters . . . . . . . . . . . . . . . . . . . . . . . 5

2 Context-Based Access Control for Medical Applications 72.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.2 Legislation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.2.1 European Data Privacy Directive . . . . . . . . . . . . . . . 92.2.2 US Health Insurance Portability and Accountability Act . . 10

2.3 Security Principles and Challenges for Health Care Systems . . . . 112.3.1 Organizational Measures . . . . . . . . . . . . . . . . . . . . 112.3.2 Technical Measures . . . . . . . . . . . . . . . . . . . . . . . 132.3.3 Authorization . . . . . . . . . . . . . . . . . . . . . . . . . . 162.3.4 Principles addressed in this Thesis . . . . . . . . . . . . . . 17

2.4 A Representative Health Care Access Control Policy . . . . . . . . 182.5 Context-Based Access Control for Health Care . . . . . . . . . . . 202.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3 Evaluation of State-of-the-Art Access Control Technologies 233.1 Access Control Policies and Models . . . . . . . . . . . . . . . . . . 24

3.1.1 Access Control Policies . . . . . . . . . . . . . . . . . . . . 243.1.2 Access Control Management . . . . . . . . . . . . . . . . . 263.1.3 Access Control Information . . . . . . . . . . . . . . . . . . 27

3.2 Access Control Architecture and Mechanism . . . . . . . . . . . . . 29

v

vi CONTENTS

3.2.1 Access Control Functions . . . . . . . . . . . . . . . . . . . 293.2.2 Access Control Software Decomposition . . . . . . . . . . . 323.2.3 Overview of an Access Control Enforcement Architecture . 33

3.3 Evaluation Criteria for Access Control Technologies . . . . . . . . 343.3.1 Expressiveness . . . . . . . . . . . . . . . . . . . . . . . . . 343.3.2 Evolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363.3.3 Uniformity . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

3.4 State-of-the-Art Access Control Technologies . . . . . . . . . . . . 383.4.1 Java Authentication and Authorization Service . . . . . . . 383.4.2 Java 2 Enterprise Edition . . . . . . . . . . . . . . . . . . . 413.4.3 COM+ and .NET . . . . . . . . . . . . . . . . . . . . . . . 453.4.4 CORBA Security Service . . . . . . . . . . . . . . . . . . . 463.4.5 Tivoli Access Manager . . . . . . . . . . . . . . . . . . . . . 513.4.6 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

3.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

4 Uniform Enforcement of Evolving Application-Domain-SpecificPolicies 594.1 Overview of the Approach . . . . . . . . . . . . . . . . . . . . . . . 604.2 Access Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

4.2.1 A Health Care-Specific Access Interface Example . . . . . . 624.2.2 Access Interface Syntax . . . . . . . . . . . . . . . . . . . . 664.2.3 Access Interface Semantics . . . . . . . . . . . . . . . . . . 66

4.3 View Connector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 684.3.1 View Connector for a Health Care Application . . . . . . . 684.3.2 View Connector Specification Syntax . . . . . . . . . . . . . 724.3.3 View Connector Semantics . . . . . . . . . . . . . . . . . . 74

4.4 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 764.4.1 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . 764.4.2 Realization of the View Connector . . . . . . . . . . . . . . 794.4.3 Implementation Alternatives and Extensions . . . . . . . . 79

4.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

5 A Modular Access Control Service for Application-Domain-Specific Policies 815.1 Aspect-Oriented Software Development . . . . . . . . . . . . . . . 825.2 Access Control Service Overview . . . . . . . . . . . . . . . . . . . 835.3 Prototype Implementation in Java Aspect Components . . . . . . . 86

5.3.1 Java Aspect Components . . . . . . . . . . . . . . . . . . . 865.3.2 Design of the JAC Prototype . . . . . . . . . . . . . . . . . 905.3.3 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

5.4 Prototype Implementation in CaesarJ . . . . . . . . . . . . . . . . 935.4.1 CaesarJ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

CONTENTS vii

5.4.2 Pluggable Authentication Module Framework . . . . . . . . 975.4.3 Implementation of the Access Control Service . . . . . . . . 975.4.4 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

5.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

6 Evaluation and Related Work 1076.1 A Thorough Evaluation of the Access Control Service . . . . . . . 107

6.1.1 Expressiveness . . . . . . . . . . . . . . . . . . . . . . . . . 1086.1.2 Policy Management . . . . . . . . . . . . . . . . . . . . . . 1106.1.3 System Evolution . . . . . . . . . . . . . . . . . . . . . . . . 1166.1.4 Scalability . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1176.1.5 Assurance . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1186.1.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

6.2 Applicability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1216.3 Positioning in a Broader Perspective . . . . . . . . . . . . . . . . . 121

6.3.1 Security Engineering . . . . . . . . . . . . . . . . . . . . . . 1216.3.2 Policy Languages and Frameworks . . . . . . . . . . . . . . 1226.3.3 AOSD and the Security Concern . . . . . . . . . . . . . . . 1236.3.4 Policy Enforcement Mechanisms . . . . . . . . . . . . . . . 1246.3.5 Context-Based Access Control . . . . . . . . . . . . . . . . 124

7 Conclusion 1277.1 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1287.2 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1287.3 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129

Bibliography 131

List of Publications 141

Biography 143

Dutch Summary

viii CONTENTS

List of Figures

2.1 Sensitivity of Health Care Data (based on [DNdB04]) . . . . . . . 142.2 Compartmentation of Health Care Data (adopted from [And96a]) . 152.3 Phases of a contact [Van96] . . . . . . . . . . . . . . . . . . . . . . 19

3.1 XACML Dataflow [OASa] . . . . . . . . . . . . . . . . . . . . . . . 303.2 Access Control Criteria . . . . . . . . . . . . . . . . . . . . . . . . 343.3 Relation between adaptability and software decomposition . . . . . 373.4 JAAS Policy File . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393.5 A Custom Permission . . . . . . . . . . . . . . . . . . . . . . . . . 403.6 J2EE Deployment Descriptor (based on [BCE+06]) . . . . . . . . . 433.7 Policy Configuration and Enforcement Subcontracts (from [Mon03]) 443.8 Declarative and Programmatic Access Control in .NET . . . . . . 453.9 Access Control Model (from [Gro02b]) . . . . . . . . . . . . . . . . 473.10 Access Decision Object . . . . . . . . . . . . . . . . . . . . . . . . . 483.11 CORBA Domain Access Policy (from [Gro02b]) . . . . . . . . . . . 483.12 Interface of the Attribute Retriever . . . . . . . . . . . . . . . . . . 493.13 Object Security Attributes (from [Bez02b]) . . . . . . . . . . . . . 503.14 Resource Access Decision Facility (from [BDB+99]) . . . . . . . . . 513.15 Protected Object Space (based on [Kar03]) . . . . . . . . . . . . . 523.16 AZN API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 533.17 Evaluation of State-of-the-Art Technologies . . . . . . . . . . . . . 57

4.1 Top-down integration of an access control policy . . . . . . . . . . 604.2 Realization with a centralized authorization engine . . . . . . . . . 614.3 Policy Specification in Ponder . . . . . . . . . . . . . . . . . . . . . 634.4 Access Control Matrix . . . . . . . . . . . . . . . . . . . . . . . . . 644.5 Access Interface for the Health Care Domain . . . . . . . . . . . . 654.6 Access Interface EBNF notation . . . . . . . . . . . . . . . . . . . 664.7 Pregnancy ICP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 694.8 ICP-application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 704.9 View Connector Specification . . . . . . . . . . . . . . . . . . . . . 71

ix

x LIST OF FIGURES

4.10 View Connector EBNF Syntax . . . . . . . . . . . . . . . . . . . . 734.11 Alternative ICP View Connector . . . . . . . . . . . . . . . . . . . 76

5.1 Access Control Service . . . . . . . . . . . . . . . . . . . . . . . . . 835.2 Collaboration Diagram . . . . . . . . . . . . . . . . . . . . . . . . . 855.3 Subject and Associated Principals . . . . . . . . . . . . . . . . . . 855.4 Authentication Aspect Component Configuration . . . . . . . . . . 885.5 JAC prototype: run-time . . . . . . . . . . . . . . . . . . . . . . . 905.6 PasswordModule Collaboration Interface . . . . . . . . . . . . . . . 945.7 Generated Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . 965.8 Pluggable Authentication Module Framework in CaesarJ . . . . . . 985.9 HealthCare Access Interface in CaesarJ . . . . . . . . . . . . . . . 995.10 Authorization Engine . . . . . . . . . . . . . . . . . . . . . . . . . 995.11 Access Control Service in CaesarJ . . . . . . . . . . . . . . . . . . 1025.12 Summarizing Table: JAC and CaesarJ . . . . . . . . . . . . . . . . 1055.13 Comparison of the two prototypes . . . . . . . . . . . . . . . . . . 106

6.1 Access Control Criteria . . . . . . . . . . . . . . . . . . . . . . . . 1086.2 Evaluation of the Access Control Service . . . . . . . . . . . . . . . 120

List of Acronyms

ACI Access Control Information, 27ACL Access Control List, 52ADO Access Decision Object, 47AOSD Aspect-Oriented Software Development, 82AZN API Authorization Application Programming Inter-

face, 53

COM+ Component Object Model plus, 45CORBA Common Object Request Broker Architecture, 46

DAC Discretionary Access Control, 25DAS Dynamic Attribute Service, 50

EAS External Authorization Server, 55EJB Enterprise Java Bean, 42

FAF Flexible Authorization Framework, 123

GP General Practitioner, 62

HIPAA Health Insurance Portability and AccountabilityAct, 10

ICP Integrated Care Pathways, 68

J2EE Java 2 Enterprise Edition, 41JAAS Java Authentication and Authorization Service,

38, 97JAC Java Aspect Components, 86JACC Java Authorization Contracts for Containers, 42

xi

xii List of Acronyms

MAC Mandatory Access Control, 25MDA Model-Driven Architecture, 121MDSOC Multi Dimensional Separation Of Concerns, 123

ODM Object Domain Mapping, 49OMG Object Management Group, 46ORB Object Request Broker, 46OSA Object Security Attributes, 49

PAM Pluggable Authentication Module, 97PAP Policy Administration Point, 31PDP Policy Decision Point, 31PEP Policy Enforcement Point, 29PIM Platform Independent Model, 122PIP Policy Information Point, 31PoET Policy Enforcement Toolkit, 124POJO Plain Old Java Object, 86POP Protected Object Policy, 52PSM Platform Specific Model, 122

RAD Resource Access Decision (Facility), 49RBAC Role-Based Access Control, 25RTTI Run-time Type Information, 92

SAML Security Assertion Markup Language, 122SDMM Security Domain Membership Management, 48SecureUML Secure Unified Modelling Language, 122

TAM Tivoli Access Manager, 51TRBAC Temporal Role-Based Access Contol, 27

VPL View Policy Language, 122

XACML eXtensible Access Control Markup Language, 29

Chapter 1

Introduction

1.1 Access Control Challenges for Contemporary

Distributed Applications

The security of software applications is crucial in the computerized society oftoday. Software applications are increasingly used to automate processes in alarge number of application domains, such as for example e-commerce and healthcare. An access control policy needs to be in place to protect these applicationsfrom unauthorized access. Such a policy specifies the conditions that must hold foran access to be granted or denied. Access control is a widely used technique thatverifies whether each access to an asset conforms to the applicable access controlpolicy.

Application domains, such as health care, have demanding security require-ments, as they deal with highly sensitive data. According to the principle ofleast privilege [SS75], access to this data should be kept to a minimum. Relyingsolely on perimeter security (i.e. firewall and intrusion detection systems) does notsuffice. The growing trend of sharing internal business processes with, for example,customers and suppliers, makes the distinction between inside and outside fuzzy.Web services for example require the exchange of XML messages through thefirewall. Even if such a clear distinction can be made, it is highly recommendableto restrict the use by insiders (e.g., employees) to what is strictly necessary inorder to prevent misuse. To meet this requirement, an access control technologyshould support the enforcement of expressive access control policies that accountfor context information when taking an access control decision. This decision isthe outcome of the application of an access control policy to an access request.Typical examples of context information are the circumstances in which access toa sensitive resource is sought or the current state of this resource. The enforcementof context-based policies is referred to as context-based access control.

1

2 Introduction

The key challenge in the design of a security infrastructure is the ongoinggrowth of distributed software systems in both scale and complexity. Anorganization has to secure a large number of applications, which may be deployedon heterogeneous systems. The policy that needs to be enforced within theseapplications is tailored to a particular organization or application domain and isdetached from a specific application. In general, it is hard to keep the accesscontrol enforcement for all these applications uniform, the more so becauseaccess policies tend to be subject to change over time. This change may betriggered by requirements imposed by legislation, a changing deployment setting,or the observation that the current installed security system does not meet theexpectations.

In this thesis, we address the security of applications by providing accesscontrol enforcement on the application level. This application-level access controlallows to protect fine-granular application resources. Application-level securitycomplements network, operating system and database layer security in that itprotects the application’s assets.

A number of technologies are already available that address application-levelaccess control. However, we argue that they fall short: either their expressivenessis too limited so that they do not support context-based policies, or access controlenforcement needs to be entangled in the application. The latter renders it hardto adapt the policy and its enforcement to changing requirements. At the basisof these shortcomings, lies the failure to modularize context-based access controlenforcement.

The Challenges Addressed in this Thesis. The goal of this thesis can besummarized by the following three challenges:

1. the enforcement of context-based access control policy to meet the high accesscontrol requirements of contemporary applications.

2. the support for the evolution of the access control policy and its enforcement,so that the system can cope with changes in the access policy, in thedeployment environment and in the application.

3. the support for a uniform access control enforcement of one commonaccess control policy to manage the complexity of keeping access controlenforcement consistent across a number of applications and environments.

Our solution should meet all of these three requirements. In the next section, wegive an overview of our approach.

1.2 Separation of Concerns for Access Control Enforcement 3

1.2 Separation of Concerns for Access Control

Enforcement

Separation of Concerns for Security. The starting point of our approachis the observation that separation of concerns is an essential principle to buildsecure systems [DPJV02]. The term “separation of concerns” was used by Dijkstrain [Dij82]:

Let me try to explain to you, what to my taste is characteristic for allintelligent thinking. It is, that one is willing to study in depth an aspectof one’s subject matter in isolation for the sake of its own consistency,all the time knowing that one is occupying oneself only with one of theaspects. We know that a program must be correct and we can studyit from that viewpoint only; we also know that it should be efficientand we can study its efficiency on another day, so to speak. In anothermood we may ask ourselves whether, and if so: why, the program isdesirable. But nothing is gained –on the contrary!– by tackling thesevarious aspects simultaneously. It is what I sometimes have called “theseparation of concerns”, which, even if not perfectly possible, is yet theonly available technique for effective ordering of one’s thoughts, that Iknow of. This is what I mean by “focusing one’s attention upon someaspect”: it does not mean ignoring the other aspects, it is just doingjustice to the fact that from this aspect’s point of view, the other isirrelevant. It is being one- and multiple-track minded simultaneously.(On the role of scientific thought-30th August 1974)

Separation of concerns lies at the basis of procedural programming andobject orientation. Closely related is the statement by Parnas [Par72] that thedecomposition into modules should be driven by information hiding such thatmodules hide the complex design decisions that are likely to change. In thisthesis, the separation of concerns will be used in two senses, namely in termsof the delineation of the responsibilities between stakeholders (with their ownviewpoint) involved in the development of the software system, and secondly (interms of software decomposition) the encapsulation of the concerns of each of thesestakeholders in well-defined and separated modules. Separation of concerns aimsto reduce the complexity of the problem at hand.

However, it is hard to modularize security due to its pervasive nature.According to De Win et al. [DPJV02] this pervasiveness manifests itself in twoways.

1. Secure Coding: Secure coding refers to the quality of the implementation ofapplication functionality. Bugs such as buffer overflows, input validation inapplication code, can introduce severe security problems. Secure coding is

4 Introduction

pervasive, as it requires from the developer to exhibit a defensive attitude sothat his code cannot be abused. Some of these problems can be removed byproviding compiler or run-time support.

2. Crosscutting Security Concerns: This form of pervasiveness relates to logicthat is introduced to implement security requirements. Examples are accesscontrol and audit. The pervasiveness lies in the specific way these concernsinteract with the application. The implementation of these concerns typicallyleads to code that is scattered all over the application and that is moreoverentangled in the business logic.

This thesis aims at the development of separation-of-concern techniques for thelatter, and in particular for crosscutting access control logic. The nature of theinteraction between the access control concern and the application is such thatit could be argued that the access control logic should be hard-coded in theapplication. The main drawback of this approach is that the access policy has to beknown upfront and cannot be adapted to meet changing requirements afterwards.It also requires that the system is completely secure from the start. This objectiveis ambitious but not always realistic as demonstrated by numerous vulnerabilityreports. Thirdly, it requires from the application developer an extensive knowledgeabout the security concern. To our mind, complexity is reduced if each of thestakeholders can focus on his or her own domain of expertise.

The Promise of Aspect-Oriented Software Development (AOSD). Theseparation of access logic from the application such that the policy can beexternally specified is not a new idea. Most state-of-the-art access controltechnologies encapsulate the access decision logic in an authorization engine, orare implemented as an access control service for a particular component platform.These approaches either do not exhibit the desired level of separation of concernsor do not have the capability to enforce context-based access policies.

Aspect orientation has been identified as a promising technique to support theevolution of crosscutting concerns in general and of crosscutting security concernsin particular [DS00]. The motivation for aspect orientation lies in the observationthat well-established separation-of-concern techniques such as object orientationfall short in modularizing crosscutting concerns. This is due to the fact that thesetechniques only support the decomposition of software according to one concern(i.e. the application logic). As a result, the implementation of context-based accesscontrol is then spread over and entangled with the application, which precludesthe evolution of access control. Aspect orientation offers support to modularizecrosscutting concerns.

Our Contributions. First, we propose an approach that introduces an accesscontrol viewpoint on the application. This viewpoint allows for the enforcement of

1.3 Overview of the Chapters 5

context-based access control policies by taking into account application-domain-specific information, but at the same time abstracts from the details of a specificapplication. This access control viewpoint introduces an abstraction layer thatis crucial for the uniform enforcement of one common, organization-wide accesscontrol policy in a number of different applications that are deployed withinan organization. It does this by providing a domain model that captures theinformation needed by the policy in terms of abstractions that are common toaccess control, namely principal, object and action. We will show how thisapproach naturally supports the separation of the concerns of the security officer(who writes down the policy), and the application deployer (who tunes the accesslogic to the application’s needs). This separation of concerns improves the supportfor the evolution of the access policy and its enforcement.

The enforcement of context-based policies is crosscutting due to its tightcoupling with the application. As a second contribution, we demonstrate thataspect-oriented techniques are needed and how they can be used to implementaccess control enforcement in a modular way. This is done by the design ofa modular access control service and the implementation of two prototypes,respectively based on the aspect-oriented framework Java Aspect Components(JAC) and the aspect-oriented language CaesarJ.

Thirdly, we identify an extensive list of evaluation criteria that can be used tocharacterize access control technologies, and apply it to our approach.

1.3 Overview of the Chapters

The remainder of this thesis is structured as follows. In Chapter 2, we motivatethe problem statement by means of requirements that are elicited from the healthcare application domain. Chapter 3 explains access control terminology andcontains an evaluation of current state-of-the-art technologies. The scope of thisdiscussion is limited to those technologies that are employed widely in practice.The definition of an abstraction layer for access control that enables a uniform andcentralized enforcement is the topic of Chapter 4. Chapter 5 presents a design of amodular access control service that is bound to the application by means of aspectorientation. Two prototype implementations respectively based on the aspect-oriented framework Java Aspect Components and the aspect-oriented languageCaesarJ serve as proof of concept. Chapter 6 evaluates our approach by applyingan extensive list of evaluation criteria. This chapter also contains a discussion ofrelated research. Chapter 7 concludes this thesis.

6 Introduction

Chapter 2

Context-Based Access

Control for Medical

Applications

In the previous chapter, we briefly described the challenges that are associatedwith the enforcement of access control in contemporary distributed applications.In this chapter, we will motivate this further in the context of the health careapplication domain. In particular, we will argue that the health care applicationdomain requires the enforcement of context-based access policies.

Our motivation starts with a description of trends that call for an adequateprotection of medical data in Section 2.1, and a brief summary of the legal andregulatory framework for privacy and security covering the legislation of boththe European Union and the United States in Section 2.2. Section 2.3 lists acomprehensive set of security requirements medical organizations should complywith. Section 2.4 presents a representative access control policy. Section 2.5 givesa working definition of context-based access control and Section 2.6 concludes thischapter.

The contents treated in this chapter, are based on the following paper [VJP+03]:T. Verhanneman, L. Jaco, B. De Win, F. Piessens, and W. Joosen, AdaptableAccess Control Policies for Medical Information Systems, Distributed Applicationsand Interoperable Systems, 4th IFIP WG 6.1 International Conference, DAIS2003 [VJP+03]

7

8 Context-Based Access Control for Medical Applications

2.1 Introduction

The ever-growing application of information technology in the health care industrycalls for the installation of a security policy that is adequate to protect medicalresources. In the preamble of the Health Insurance Portability and AccountabilityAct (HIPAA) privacy rule [Sec02a], the following trends are identified:

• an increased use of interconnected electronic information systems for storingand transmitting health information, allowing to share a large number ofmedical data with a large number of people at a time.

• an increased number of people and organizations have access to healthcare data due to a rapid growth of integrated health care delivery systems,managed care and outsourcing.

• an increased ability to collect highly sensitive information about a person’scurrent and future health status as a result of advances in scientific research,such as for example genetic information.

The right for privacy is considered as the fundamental right “to be left alone”,including the “freedom from intrusion or observation into one’s private affairs, theright to maintain control over certain personal information, and the freedom toact without outside interference” [BRR99].

Privacy is a sine qua non for the provision of high quality health care.Nowadays, there is an increasing public concern about the loss of privacy. Thisconcern is reflected in several legislative initiatives, which will be discussed in thenext section.

2.2 Legislation

Current legislation actually provides for two kinds of rights and duties.First, the law prescribes the circumstances for medical data to be collected,

stored and used, and the authorization rules to access the data. This is inputfor the access control policy that a health care organization should manage. TheHIPAA Privacy Rule is the an example of such legislation [Sec02a].

Second, the law also sets some standards on how well the policy should beenforced. In other words, if a health care organization stores and processes medicaldata, and outsiders (or malicious insiders) manage to get unauthorized access tothe data, the organization could still be prosecuted and convicted if it could beshown that the data was not appropriately protected against unauthorized access.Based on this legislation, health care institutions formulate policies, containingboth organizational and technical security measures. The second kind of legislationin particular, is important from the point of view of the enforcement of an IT policy.

2.2 Legislation 9

The term IT policy is used to denote those measures that are to be enforced bythe whole of hardware and software systems.

In this section, a short survey is given of the relevant legislation.

2.2.1 European Data Privacy Directive

Considering the protection of health information in the EU, the Data ProtectionLaw (Directive 95/46/EC) should be mentioned first [EC95]. It does not onlyapply to personal identifiable data in general, but also to personal identifiablemedical data, and to both automatic and manual processing. Article 17 requires:

Member States shall provide that the controller must implementappropriate technical and organizational measures to protect personaldata against accidental or unlawful destruction or accidental loss,alteration, unauthorized disclosure or access, in particular where theprocessing involves the transmission of data over a network, and againstall other unlawful forms of processing. Having regard to the state of theart and the cost of their implementation, such measures shall ensure alevel of security appropriate to the risks represented by the processingand the nature of the data to be protected.

Recommendation R(97)5 of the Council of Europe (“on the Protection ofMedical Data”) [Cou97] provides further guidance for health care providers.Recommendations have no legally binding character for the member states, butare incentives for certain behavior. The text of the recommendation contains thefollowing part:

9.1 Appropriate technical and organizational measures shall betaken to protect personal data - processed in accordance with thisrecommendation - against accidental or illegal destruction, accidentalloss, as well as against unauthorised access, alteration, communicationor any other form of processing. Such measures shall ensure anappropriate level of security taking account, on the one hand, of thetechnical state of the art and, on the other hand, of the sensitive natureof medical data and the evaluation of potential risks. These measuresshall be reviewed periodically.

We argue that the emphasis on appropriate measures and periodical reviewnecessitates flexibility and configurability of the IT enforced access control policy.The recommendation indicates that protection of personal data may need to beincreased if the security technology becomes available.


2.2.2 US Health Insurance Portability and Accountability

Act

Contrary to the European Union, in the US there is no explicit constitutionalrecognition of privacy. Therefore, there is no comprehensive legislation, but rathera patchwork of laws, each directed to a certain domain. Drawback of this approachis the large amount of laws enacted, advantage is that specific issues of a certaindomain are dealt with in their very own way.

The specific law concerning the protection of individually identifiable healthinformation is included in the Health Insurance Portability and AccountabilityAct of 1996, also known as HIPAA.

HIPAA is considered the most significant health care legislation passed inyears. The law contains several sections, including rules on electronic transactions,national identifiers, patient privacy, and data security. It obliges health careorganizations to use information and communication technology to increaseefficiency, but it also addresses the problems of deploying these technologies.Therefore all health care organizations that maintain or transmit electronic healthinformation must comply, and there are severe civil and criminal penalties forthose that do not.

In the context of this thesis, two rules of the comprehensive HIPAA regulationare important, namely the Privacy Rule [Sec02a] and Security Rule [Sec02b]. TheSecurity Rule applies to protected health information in electronic form only,whereas the Privacy Rule applies to protected health information in any form.The latter sets forth which uses and disclosures are authorized or required andwhich rights patients have with respect to their health information.

The relationship between the Privacy Rule and the Security Rule can besummarized by saying that the former sets the policy to which personal healthinformation should be subjected, while the latter specifies which implementationis obligatory for the enforcement of this policy and which reasonable efforts shouldbe made. It describes the necessity for standards at all stages of transmission andstorage of electronic health care information to ensure integrity and confidentialityof the records at all phases of the process, before, during and after electronictransmission. It defines administrative, physical and technical safeguards toprotect the confidentiality, integrity and availability of electronic protected healthinformation.

Regarding access control, a rewording in the Final Security Rule [Sec02b] incomparison with the Proposed Rule [Sec00] can be noticed:

There was no intent to limit the implementation features to thenamed technologies and this final rule has been reworded to makeit clear that use of any appropriate access control mechanism isallowed. Proposed implementation features titled “Context-basedaccess”, “Role-based access”, and “User-based access” have been

2.3 Security Principles and Challenges for Health Care Systems 11

deleted and the access control standard at Sec. 164.312(a)(1) statesthe general requirement.

Features such as context-based, role-based and user-based access control areno longer explicitly mentioned in the rule. Instead, the requirement is thatappropriate access control should be provided. As in the European legislation,the emphasis is on the fact that technical enforcement should be appropriate withrespect to risk.

2.3 Security Principles and Challenges for Health

Care Systems

All regulations state that appropriate technical and organizational measures needto be in place to protect against unauthorized access. Security practitioners,researchers and federal agencies have formulated security principles to guide anorganization in the implementation of these legislative rules. In this sectionwe will give a comprehensive compilation of principles that were presentedby Anderson [And96c, And96b], Buckovich et al. [BRR99] and the NationalInstitute of Standards and Technology (NIST) [BJH+04]. These principles aresubdivided in three groups. Section 2.3.1 lists the principles that relate toorganizational measures. The technical measures that should be in place arediscussed in Section 2.3.2. Section 2.3.3 groups the principles that form the basisof authorization. In Section 2.3.4 we will narrow the scope by highlighting theprinciples that are addressed in this thesis.

2.3.1 Organizational Measures

Principle 1 Security/privacy/confidentiality policies, procedures, regulations andsanctions should be in place for all entities with exposure or access to individualhealth information (adopted from [BRR99, Principle 26]).

Regarding this principle, the NIST guideline [BJH+04] on the implementationof the HIPAA Security Rule [Sec02b] encompasses among its administrativesafeguards policies and procedures:

• to prevent, detect, contain, and correct security violations, resulting from anextensive assessments of the risks, ranging from computer viruses to naturaldisasters [BJH+04, Section 4.1].

• to ensure that all personnel have appropriate access and to prevent thosethat are not authorized, from obtaining access to health care data [BJH+04,Section 4.3].


• to authorize access consistently, e.g. by deciding how and on which basisaccess is granted to users [BJH+04, Section 4.4]. Section 2.3.3 elaborates onthe appropriateness of access.

• to address security incidents [BJH+04, Section 4.6].

• to respond to emergency or other occurrence (e.g. fire, vandalism, systemfailures, and natural disaster), i.e. a contingency plan [BJH+04, Section 4.7].

The definition of a workable policy is challenging due to inconsistent policiesbetween organizations that exchange health care data, and demands on time andfinancial resources [Kal02]. For example, the introduction of smart card technologyadds a considerable overhead to each transaction, i.e. for the insertion of the smartcard and the PIN, and the calculation of a signature [DNdB04]. Also ignoranceof health care staff towards security measures impedes their introduction [Kal02].Implementing security awareness and training is therefore crucial [BJH+04, Section4.5], as stated by the following principles:

Principle 2 All entities involved with health care information have a responsibilityto educate themselves, their staff, and consumers on issues related to theseprinciples (adopted from [BRR99, Principle 25]).

This principle is also important from the perspective of usability. Cra-nor [Cra05] identifies the following three approaches to make security more usable:(1) invisible security or (2) intuitive and visible security, and (3) training.

Principle 3 The introduction of policies and procedures require the assignment ofpersons who are held responsible for their implementation [BJH+04, Section 4.2].

A security official should be assigned who is held responsible for the overalldevelopment and implementation of the required procedures. For each medicalrecord, one of the physicians on the care team should take the responsibility tocontrol access to that record [And96c, Principle 3]. This responsible physician, forexample, determines by whom the data may be accessed, and notifies the patientof any changes in this set of people. Another example is that a person or entity isheld responsible for the integrity of the data they create, maintain, use, transmit,collect or disseminate [BRR99, Principle 7].

According to Anderson [And96a], “the likelihood that information will beimproperly disclosed depends on two things: its value, and the number of peoplewho have access to it”. As the computerization of health records facilitates theaggregation of a large number of data at a time, this opens the avenue to abusessuch as the advertisement of products to a particular group of patients. Thereis also a concern that this aggregate data can be used against an individual inemployment, in access to care, and in applying for insurance [BRR99, Principle18].


Principle 4 Measures should be taken to prevent the aggregation of large amountsof data [And96c, Principle 8].

Nowadays, a large number of parties are involved in the care giving processor in the processing of health care information. Health care organizations may,for instance, outsource billing or rely on vendors to provide system support. Thisdistribution of medical data renders securing the data even harder, and calls forthe following principle:

Principle 5 A business associate, a health care organization appeals to, mayreceive, maintain and transmit health information on the organization’s behalf,provided that the latter has assurances that the data is safeguarded appropriately[BJH+04, Section 4.9].

Last but not least, appropriate security is necessarily dynamic. Reviewingthe policies, procedures and their implementation is necessary to evaluate theireffectiveness [And96c, Principle 9], and to respond to changes in environment andoperation [BJH+04, Section 4.8]. This also includes a continual incorporation ofnew technologies [BRR99, Principle 27].

Principle 6 Policies and procedures should be reviewed periodically.

2.3.2 Technical Measures

Because of the increased specialization of care providers, and the increasedcomplexity of care procedures, the size of the team of care providers that dealswith one patient grows, e.g. teams of ten to fifty are fairly common. Also, healthcare data can be decentralized and accessed remotely, whereby communicationnetworks outside the physical boundaries of the health care facility are used toshare information. This requires that the organizational measures presented inSection 2.3.1 are backed up by technical measures. The following discussionincludes both physical safeguards and safeguards that are integrated in theinformation system.

Principle 1 Access Control — Technical procedures and policies need to be inplace to prevent unauthorized access to health care data.

Firstly, physical access to the facilities housing electronic information shouldbe restricted [BJH+04, Section 4.10]. In a hospital, a large number of devicesand workstations are located in the health care facilities, which can be freelyaccessed by patients and visitors. Care should be taken that health care datacannot be viewed by unauthorized persons, by for example installing counters,limiting the functions that can be performed from that workstation, and byensuring that only registered users (personnel) can access these devices [BJH+04,


[very low]public data

[low]all caregivers

[high]discretion required

[very high]personal notes

specialization

[medium]

Figure 2.1: Sensitivity of Health Care Data (based on [DNdB04])

Section 4.11-12]. Electronic media containing health care data should be protectedfrom unauthorized access and destroyed properly at disposal [BJH+04, Section4.13]. Also the internal network of a health care organization requires adequateprotection. Besides the implementation of these physical access restrictions, accesscontrol needs to be enforced on the electronic information system, so that onlyauthorized persons and software programs are allowed to access a particularapplication, business function or data [BJH+04, Section 4.14].

Health care data are often labeled according to their sensitivity, as stated bythe following principle:

Principle 2 Data Sensitivity and Information Flow — Health care data is labeledwith its sensitivity level, which should also be observed as the data flows throughthe health care organization.

In [DNdB04, Dam04], medical data is classified according to the sensitivitylevels that are shown in Figure 2.1:

1. very low: administrative data.

2. low: data that is only accessible for health care professionals, e.g. allergies.

3. medium: data that is only accessible for health care professionals with thesame specialization.

4. high: data under restricted access. The patient is allowed to view everythingup to this level.

5. very high: a physician’s personal notes, including private recordings ofobservations, opinions, and impressions. These notes may be shared withcolleague specialists.


A B C D E

shared data

Figure 2.2: Compartmentation of Health Care Data (adopted from [And96a])

The last level may also encompass the recordings, observations, opinions andimpressions of which the release is potentially harmful for a patient [BRR99,Principle 12]. Kalra [Kal02, p 246] also indicates the need for the association ofsensitivity levels to data. His classification proposes the following five sensitivitylevels: (1) administrative data, (2) data for audit, research and teaching, (3)clinical data, data that can be accessed by (4) the core/emergency care team andby (5) personal clinicians.

In [And96a] the need for compartmentation of data (Figure 2.2) is advocatedto keep information within the department within which it originated, to preventinformation flow across the system. Only a subset of information is shared betweenthe departments.

Information flow involves that information that is derived from sensitive datashould also be labeled as sensitive. With respect to accessibility, this principle canbe rephrased as follows: Information derived from record A may only be appendedto record B if the persons who can access record B, are also authorized to accessrecord A [And96c, Principle 7].

When withholding information from a physician, it should be taken intoaccount that the absence of information (e.g. an HIV-flag) may actually leakinformation about the patient. A discrete flag can be used to indicate that certaininformation is missing [And96c], so that a physician may, for example, ask thepatient to confide this information to him or overrule the access denial, if thisinformation may be relevant for the treatment.

Clinical information serves as the basis for medical decisions. Therefore,individuals are entitled to the integrity of their health care data.

Principle 3 Integrity — Implement policies and procedures to protect electronicprotected health information from improper alteration or destruction [BJH+04,Section 4.16].

Safeguarding the integrity of data relates to the first principle in the sense thatonly authorized persons should be able to modify data. It also implies that clinical


information cannot be deleted until an appropriate time period has expired, andthat information is updated by appending a new version [And96c, Principle 5].

Both Principle 1 and 3 require that information is protected while electronicallytransmitted:

Principle 4 Transmission Security — During transmission, data should beprotected against unauthorized access and modification ([BRR99, Principle 23]and [BJH+04, Section 4.18]).

Principle 5 Audit and Notification — All access to health care data should berecorded, by capturing all necessary information about the access, such as the user’sname and access time ([BJH+04, Section 4.15] and [And96c, Principle 6]).

Both access control (Principle 1) and audit (Principle 5) rely on a correctattribution of a particular access to a person:

Principle 6 Authentication — Implement procedures to verify that a person orentity seeking access to electronic protected health information is the one claimed(adopted from [BJH+04, Section 4.17]).

2.3.3 Authorization

A major challenge is to strike a balance between the availability and the protectionof data, all the more so because data also needs to be protected against abuse byinsiders, such as personnel. By and large, access should be granted based onthe need-to-know or the minimum necessary principle. Reasonable effort mustbe made to limit access to information to the minimum necessary to accomplishthe intended purpose or disclosure [Sec02a]. However, the need-to-know principleis hard to approximate by an access policy [Van96] and even if this is realized,“legitimate access does not entail legitimate use” [Van96].

According to Anderson [And96c] the principle of need-to-know is not anacceptable basis for access control decisions. It is the patient’s consent thatmatters. This is merely an application of the Hippocratic oath, which statesthat personal information that is learned in the course of professional activities isnot passed on, unless the patient agrees [And96c].

In the next paragraphs, a number of possible uses of health information arediscussed.

The Patient. Individuals hold the right to access, amend and correct their ownhealth information. A patient can assign a confidant, whose identity is recorded.In some cases, the right to inspect medical data can be exercised by other persons,e.g. the guardian of an under aged patient or relatives of a deceased person.

In general, the subject of the medical data has access to his entire record,excluding a physician’s personal notes (Section 2.3.2), unless, for example,


the right to inspect the data is exercised through a physician who acts as aconfidant [DNdB04]. A physician can also withhold information from the patient,if, for example, its release would obviously cause harm to the patient’s healthcondition, the patient appeals to the right not-to-know, or the physician awaits thenext contact to provide explanation. According to Anderson [And96c, Principle4], a patient should also be able to gain insight in who can access his data and bywhom it has been accessed. An individual should be able to exercise control on theaccess to his data by withholding information from electronic format, segregatinginformation from shared records, specifying limits on the period of time andpurpose of use, and modifying default assigned sensitivity levels to health caredata.

Treatment. The HIPAA Privacy Rule [Sec02a] requires the need for thepatient’s consent to use or disclose health information for treatment or paymentpurposes. It is not always possible to obtain this consent, e.g. in emergencysituations. In these cases, treatment is provided as necessitated by the healthcondition of the patient.

Research. In general, there is consensus that aggregation of medical data shouldbe allowed for the purposes of research and audit, as long as the information isanonymized so that individuals cannot be identified.

Other Uses. In some cases, health care information may be released withoutprior consent of the patient, for example in the case of law enforcement or for thereporting of public health information on communicable diseases.

2.3.4 Principles addressed in this Thesis

A health care organization is required to have a security policy in place toadequately protect medical data (organizational measure 1). In the remainderof this thesis, we limit the discussion to the specification of an organization-wide access control policy. An access control policy specifies a series ofauthorizations. As discussed in Section 2.3.3, an authorization may be basedon the (treatment)relationship between the patient and the authorized user, aparticular use, and circumstance. It may also depend on the characteristics of thedata to which access is granted, such as its sensitivity (technical measure 2).

In this thesis, we are primarily concerned with the enforcement of this accesscontrol policy (technical measure 1), and with the ability to review both theaccess policy and its enforcement (organizational measure 6). In the course of thisthesis a number of the other principles will be treated to a lesser extent. Accesscontrol enforcement can be used to safeguard data from unauthorized modification(technical measure 3). Access control relies on authentication to attribute an


access request to a user (technical measure 6), and possibly on audit (technicalmeasure 5) to keep an access trail.

2.4 A Representative Health Care Access Control

Policy

In this section, an example health care policy is given that will serve as anillustration for the remainder of this thesis. The policy is based on the descriptionof the design and development of the hospital information system of U.Z. Leuvenin the Ph.D. thesis of Van den Bosch [Van96]. Section 6.3 on access control hasserved as the main source of inspiration to obtain a representative health carepolicy. First, the overall system is described and afterwards an access policy isformulated.

Contacts. The system is centered on contacts, which are essentially workflows.A description [Van96, p 95-96] is given below:

A contact is a medical logical unit that can be an outpatient visit, ahospitalization, a surgery, a chemotherapy treatment. A contact is not directlylinked with a patient’s movements, including admission, discharge and transfers:one contact can have many admissions and one admission can have several(simultaneous contacts). For example, a renal dialysis treatment contains anadmission for each time a patient is dialyzed.

A contact may result in a report after going through the following phases(Figure 2.3):

1. Reception: The patient and the department is associated with the contact.

2. Assignment: The contact is assigned to a physician and a supervisor.

3. Report Generation: The assigned physician generates the report, which isthen placed on the work list of the supervisor for validation.

4. Report Validation: The assigned supervisor validates the report. This alsocloses the contact.

The assigned physician may also close the contact by an explicit statement thatno report is necessary.

Services. A physician can address a service request to another physician, tocarry out, for instance, nursing acts, radiology or laboratory tests. The requestingphysician may cancel this request. The addressed physician performs the serviceand closes it upon termination.

2.4 A Representative Health Care Access Control Policy 19

Reception Assignment

No report necessary

Report Validation

Figure 2.3: Phases of a contact [Van96]

Appointments. The system allows users to associate appointments with acontact. An electronic book keeps track of all the appointments for a particularphysician, a location (e.g. a theater), or a resource. Each electronic book isassigned to a book owner. Only this owner can view the list of patients that havean appointment.

Patient and User Tracking. The system is equipped with a tracking system,which keeps track where (which ward or department) the patient resides at eachpoint and to which wards a staff member currently has access.

Referring Physicians. In the context of the LISA1, (external) general practi-tioners (GP) are able to view their patients’ hospital records, so that they are keptinformed of the health condition of their patients. This access is comprehensive,but excludes access to highly sensitive data including psychiatric and geneticrecords. The GP only gains access provided that the patient has signed an informedconsent form.

The Access Control Policy

The data that needs to be protected encompasses the contact and all the serviceresults, and reports that are associated with the contact. All these documents arebelow referred to as patient data.

1. The first access rule states that a user can only view patient data thatoriginated within one of the departments this user is assigned to. All userscan view patient data, of which the department field is left blank. —Compartmentation

2. Physicians who are assigned to a contact, either as supervisor or executingphysician, are granted access to patient data related to that contact, until30 days after the contact was closed. —Assigned Physicians

1LISA: Leuvense Internet Samenwerking Artsen project [UZL]


3. There are no time constraints on the access rights of the general practitionerof the patient. A general practitioner retains his access rights as longas he remains registered as the patient’s general practitioner. —GeneralPractitioner

4. A user is granted view access to a patient’s data if the patient resides orresided less than two weeks ago on a ward to which the user currently hasaccess. —User Tracking

5. A physician can overrule an access denial, provided that a detailed reasonis specified. This reason, the access time, user name and terminal ID arelogged. —Overrule Access

6. Not only these overrule accesses are carefully monitored, but also all accessesto data of so-called monitored patients. In case treatment is provided tocelebrities or personnel, a supervisor of a contact can indicate that accessesneed to be monitored. —Monitoring

7. Users can designate other users as stand-in, e.g. when they are on holiday.This stand-in then temporally obtains the privileges of the delegating user.—Delegation

8. System administrators can view the version history of patient data, but notits actual contents. The information department can retrieve all versions ofa piece of data. —System Administration

2.5 Context-Based Access Control for Health Care

Although omitted in the final HIPAA security rule, the implementation ofappropriate access control calls for either user-based, role-based or context-based access control. The principles in Section 2.3 and the presented accesspolicy in Section 2.4 require the implementation of the last option. Role-based (RBAC96 [SCFY96]) and user-based access control cannot take contextinformation into account, such as the presence of a relationship (e.g., Section 2.4rule 2 & 3) or special circumstances (e.g., the emergency access in rule 5). Theimplementation of context-based access control can be done by, for example,extending user- or role-based access control with the ability to account for contextinformation. In this section, a working definition is given of context-based accesscontrol.

Access Control. We refer to attempts to access functionality or data in asoftware system as access requests. An access request typically involves an object,an action and a principal. An object is the resource for which access is requested,such as for example health care information. The action (or sometimes operation)

2.5 Context-Based Access Control for Health Care 21

refers to the kind of access that is requested. Typical examples of actions are“read” and “write”. The principal is the source of the access request, and mayrepresent a user, a group, a machine, or a role. An access control policy specifieswhich actions a principal is allowed to perform on an object. Access controlenforcement can be divided into three subtasks, namely (1) the interception of eachaccess request, (2) the evaluation of an intercepted access request with respect tothe access control policy, and (3) the enforcement of the access decision. Usually aso-called reference monitor, which acts as the guard of the object, performs thesetasks. The information that this reference monitor has at its disposal is typicallylimited to the target object, the requested action, and the requesting principal.

Context-Based Access Control. To enforce expressive policies, contextinformation is often required to make an access decision. Besides taking intoaccount the principal, the target object and the action, context-based accesscontrol also requires information regarding the context in which the access isrequested. This context includes the context of objects, principals and the accessrequest itself. In Section 3.1.3 we will give an overview of different kinds of contextinformation. Below, a number of examples are given in the domain of health care:

1. Context of the Access Request: Common examples are time and location ofthe user who requests access (e.g., Section 2.4 rule 4). A physician is providedwith the capability to overrule an access denial if access is requested in thecontext of an emergency situation (Section 2.4 rule 5).

2. Relationship between User and Patient: Basing authorization on the ex-istence of a particular relationship between the principal of an accessrequest and the patient for whose data access is requested, is also endorsedby Beznosov [Bez00]. In [Smi01] the following types of relationships aredistinguished:

(a) Identity: the patient himself.

(b) Surrogacy: a user authorized to act on behalf of the patient.

(c) Treatment: a caregiver of the patient, who can be the primary, referring,consulting care provider.

(d) Employment: a sponsor of a health plan that covers the patient.

(e) Underwriting: an insurer of the patient.

3. Application-domain-specific attributes of objects and principals: This in-formation can be subdivided in security-related and non-security-relatedattributes [BDB+99]. Security-related attributes are attributes that areintroduced to implement security and include, for example, the user’sidentity, role assignment and group membership or sensitivity for objects


(as discussed in principle 2 in Section 2.3.2). Non-security-related attributesare attributes that initially have been introduced for other reasons thansecurity, but that turn out to be relevant for the evaluation of access requests.Examples are the age of a patient, and the ward a physician is assigned to.

The need for context-based access control has been acknowledged and ad-dressed by other researchers. In the context of health care, the DRIVE RBACmodel [WFSM02] is particularly interesting since it extends Role-Based AccessControl (RBAC) [FSG+01, FK92], with the notion of trust constituency andtime constraints to describe context. A trust constituency defines the rights andobligations of the actors in a business process to a certain type of asset and may,for example, state that identifiable clinical data should only be handled in clinicalactivities. This approach introduces two types of contexts: The working contextdetermines which roles can be activated by the user in a session, for example, therole on-call physician can only be activated during the nights and weekends. Thepermissions assigned to a particular role can vary according to the user context,which for example includes the location of the user requesting access. For example,access permissions may be reduced if the request originates from outside the warda physician is associated with.

2.6 Conclusion

A health care organization is required to specify and enforce an access controlpolicy to prevent unauthorized access to medical data. In Section 2.4, we havepresented an example policy that calls for the inclusion of context informationin the access control policy. Support for context-based access control allows, forexample, to authorize access based on the existence of a relationship between aphysician and the patient whose data is being accessed. This context-based policyand its implementation should be reviewed periodically to evaluate its effectiveness,to respond to changing requirements, and to adopt new security technologies. Inthe remainder of this thesis, this principle is referred to as the support for evolution.

Chapter 3

Evaluation of

State-of-the-Art Access

Control Technologies

In this thesis, we aim at the enforcement of a context-based access policy inthe applications deployed within an organization. The protection of applicationresources calls for application-level access control enforcement. Hereby, we focuson the enforcement of access control in object-oriented systems, such as object-oriented middleware. Examples of resources that need to be access controlled areobject instances, and the invocation of a method. The scope of technologies thatprovide application-level access control encompasses both access services offeredby a middleware platform, and access control libraries or frameworks that can beintegrated in an application. Embedding access control logic in the application isalso an alternative to implement application-level access control.

We present a set of evaluation criteria that can be used to evaluate these accesscontrol technologies. From this list, we focus on three criteria that are importantto implement access control in an application domain with demanding securityrequirements, such as the health care application domain, which was discussedin the previous chapter. The security requirements in these application domainsmandate support for the enforcement of (1) context-based access control policies.In order to respond to changing requirements, changes in the organization andapplication, (2) the evolution of the access control policy and its enforcementshould be supported. The evolvability is related with the adherence to theseparation-of-concerns principle, which states that the responsibilities betweenstakeholders should be clearly separated. The evolving organization’s accesscontrol policy needs to be enforced (3) uniformly in the applications deployedwithin the organization. We opted to focus on these requirements based on

23

24 Evaluation of State-of-the-Art Access Control Technologies

the observation that these criteria are badly supported by state-of-the-art accesscontrol technologies. This chapter substantiates this observation by evaluatingaccess control technologies with respect to these three requirements. For thisevaluation, we have classified the technologies based on their architecture,and more specifically, on the way in which the access control functionality isdecomposed into modules.

The outline of this chapter is as follows. Sections 3.1-3.2 introduce someterminology by means of working definitions. This discussion is divided in twoparts. The first part (Section 3.1) discusses the specification of what should beenforced, and the second part (Section 3.2) focuses on how access control is to beenforced. Section 3.3 discusses the evaluation criteria, by means of which state-of-the-art technologies are evaluated in Section 3.4. Conclusions are drawn inSection 3.5.

3.1 Access Control Policies and Models

A security policy objective can be characterized as a statement to protect anidentified resource from unauthorized use [Ste91]. The resources to be protectedare tangible assets, e.g. information or property. Unauthorized use refers to activehuman threats.

3.1.1 Access Control Policies

Access control is regulated according to an access control policy. Damianoudistinguishes three levels of access control policies [Dam02]:

1. High-level abstract policies (also organizational security policy [Ste91]) aresets of laws, rules, and practices that regulate how an organization manages,protects, and distributes resources to achieve specified security policyobjectives [Ste91]. This computer-independent view includes for exampleprocedures such as document sensitivity labeling. These rules are typicallyformulated in a natural language. In order to be enforceable, they should bemore refined into specification-level and low-level policies.

2. Specification-level policies (high-level policy or automated security policy):Sterne [Ste91] defines an automated security policy as the set of restrictionsand properties that specify how a computing system prevents information andcomputing resources from being used to violate an organizational securitypolicy. These policies typically abstract low-level policies and can thereforebe formulated by human security officers. Nonetheless, their enforcement canbe automated, as these policies are formulated in a precise format and relateto specific resources. In the remainder of the thesis, this type of policies isreferred to as a high-level policy.

3.1 Access Control Policies and Models 25

3. Low-level policies are typically security mechanism-specific configurations.Examples are firewall rules and application server deployment descriptors.

The access control policy determines the authorizations within the system.Authorization refers to the act of authorizing principals to perform some actionon a target object by the specification of a policy. Typical examples of principalsare human users, groups of users, and roles. The term authorization will also beused to refer to the evaluation of an access request, with as outcome either grantor deny.

Although often left implicit, an access control policy can typically be repre-sented in the form of an access control matrix.

Policy Languages for Access Control

High-level policies are formulated by means of an access control policy language.These languages are often rule-based, or based on formal logic. Logic-based policiesare easier to analyze, but are less intuitive and harder to implement [Dam02].

In a rule-based, general policy rules are formulated in the form:

if condition then principal {may/may not} do action to target object.

These authorization rules allow to specify conditions on target objects,principals, actions and their relationships.

Event-based languages explicitly specify the event that triggers the rule. Thesetype of rules are appropriate to express actions that need to be executed as partof security management, e.g. in response to certain events or periodically, orto express obligations. An obligation is an action that should be performed inconjunction with the enforcement of an authorization decision [OASa].

event triggers action if condition.

Meta-Policies

Meta-policies are policies about policies. They govern for example how applicablepolicies should be composed by indicating precedence, and/or conflict resolutionstrategies. Also constraints concerning the validity of a policy can be modeled bymeans of meta-policies. For example, a static separation-of-duty meta-policy canprevent that conflicting roles are assigned to the same user principal [Dam02].

Access Control Models

An access control policy may be based on an access control model, whichprovides a formal representation of security policies [Dam02]. Examples ofwidely known access control models are the Role-Based Access Control Model(RBAC96 [FSG+01]), the Mandatory Access Control Model (MAC [BL73, BL75]),


and the Discretionary Access Control Model (DAC [Dep83]). For an in depthtreatment of policy languages and models, we refer to [Dam02, Chapter 2].

3.1.2 Access Control Management

Handling application-level security policies is difficult and error-prone [Bro01].The large number of principals and objects calls for a scalable access controlinfrastructure. This infrastructure should be flexible as well, e.g. to supportevolving requirements. Brose [Bro01] distinguishes three management taskscorresponding to the three axes of access control: principals, objects andauthorization. The management of authorization (or the access control policy)has already been discussed in the previous section. Below, the management ofprincipals and objects will be briefly described.

Principal and Credential Management

A principal is an entity who can be authorized and whom an access requestcan be attributed to. The access control logic proposed in [LABW92] defines acomprehensive set of principals. The attribution of an access request to a principalis referred to as authentication. A principal differs from a subject in that the latteris an active entity within the system, such as a process or thread, which makes anaccess request on behalf of a principal.

The management of these principals involves, for instance, the choice of namesthat make sense to humans and may have to be unique, and the management ofcertain relationships between principals [Bro01], e.g. user-role assignments or arole hierarchy in RBAC.

A subject needs to prove that it acts on behalf of a principal. This is typicallydone by associating credentials with the subject. These credentials can be public,such as a public key certificate, or private, such as the private key that correspondsto the certificate. Credential management is the management of the associationof credentials to principals. A resource owner, who is entitled to authorize accessto a particular resource, may delegate the management of credentials to anotherentity.

Object and Domain Management

To keep the policy manageable, target objects are often grouped in so-calleddomains (also referred to as policy groups). Because these domains also come inhandy when managing authority, the term domain is also often used to define thelimits within which an entity can exercise its authority. This grouping of objectsis often implemented by assigning attributes to objects, such as for example asensitivity level.

3.1 Access Control Policies and Models 27

3.1.3 Access Control Information

Basic access control policies consist of access rules in the form of the triple(principal, object, action). In the ISO/IEC standard 10181-3 [ISO] for accesscontrol frameworks, a context-based access control scheme is referred to as ascheme in which rules concern contextual information. We give a number ofexamples of access control models that have been developed to take into accountcontext information.

Temporal RBAC (TRBAC) [BBF01] augments RBAC96 (as presented in[SCFY96]) with the ability to enable and disable roles periodically. Inclusionof context information is also important for the enforcement of access controlin collaborative systems [TAPH05], in which groups of users communicate andcooperate on common tasks. Access rights in these systems vary as tasks progress,and may depend on content and attributes of resources. In [CLS+01] the notion ofenvironment roles is introduced to capture context in a context-aware ubiquitouscomputing infrastructure. In a home environment, access to certain appliancesmay only be granted if the request is made from certain locations.

Below, we have divided the information on which an access decision de-pends, into the following three categories: (1) the state of the application andenvironment, (2) the access request, and (3) the history of previous accesses(and decisions). The whole of this information is referred to as access controlinformation (ACI) [ISO].

Application State and Environment

• Object State: Object state includes those attributes that relate to the targetobject of the access request. These attributes may include security-relatedattributes, such as for example security domain and sensitivity level, andapplication-domain-specific attributes that are non-security-related.E.g., access to data of monitored patients is subjected to more stringentaudit.

• Principal State: Principal state includes relations between principals as wellas attributes that are specific to a principal. This includes the assignmentof security-related attributes, such as clearance, group membership, androles to a user-principal. As was the case for object attributes, principalattributes may also encompass application-domain-specific attributes thatare non-security-related. Attributes that identify a relationship between aprincipal and object, can be regarded as both principal and object state.E.g., physicians who are assigned to a contact are granted access to patientdata.

• Environmental State: The validity of an authorization may be limited intime, and depend on the state of the overall system.


E.g., nurses are only allowed to access the system during their working shifts.

Access Request

Information in this category pertains to a particular access request.

• Subject Attributes: Subject attributes encompass all attributes that concernthe initiator of the access request. This is in the first place the principal(s)on whose behalf the subject acts. E.g., a user who works at the informationdepartment can retrieve all versions of a piece of data.

Other examples of subject attributes are an emergency (overrule) accesscondition, the strength of the user authentication, the location where theaccess request originates. E.g., a user is granted view access to a patient’sdata if the patient resides on a ward to which the user currently has access.

Subject attributes may also comprise the access path: In a chain of methodinvocations, a target object may act as an intermediary subject on its turn.The initiating subject may have to delegate some of its privileges so thatthe intermediary can act on its behalf. The intermediary may or maynot add (some of) its credentials to the interaction. Depending on thedelegation mode, the interaction state may thus also include intermediarysubjects’ state. The CORBA Security Service specification [Gro02b] specifiesa number of different options with respect to the delegation of credentials,such as impersonation and traced delegation.

The access request may take part in a broader business transaction, orprotocol. An authorization engine may require information from thetransaction in its whole, in order to evaluate an access request. An exampleis that medication can only be prescribed through a dedicated prescriptionmodule, which tracks allergies and contraindications.

• Access Request Parameters: The access request parameters refer to thearguments of the action that a subject is attempting to invoke on an object.

History of Access Requests and Decisions

Previous access requests and decisions can be taken into account when evaluatingan access request. A Chinese wall policy is a standard example of a policy thattakes into account the history of previous access requests. Another example is thefollowing rule from [EAC98] to avoid the aggregation of data:A subject who already gained access to an overview of the treatment proceduresprovided by the hospital at a particular day, should be denied access to a list ofpatients that were admitted that day.

3.2 Access Control Architecture and Mechanism 29

Protection State

To summarize, an authorization decision may be based on the application’s state,the request’s state, the history of previous requests and decisions, and the policy.The application’s protection state is a snapshot of both the application’s state andthe history of previous accesses.

protection state = (access history, application′s state)

authorization decision = f(protection state, request′s state, authorization policy)

3.2 Access Control Architecture and Mechanism

In this section, we discuss the access control enforcement architecture andmechanism. Starting from a description of the access control enforcementprocess in Section 3.2.1, the functions are identified that are relevant for accesscontrol enforcement. Section 3.2.2 elaborates on strategies to decompose theimplementation of this functionality into modules. In Section 3.2.3 we brieflydiscuss the other elements that can be captured in the access control architecture.

3.2.1 Access Control Functions

In order to be able to enforce access control policies, an access control technologyhas to fulfill a number of functions. The discussion of these functions is subdividedinto core functions, which pertain to the access control enforcement itself, and anumber of supporting functions.

Access Control Enforcement

We chose to base the description of the access control enforcement functions on theExtensible Access Control Markup Language (XACML [OASa]) dataflow diagram(Figure 3.1), as it is a well-known representative of this approach. It contains themajor building blocks required for access control enforcement, namely a PolicyEnforcement Point (PEP), Policy Decision Point (PDP), and Policy InformationPoint (PIP). Note that the XACML terminology slightly differs from ours: Theterm subject in the XACML specification is our notion of a principal, and ournotion of a subject is called access requester in the XACML specification.

PEP. The reference monitor or the PEP is part of the access path of the accessrequester (in this thesis referred to as the subject) to the target object. It mediatesor intercepts all events that are labeled by the policy as security sensitive, andenforces the decision taken by the Policy Decision Point. The decision can eitherbe a binary grant/deny (not shown in Figure 3.1) or can be more complex andinclude obligations that are enforced by an obligation service. We conclude that


Figure 3.1: XACML Dataflow [OASa]


a reference monitor fulfills two functions, namely Access Control Mediation andAccess Control Decision Enforcement.

PDP. The PDP fulfills the Access Decision Function by verifying whether anaccess request complies with the access control policy. The decision can be eithergrant or deny, or include an obligation, as discussed before.

PIP. For the evaluation of an access request, the PDP may need to takeinto account a variety of (context) information. As depicted in Figure 3.1,this information may, for instance, concern the resource being accessed, theenvironment, and the principal. This Access Control Information Retrieval iscarried out by a so-called Policy Information Point.Two elements in Figure 3.1 have not yet been discussed. The context handlertranslates the request from an application-specific format to the XACML stan-dardized format. The Policy Administration Point (PAP) is the system entitythat creates the policy.

Supporting Access Control Functions

Besides the core access control enforcement functions, a number of other support-ing functions can be identified, of which the most relevant are discussed below:

Access Policy Management. An access control technology should providesupport (in the form of tools) for Policy Specification to specify policy rules, policygroups, and principals.

Support is also required for the Runtime Management of the policy, e.g. tomaintain a runtime representation of the policy, and to make sure that changes inthe policy are propagated to all PDPs.

Subject. A Subject represents a principal within a system. To support this,a subject may for example, offer functionality to authenticate a user, activateand deactivate roles, hold credentials that may need to be presented whenauthenticating a subject’s request.

Request Authentication. Request Authentication verifies the authenticity of anaccess request, and more specifically, whether a subject is entitled to make thataccess request on behalf of the principal it claims to represents. Authenticationmay, for example, involve the validation of credentials.


3.2.2 Access Control Software Decomposition

The software decomposition strategy determines how modules implement theaccess control functions presented in the previous section. This decompositionalso determines how the access control logic is bound to the application, as itdetermines how the PEP and the PIP is realized. A module is a static unit thatencapsulates embedded abstractions, like types, variables, and classes [Szy02].The relation between the access control functions and the decomposition intomodules is that one or more module(s), or even a part of a module may realizea function. Below, a number of software decomposition strategies are appliedto access control architectures to gain insight in how such a technology can beextended and customized to a particular application.

Embedded Access Control. We can distinguish between the following twodecomposition strategies:

1. In case of an embedded policy decision point, no distinction can be madebetween the application and access logic.

2. An embedded policy enforcement point hardwires the mediation points wherea policy decision point is invoked. The latter is external to the application,and often implemented as a black or whitebox framework.

Embedded access control typically makes use of an Application Programmer’sInterface (API), provided by a component framework to get hold of a fixed set ofsubject attributes. J2EE, for example, provides an API that allows to retrieve theprincipal and the roles of the accessing subject.

Access Control Frameworks. A framework captures the commonalities withina domain (e.g. access control enforcement), and leaves so-called hot spots orvariation points for customization and extension. These common features canbe a piece of common functionality, or interactions between modules. There existtwo flavors of frameworks:

• Whitebox Framework: In a whitebox (object-oriented) framework the hotspots are places where the framework can be extended by means ofinheritance. Customization, for example, consists in overriding abstractmethods of the framework.A representative technology in this category is the Java Authenticationand Authorization Service (JAAS) [Jaw00, GED03]. In order to enforceapplication-domain-specific policies, JAAS needs to be extended with newpermission classes.


• Blackbox Framework: In a blackbox framework, the hot spots are well-defined interfaces that shield the implementation of the framework. Cus-tomization is then done by means of (object) composition.A representative technology is the Open Group Authorization API that isintegrated in Tivoli Access Manager [Kar03].

Component Framework Access Control Service. A component frameworkimplements run-time services that implement the component model. Implemen-tation of non-functional concerns, such as security, on which a component doesnot depend explicitly for its correct functioning, are often hard-coded and tangledin the component framework. Interception is often used to transparently imposesuch a non-functional service. A component framework access control servicedistinguishes itself from state-of-the-art access control frameworks by the inclusionof the policy enforcement point.A representative component framework access control service is the declarativeaccess control offered by the J2EE application container [BCE+06].

3.2.3 Overview of an Access Control Enforcement Architec-

ture

The previous sections only provide a partial view on a software architecture foraccess control. We will briefly overview the elements that are captured in anaccess control architecture, and situate the previously discussed elements in thisoverview. We note that these elements are mentioned here for completeness, andwill not be elaborated on in the remainder of this thesis.

Conforming to [BCK03], the description of the architecture can be subdividedaccording to three software structures, namely module, process and allocationstructure.

The software decomposition presented in the previous section is part of themodule structure. This module structure determines the interfaces of modules,inheritance relationships, and their dependencies.

The dynamic behavior of the system is highlighted by the process structure1.Central to this structure are processes, sets of programming steps that arerepeated in response to a triggering event or to a timing constraint with an ownthread of control, which can be suspended [BCK03]. The process view includesa description of their distribution, shared data and interaction. For example,the reference monitor is customary placed at server side to intercept inboundrequests. Optionally, a reference monitor can be placed at client side to interceptoutbound requests as well. Distribution of policy information points adds the

1In [BCK03] this structure is referred to as the Component-Connector Structure. We useda slightly differing definition of component [Szy02], and therefore the term process structure ismore appropriate.


I. Expressiveness II. Evolution

Policy Management System Evolution

- mediation gran.- richness- ...

AssuranceScalability

- run-time performance- architectural scalability

- III. Uniformity abstraction centralized mgmt

- administration scalability- access control policy mgmt- ...

characteristics: * extensible PIP * modularized PDP * transparent PEP

confidence buildingactivities

Figure 3.2: Access Control Criteria

additional requirement that the information the policy decision point relies on isauthentic and (sometimes) even kept confidential. The XACML dataflow diagramin Figure 3.1 depicts a rudimentary process view.

The allocation structure includes deployment, mapping of the software ontothe development/configuration/integration environment and allocation to teamsof developers.

An access control mechanism is a component that after installation fulfills(a subset of) the access control functions. Often a mechanism is tailored to aparticular (component) platform or application, such as access control for J2EE.A total access control solution may involve a composition of several access controlmechanisms.

3.3 Evaluation Criteria for Access Control Tech-

nologies

In this section, we discuss a number of criteria by means of which state-of-the-art technologies will be evaluated. We limit the discussion to those criteria thatcorrespond to the objectives of this thesis as set forth in the introduction ofthis chapter. In Chapter 6, a more comprehensive set of criteria is introduced.Figure 3.2 shows a high-level overview of this set and indicates the criteriathat this thesis focuses on, namely: the enforcement of context-based policies inan application, the evolution and uniformity of application-level access controlenforcement. The other criteria are discussed in Chapter 6.

3.3.1 Expressiveness

The degree to which an access control technology succeeds in enforcing context-based access control policies on application resources is referred to as the

3.3 Evaluation Criteria for Access Control Technologies 35

expressiveness of that technology.

Two important characteristics of this criterion are the mediation granularity ofaccess control enforcement, and the variety of information that can be taken intoaccount when evaluating an access request, referred to as richness.

Mediation Granularity

The mediation granularity of an access control technology measures the abilityto select access control mediation points. Together with richness, granularitydetermines the unit of protection, i.e. the action-resource pairs that can beprotected. In [Bez00], a hierarchy of granularity is proposed: application, interfacemethod and other resources. We extend this hierarchy below:

1. Application: This level of granularity only allows to select the entry pointsof the application.

2. Interface Method: This level of mediation granularity allows to select aparticular interface method. Access control is enforced on all objects thatimplement this interface. This level of granularity also encompasses thecreation of instances of a particular class.

3. Application Resources: e.g., sockets, files, and database connections.

4. Application Object/Component Instances: In addition to interface methodgranularity, object or component instances that need to be protected can bepinpointed. For example, object instances can be selected based on theirname (if naming is supported) or based on some (state) properties.

The complexity that object orientation adds is that object-oriented systemsdo not tend to have rigid naming hierarchies: The system contains a largenumber anonymous objects and multiple names (aliases) may refer to thesame object [Bla99]. Blakley formulates the following requirement [Bla99]:Object-oriented security systems should let security administrators define anobject’s policy without having to know its name. Objects with no namesshould be securable; objects with many names should be securable and shouldbe secured by the same policy no matter which name is used to refer to them.

5. Variable Assignment and Retrieval: Sometimes, a technology may supporteven more fine-granular access control so that the assignment and retrievalof instance variables can be protected.

Mediation granularity is a characteristic of the Policy Enforcement Point(PEP).


Richness

Richness can be defined as the variety of information that can be taken into accountduring the evaluation of an access request [Bez00]. Richness is determined by theinterface of the Policy Decision Point and by the information that can be retrievedfrom the Policy Information Points.

Embedding access logic allows to take into account a rich variety of information.The policy decision point integrated by black and whitebox frameworks oftenprovides a rich interface. But as these frameworks do not provide the binding withthe application, the corresponding PIP still needs to be provided. Componentframework services, such as J2EE, typically only allow to enforce basic accesspolicies.

3.3.2 Evolution

Access control enforcement evolves over time, due to changes in the access policyor system. The evolvability of an access control technology is determined by thedelimitation of the responsibilities of the stakeholders involved. A security officermanages the policy and an application deployer integrates the enforcement of thispolicy in an application. Support for evolution therefore requires support for policymanagement and system evolution.

Policy Management

Policy evolution can be driven by changes in the organization, such as the additionand removal of users, roles, groups, and assets. This type of changes requiressupport for principal and object management.

Policy changes may also involve an addition or removal of new policy rules,the retrieval of different access control information, the use of a different accesscontrol model.

As shown in Figure 3.2, policy management also encompasses uniformity, whichis defined as the ability to enforce one common access policy in a number ofapplications. This requirement is further elaborated on in Section 3.3.3. For adiscussion of other criteria that are associated with policy management, we referto Section 6.1.2.

System Evolution

Policy evolution may necessitate adaptations in the enforcement logic. Besidespolicy evolution, policy enforcement logic may also need to evolve due to changesin the application, such as code refactoring, or the replacement of a mechanism.

The adaptability of the system is the degree to which it can be adapted tocope with new requirements. The following characteristics positively influence theadaptability of an access control technology:

3.3 Evaluation Criteria for Access Control Technologies 37

Embedded(PDP)

WhiteBoxFramework

BlackBoxFramework

Framework Service(declarative)

extensible PIP - x (0) x (0) -modularized PDP - + + xtransparent PEP - x (-) x (-) +

Figure 3.3: Relation between adaptability and software decomposition

• an extensible PIP

• a modularized PDP

• a (to the application) transparent PEP (providing mediation and decisionenforcement)

An access control technology is called configurable if it can be adapted to newrequirements declaratively.

Figure 3.3 shows how these characteristics relate to the access control softwaredecomposition options identified in Section 3.2.2. The following conclusions canbe drawn: Embedding access logic in an application allows to enforce expressivepolicies, but adversely affects adaptability towards new requirements as the accesscontrol logic is hard-coded.

State-of-the-art blackbox and whitebox frameworks typically aim at mod-ularizing the access decision logic, and often provide support to take intoaccount application-domain-specific information in the access decision process. Forexample, an interface of the PDP may specify a context parameter. However, theseframeworks generally do not include a policy enforcement point. As a consequence,invocations to the access decision logic are often embedded in the application.

The declarative access control enforcement that is provided by componentframework access services, is often adaptable, but lacks expressiveness due toits generality. The range of policies that can be enforced is typically limitedto invocation access policies, which only take into account the principal andthe invoked interface method. Sometimes such an access service specifies aclear interface to the decision logic so that it is easy to provide an alternativeimplementation. State-of-the-art access services also provide an API, which allowsapplications to retrieve the requesting principal, and to embed their own accesscontrol logic.

3.3.3 Uniformity

This criterion evaluates the degree to which one (organization-wide access control)policy is described and enforced uniformly in several applications that aredeployed within one organization. This criterion is also referred to as consistencyin [Bez02a]. It implies that the policy should only be written down once to


integrate its enforcement in multiple applications. This requires abstraction fromapplication-specific details and central management of the policy.

Abstraction

The abstraction of an access policy from application-specifics is a prerequisiteto support separation-of-concerns between the stakeholders involved in theintegration of access control enforcement in the application. More specifically, thesecurity officer should not be required to understand the applications’ internalsto formulate the common policy that needs to be enforced in these applications.Support is needed to specify these application-domain-specific abstractions andbind these to the application. E.g., application-specific events may be classifiedinto (abstract) actions corresponding to their sensitivity.

Centralized Management

The enforcement of one common policy in several applications is facilitated if thepolicy can be administered centrally.

3.4 State-of-the-Art Access Control Technologies

In this section a number of relevant state-of-the-art access control technologies arediscussed. For each technology, we examine the provided access control functionsand the software decomposition strategy. In addition, a brief evaluation is carriedout with respect to the evaluation criteria introduced in Section 3.3.

3.4.1 Java Authentication and Authorization Service

The Java Security Architecture [Gon] provides fine-grained access control to secureapplications. The Java Authentication and Authorization Service (JAAS) is awhitebox framework that provides an authentication framework and augmentsJava Security with principal-based (as opposed to codesource-based) authorization.JAAS provides a default implementation that allows to specify the policydeclaratively. The security architecture can be customized by plugging in anexternal provider.

Access Control Policy Specification

The Java Security Architecture includes a default policy provider, with associatedpolicy specification syntax. Authorization consists in assigning permissions to aprincipal or a codebase. A number of Permission -classes have been predefined,such as a FilePermission , which is required to open a file. To verify whether anaccess request conforms to the policy, access control checks are hard-coded in the

3.4 State-of-the-Art Access Control Technologies 39

grant codebase "file:./CoffeeBreak.jar",

principal java.security.Principal "Duke" {

permission java.io.FilePermission "CoffeeOrders","read";

permission coffeebreak.CoffeeBreakPermission "10";

};

Figure 3.4: JAAS Policy File

Java class library before each security-sensitive operation, such as the opening ofa file or socket.

The policy may also include application-(domain-)specific permissions definedby the application, such as the CoffeeBreakPermission in Figure 3.4. Below wediscuss how an application can include the necessary access control checks.

Evaluation of Access Requests

The access decision process is triggered by calling checkPermission(...) oneither the installed SecurityManager , or the AccessController . The differencebetween these two is that the former can be regarded as a central point ofaccess control and the latter as the encapsulation of the stackwalking algorithm,which is discussed below [Gon]. Although the default implementation of theSecurityManager delegates the access control check to the AccessController ,it is recommended in [Gon] to use the latter, because the use of a poorlyimplemented SecurityManager may entirely subvert access control enforcement.A checkPermission(...)-call takes a Permission -instance as an argument andinitiates a stackwalk. This stackwalk verifies based on the policy whether thecurrent AccessControlContext , associated with the calling thread, implies thegiven Permission -instance.

A Policy -instance specifies the permissions for each so-called Protection-

Domain . This ProtectionDomain is associated with a codebase, along with theprincipals on whose behalf the code is executed. Two options exist: Eitherpermissions are assigned statically to a ProtectionDomain at its constructiontime, or the current Policy -instance verifies at the point of the access decisionwhether the given PolicyDomain implies the required Permission. The overallverification procedure then consists in verifying whether all the domains on thestack (taking into account any stackmodifiers) imply the required Permission.

Access Control Integration with JAAS

The Java Security Architecture introduces an AccessControlContext for eachthread, which keeps track of the Subject and the different codebases of


public final class CoffeeBreakPermission extends BasicPermission{

//duration of coffeebreak (in minutes)

private int breakDuration;

public CoffeeBreakPermission(int break){this.breakDuration=break;}

public int getDuration(){ return this.breakDuration;}

...

public boolean implies(Permission p){

if(!(p instance of CoffeeBreakPermission))

return false;

return (this.getDuration() >=

((CoffeeBreakPermission)p).getDuration());

}

}

Figure 3.5: A Custom Permission

the stackframes. This Subject holds a set of Principal s that have beenassigned during authentication. An access control check consists in invokingcheckPermission(...) on the installed SecurityManager .

To provide application-specific security, the application can define customPermission -classes, as in Figure 3.5. These allow to take into account addi-tional context information in the access control evaluation process by means ofthe implies(Permission)-method, which specifies an implication relationshipbetween permissions. This implication relation is hard-coded, and therefore thisapproach is rather ad hoc.

An application-domain-specific policy can be enforced by embedding accesschecks in the application. The mediation granularity is thus at the applica-tion’s discretion. The application also bears the responsibility to associate aSubject with an AccessControlContext by means of the following method-call:Subject.doAs(Subject subject, PrivilegedAction action) .The action parameter encapsulates the functionality that has to be performedon behalf of the given Subject .

This results in security logic that is closely entangled in the application logic.It is therefore hard to, for example, relocate access control checks, or to includeadditional context information in the access decision process. Below, we elaborateon how the security architecture can be further customized.

Customizing the Security Architecture

The three important variation points in the JAAS framework are the Policy , theSecurityManager and the AccessControlContext , and these can be replaced tocustomize the security architecture [Jaw00].


1. Replacing the Policy is typically done when a different specificationlanguage or a custom policy store is used.

2. The SecurityManager could be replaced to omit the stackwalk altogether orit could be extended to enforce generally applicable policy rules. An exampleis the logging of every access attempt.

3. Customizing the AccessControlContext allows to extend the informationcontained within the AccessControlContext . JAAS itself is implementedas a customization of the AccessControlContext such that it takes intoaccount the Principal s, on whose behalf access is requested. Extending theAccessControlContext is less straightforward to implement and requiresthat the application manipulates the AccessControlContext .

Although the JAAS framework allows for powerful extensions, the implemen-tation of a custom access control model might require a carefully thought-outdesign. The policy decision point seems to correspond to the whole of Policy ,SecurityManager , AccessControlContext and Permission , each having alimited view on the access request context and/or the policy. The reason is that theJava Security Architecture was originally designed solely for code access securityand that user-based authentication and authorization were added afterwards.

Conclusion

We can conclude that JAAS is capable of enforcing expressive policies. However,it does not support the uniformity requirement. It is also up to the applicationto invoke the access logic with the appropriate arguments, which leads to anentanglement of the access logic with the application.

3.4.2 Java 2 Enterprise Edition

J2EE security [BGH+02] is an example of a platform service. Besides trans-port and message layer security, the J2EE security service provides supportfor application-specific security management. There are two ways to enforceapplication-level access control, namely declaratively (container managed) andprogrammatically. The former reduces the burden on the application developerand ensures that enterprise beans are portable across J2EE application servers.

Declarative Application-Specific Access Control

A declarative policy can be specified by the deployment descriptor (Figure 3.6) orby specific annotations in the code, or both. In the latter case, the deploymentdescriptor has precedence over annotations. Authorization is based on the rolesthat are assigned to the calling principal. This principal can be propagated with


the invocation. Alternatively, a run-as role can be specified as delegation option.A role groups a number of method permissions. These permissions can either groupall interface methods of an enterprise bean, or select a subset based on the methodname and optionally parameter types. The set of these roles should be seen as asecurity view on the application that group permissions needed by a given type ofuser to successfully use the application. This view can be specified by the beanprovider or application assembler.

For a particular deployment setting, the application-scoped roles are to bemapped to the authorized users and groups in the scope of the application server.Declarative access control in J2EE fails to include any context.

An API for Programmatically Enforcing Access Control

In case this is necessary, the enterprise bean can also enforce its own access control,i.e. programmatic security. For this purpose, the EJB container also provides theapplication with an interface offering the following methods to retrieve the callingprincipal and his roles:EJBContext.getCallerPrincipal() and EJBContext.isCallerInRole("...") .

Plugging in an External Provider with Java Authorization Contractsfor Containers

Java Authorization Contracts for Containers (JACC) [Mon03] specifies interfacesfor plugging in external policy providers. Providers specify the roles a principal isentitled to.

JACC defines three subcontracts, as shown in Figure 3.7:

1. The Policy Provider Subcontract (not shown in Figure 3.7) captures therequirements that need to be fulfilled by external policy providers and con-tainer such that the external policy provider can be integrated. More specifi-cally the contract specifies a Java extension package, namely javax.security.jacc .The most important classes of this extension package are discussed below.

2. The Policy Configuration Subcontract defines requirements such that declar-ative J2EE policy rules can be translated to rules understood by the externalprovider.

3. The Policy Decision and Enforcement Subcontract defines the interactionsbetween the container enforcement points and the provider that takes theaccess decisions. This interaction, for example, encompasses the retrieval ofadditional information concerning the access request.

We organize the discussion of these contracts around two classes of the jaccpackage, namely the PolicyConfiguration and PolicyContext .


<ejb-jar>

<enterprise-beans>

...

<session>

<ejb-name>AardvarkPayroll</ejb-name>

<ejb-class>com.aardvark.payroll.PayrollBean</ejb-class>

...

<security-role-ref>

<description>

This role should be assigned to the employees of the payroll

department, and has been linked to the payroll-department role.

</description>

<role-name>payroll</role-name>

<role-link>payroll-department</role-link>

</security-role-ref>

<security-identity>

<run-as>

<role-name>admin</role-name>

</run-as>

</security-identity>

</session>

</enterprise-beans>

<assembly-descriptor>

<security-role>

<description>

This role includes the employees of the payroll department.

</description>

<role-name>payroll-department</role-name>

</security-role>

<method-permission>

<role-name>payroll-department</role-name>

<method>


<method-name>updateSalary</method-name>

</method>

</method-permission>

<method-permission>

<unchecked/>

<method>


<method-name>increaseMySalary</method-name>

</method>

</method-permission>

<exclude-list>

<method>


<method-name>decreaseMySalary</method-name>

</method>

</exclude-list>

...

</assembly-descriptor>

</ejb-jar>

Figure 3.6: J2EE Deployment Descriptor (based on [BCE+06])


Figure 3.7: Policy Configuration and Enforcement Subcontracts (from [Mon03])

According to subcontract 1, a policy provider is required to implement aPolicyConfiguration , so that deployment tools can register policy statementsas formulated by the deployment descriptor with the provider. Subcontract 2specifies how this registration is to be carried out by deployment tools. For EJBdeployment descriptors (as in Figure 3.6):

1. An EJBMethodPermission-statement is added for each <method-permission>

element, both for <unchecked> as for <role-name> elements. An EJB-

MethodPermission-object is also created for each element in the <excluded>-list.

2. A EJBRoleRefPermission-object is created for each <security-role-ref>

element to cope with isCallerInRole(...) invocations.

Each PolicyConfiguration-instance is associated with a PolicyContext

that is associated with an application. Its implementation is provided by thecontainer that can register so-called PolicyContextHandlers . These allow apolicy provider to include additional information such as the arguments of arequest (EJB Arguments Policy Context Handler), the bean involved in therequest (EnterpriseBean Policy Context Handler), the subject (Container SubjectPolicy Context Handler). The specification of these handlers is the topic of


subcontract 3. This contract also includes the responsibility of the container toset the PolicyContext and to invoke the decision logic (either by invoking theAccessControlContext , AccessController , SecurityManager , or Policy inplace). The contract also specifies the decision semantics that must be employedby the provider. This for example includes the precedence of excluded policystatements over unchecked and checked statements, and the implies relationbetween permissions.

Conclusion

As the scope of the roles is limited to one application, J2EE security does notsupport a uniform enforcement of one common policy in number of applications.The policy that is enforced by the J2EE container is easily adaptable, but lacksexpressiveness. Programmatic access control can support expressive policies butis harder to adapt.

3.4.3 COM+ and .NET

We only treat security in COM+ and .NET briefly, as it is similar to J2EEsecurity [Bez02a]. Access control can be either configured declaratively or enforcedprogrammatically. For the latter option, the developer can make use of anAPI to retrieve the principal, on which the IsInRole(String)-method can beinvoked. Access control checks can be inserted by means of a demand for aPrincipalPermission . Declarative checks can be placed at method and at classlevel, as shown in Figure 3.8.

[PrincipalPermission(SecurityAction.Demand, Role="payrole-department")]

public class AardvarkPayRole{

[PrincipalPermissionAttribute(SecurityAction.Demand, Name = "John")]

public void updateSalary(long newSalary){

...

}

//programmatic access control

public void viewSalary(String user){

PrincipalPermission pp = new PrincipalPermission("John");

pp.Demand();

IPrincipal principal = Thread.CurrentPrincipal;

if(principal.IsInRole("payrole-department")){ ...}

else throw new Exception("Access Denied");

}

}

Figure 3.8: Declarative and Programmatic Access Control in .NET


3.4.4 CORBA Security Service

The CORBA Security Service specification [Gro02b] of the Object ManagementGroup (OMG) specifies a comprehensive list of security requirements vendors needto fulfill in order to obtain conformance with the specification. In this section, welimit the discussion to the enforcement of access control policies.

The CORBAsec specification distinguishes between applications based on theirsecurity awareness: The application may be either completely security-unaware orsecurity-aware. The latter implies, for example, that the application tunes thepolicy that is enforced by the system on the application’s behalf, or that theapplication implements its own policy enforcement.

The specification defines two security functionality levels, of which at least onehas to be supported by an ORB implementation in order to obtain conformancewith the specification.

1. Level 1 security implements object invocation access control enforcement forsecurity-unaware applications, and provides a limited API for those applica-tions that require few security functionality from the ORB for implementingtheir own access control enforcement. This API allows the application to ob-tain the (privilege) attributes of the principal (Current::get attributes )on whose behalf access is requested. At this level, the specification doesnot provide details about how the policy is to be specified and administeredother than that access control can be based on sets of objects and subjects.

2. Level 2 security provides all the functionality offered by Level 1, andin addition offers more facilities and an administrative interface thatallows security-aware applications to configure the object invocation accesscontrol enforcement. This interface also ensures that these security-awareapplications are portable.

As shown in Figure 3.9, a distinction is made between an access policy thatis automatically enforced on an object invocation, referred to invocation accesspolicy, and a policy that is enforced by the application itself, referred to as anapplication access policy.

The Invocation Access Control Policy

An access control policy determines whether a client is granted access to an object.Target objects that are subject to the same policy are grouped into domains,which can be organized in a hierarchy. The domain an object is assigned to canbe controlled by a construction policy.

A principal is defined as a human user or a system entity that is registeredwith and authentic to the system. A principal can hold attributes that are either:

• Public, i.e. available to any principal without requiring authentication.


Figure 3.9: Access Control Model (from [Gro02b])

• acquired through authentication, e.g. identity attributes and privilegeattributes.

• acquired through delegation, i.e. obtained from another principal on whosebehalf the access is made. CORBAsec specifies a number of delegationoptions, including: no delegation, simple delegation (impersonation), com-bined, composite and traced delegation.

Operations on target objects are grouped by means of rights. To enforce apolicy, one first has to specify the required rights that are needed to execute aninterface method. These rights are grouped into rights families. The defaultCORBA rights family encompasses the following rights: g (get), s (set), m(manage) and u (use). Vendors can extend the service with additional families.An access policy then specifies a mapping between principal attributes and rights.

Per object type, the required rights are to be specified for each operation.

Modularizing Access Decision Logic in an Access Decision Object

Figure 3.10 shows how the access decision process then proceeds: the ORBintercepts an invocation attempt (either at client or server side or both), andinvokes an access decision object. The default implementation of this accessdecision object compares the required rights of the interface method with theeffective rights associated with the current principal’s attributes. The requiredrights are specified per interface method, and can be combined: it is possible tospecify that a principal needs only one (ANY) right or all of the rights (ALL) in thereturned rights set. The effective rights of a principal’s attributes are determined


Access DecisionObject

access_allowedyes/no

credentials target

operation_name target_interface_name

Access Policy(effective rights)

Required Rights

Figure 3.10: Access Decision Object

Privilege Attribute Delegation State Granted Rightsaccess id:alice initiator corba: gs–

other: -u-m-saccess id:alice delegate corba: g—group:programmers initiator corba: g—group:administrators initiator corba: gs–

Figure 3.11: CORBA Domain Access Policy (from [Gro02b])

by each policy associated with the domains the target object belongs to. Anexample access policy is given in Figure 3.11.

Integration of an Application Access Policy

An application access policy is to be enforced by the application itself, althoughit is recommended to encapsulate the access control logic, e.g. in an accessdecision object. The Resource Access Decision Service, discussed below, followsthis approach. To enforce this kind of policies, the application can make use of theCORBA security service, e.g. to obtain information concerning the principal bymeans of the Current::get attributes -call, to associate a policy with a domain,and to retrieve the applicable policy.

The Security Domain Membership Management (SDMM) [Gro02a] is aproposal that supports the enforcement of application-specific policies for CORBAapplications. The SDMM specification [Gro02a] identifies three ways to includeapplication state, namely by:


get_attributes_by_type(type: AttributeType) : AttributeValueList

get_all_attributes() : Object AttributeList

Figure 3.12: Interface of the Attribute Retriever

1. the addition of Dynamic Attributes to the principal’s privilege attributes tocapture, for example, a relationship between this principal and the resourcebeing accessed. Examples are “the primary account holder”, and “theattending physician”.

2. the introduction of Object Security Attributes, which can be retrieved by acustom implementation of the AccessDecision-object

3. supporting Object Domain Mapping based on application state.

The specification addresses the last two options in such a way that the application’sawareness is kept to a minimum. The Resource Access Decision Service implementsthe first option.

Object Security Attributes. Object Security Attributes (OSA) [Bez02b] allowto keep middleware security services generic (reusable) and yet allow for enforce-ment of application-domain-specific security policies. As shown in Figure 3.13,the approach allows to retrieve application state by means of a backdoor. Thisbackdoor is implemented as an AttributeRetriever (Figure 3.12) that is specificfor a particular target object and needs to be created and registered by theapplication itself.

Object Domain Mapping. Object Domain Mapping (ODM) [Gro02a] pro-vides security-aware applications with the ability to manage the security domainsan object belongs to. Similar to security object attributes, it is up to theapplication to create and register an object domain membership manager. If nosuch manager was registered for a particular object (e.g. for security-unawareapplications), a default object domain manager determines the domains an objectbelongs to.

Enforcing an Enterprise Security Policy with the Resource AccessDecision Facility

The Resource Access Decision (RAD) Facility specification [Objb] is an OMGspecification that aims at the standardization of the enforcement of fine-granularaccess control policies at the application level. This standardization offersa uniform way to administer an enterprise security policy. The (end-user


Application

Target BackDoor

DecisionFunction

Application-specificFactors Request

Application-specificFactors

EnforcementFunction

AccessRequest

AccessRequest

Middleware Security Subsystem

Decision

Decision Request

Middleware

Figure 3.13: Object Security Attributes (from [Bez02b])

oriented) facility is based on CORBA security and can be used by security-awareapplications.

In [BDB+99], it is described how the Resource Access Decision Facilitysupports abstraction by conveying to the AccessDecision -object a protectedresource name to abstract from application-dependent semantics and syntaxes, andan access operation to abstract from the semantics of the access (Figure 3.14). Adrawback is that these abstractions have to be applied by the application developer(in consultation with the security officer). To obtain application context, RADintroduces a DynamicAttributeService (DAS) to retrieve dynamic attributesconcerning the principal of an access request.

Replaceability Packages for Customization

The CORBAsec specification accommodates for evolution of the system by thespecification of replaceability packages. Two replaceability packages are specifiedthat enable to plug in a different Security Service:

1. ORB Service Replaceability: Conformance to this replaceability packageallows an ORB to know little about security, because security code is factoredout of the ORB and implemented by interceptors. The ORB calls theseinterceptors in a specified order to apply an object service.


Application ado: Access Decision Object

loc: PolicyEvaluator Locator

das: DynamicAttribute Service

dc: DecisionCombinator

pe:PolicyEvaluator

access-allowed(ResourceName, Operation,

AttributeList) get_policy_decision_evaluators(ResourceName)

dc,{pe}

get_dynamic_attributes(AttributeList,ResourceName,Operation)

combine_decisions(ResourceName,Operation,AttributeList, PolicyEvaluatorList)

evaluate(ResourceName,Operation,AttributeList)

pe: PolicyEvaluator

pe: PolicyEvaluator

AttributeList

Figure 3.14: Resource Access Decision Facility (from [BDB+99])

2. Security Service Replaceability: This package contains a number of interfaces,such as the AccessDecision interface, that are positioned so that thesecurity services are independent from a particular ORB implementation.

Conclusion

CORBAsec provides support to integrate the enforcement of invocation accesspolicies in security-unaware applications. These invocation access policies fail toinclude the context in the access decision process. Applications that require theenforcement of a more fine-granular and expressive policy can implement their ownaccess control enforcement.

OSA and ODM are a first attempt to enforce context-based policies whilekeeping the security service generic. The application is responsible for registeringthe necessary attribute retrievers and domain membership managers. Because theinterface of this attribute retriever is kept generic, it is not clear in advance whichinformation the application should be able to deliver to the access decision object.

RAD supports uniform access control enforcement by abstracting from ap-plication-specifics. It is the responsibility of the developer to convey an abstractresource name and operation to the access decision object. This translation fromapplication-specific requests is hard to adapt, as it is embedded in the application.

3.4.5 Tivoli Access Manager

Tivoli Access Manager [Kar03] for e-business applications provides in the firstplace centralized access control management that moreover supports uniformity


http://www.acme.com/sales/web/db.cgi?service=Softwear&product=shirt&color=red

/db/redshirt/app/snoop/app/snoopA...

/db.cgi*product=shirt*color=red*/rt[25]/servlet/snoop/rt?/servlet/snoop...

URL Mapping

*product=shirt*color=red*

/

/ManagementUser-defined /WebSEAL

www.acme.com/

web/

db.cgi

Dynamic URL Entries ...red shirt

...group admin vwxgroup customer v-xany_authenticated v-xunauthenticated ---

ACL

protected object namespace

Figure 3.15: Protected Object Space (based on [Kar03])

by the definition of a protected object space.

Access Control Lists, Protected Object Policies and AuthorizationRules

Tivoli supports a centralized management and consistent enforcement of policiesby the declaration of a protected object space. These objects are organized in ahierarchy as shown in Figure 3.15. This hierarchy encompasses both user definedtarget objects as access control management objects, including users and groups,and access control lists.

These objects can be associated with access policies, which may be formulatedin the following forms:

• Access Control Lists determine what permissions a user or group holdson an object. A permission denotes a type of access. Similar as inCORBASec [Gro02b], a standard set of permissions has been defined, whichcan then be extended by means of rights families.

• Protected Object Policies encompass additional conditions that must befulfilled (irrespective of the requesting user or group) so that access canbe granted.

• Authorization Rules support the enforcement of context-based access policiesby taking into account the context of the request and environment whengranting or denying access to a user or group.


azn_decision_access_allowed_ext(

azn_creds_h_t creds,

azn_string_t protected_resource,

azn_string_t operation,

azn_attrlist_h_t app_context, //context provided by the caller

int *permission, //result of the access request

azn_attrlist_h_t permission_info //implementation specific information

//about the decision

);

Figure 3.16: AZN API

The use of authorization rules in principle supersedes POPs and ACLs. Byusing POPs and ACLs better performance results are obtained, and thereforerules are rather used to complement ACLs and POPs [tiv03]. The protected objecthierarchy allows to store information in the form of extended attributes for useby external authorization services. Tivoli Access Manager’s architecture allows toplug in these external services.

Authorization API

Tivoli Access Manager allows to enforce rich policies that can take into accountthe following information:

• User credential entitlements are attribute-value pairs that are added to theclient credential during authentication or during a transaction.

• Application context information denotes information that is specific for therequest, such as the value of the current transaction.

• Authorization engine context information includes the protected object andthe operations that a user wants to carry out.

• Dynamic access decision information is retrieved from external dedicatedentitlement services at the time that an access request is evaluated. Anexample is the quota a user has.

Figure 3.16 shows how this information is reflected in the Authorization(AZN) API included by the access manager, which implements the Open GroupAuthorization API standard [OG].

The access decision is based on a weighted sum of the decisions of externalauthorization services and the authorization engine that is included in TivoliAccess Manager. The latter verifies whether the requester holds the requiredpermissions on the object and the permission to traverse the hierarchy to the


object (traverse permission). The required permissions for each operation have tobe configured by the security administrator.

Privacy Manager is an extension of the Access Manager to support dynamicrole activation. It includes a role engine that adds users to a dedicated (dynamic)group whenever a set of conditions formulated on the application and requestcontext are met. This membership only holds for the duration of the request.This way the rule can be enforced that only the patient’s primary care physiciancan modify a patient’s record.

Integration with Tivoli

The Authorization API can be invoked by a resource manager of the AccessManager Family or by a third party application. WebSEAL is an example of sucha resource manager to control access to web resources. WebSEAL can cope withdynamic URLs by mapping these on protected objects, as shown in Figure 3.15.

Besides the C API, Tivoli Access Manager also includes java classes that buildon JAAS. This implementation uses the implies -method of the PDPermission

to invoke the authorization server.Tivoli Access Manager can also be integrated as a JACC provider (e.g. for

the Websphere application server). A permission is placed as an object in theprotected object space and the role that is granted the permission is added as anextended attribute.

The application is responsible for gathering the necessary information formaking the access request. This includes mapping the accessed resource ontothe protected object space, translating the operations in terms of the predefinedrights, and retrieving context information necessary for the access decision.

Centralized Management with Tivoli Access Manager

As discussed before, a protected object space provides a uniform view on theapplication resources within an organization. Tivoli Access Manager uses a centralauthorization engine as its decision point. Optionally, this decision point can bereplicated locally.

A Plug-In Architecture for Customization

The access manager’s plug-in architecture allows to extend the architecture withservice plugins. These libraries are written by application developers and allow toexchange domain-specific data.

Several types of plug-in services are supported. The most important forauthorization are the External Authorization Service and the Entitlement Service.An Entitlements Server enables application developers to supplement accessmanager’s authorization with their entitlements model. For example, the Access


Manager Protected Objects Entitlement Server returns a list of protected objectsfor which a given user credential has specific access privileges. An ExternalAuthorization Server (EAS) is an external authorization engine that is invokedwhen a trigger is satisfied. The trigger can be a POP trigger that is satisfied whenaccess is requested to a particular protected object. A trigger condition can alsoselect based on the action that is invoked.

Conclusion

Tivoli Access Manager provides a flexible architecture that allows to enforceexpressive policies. The architecture modularizes the access decision logic in aseparate authorization service. However, it is the responsibility of the applicationto map the request to the protected object and action, as well as to provide allnecessary context information.

3.4.6 Summary

In Figure 3.17, we evaluate the technologies discussed in this chapter with regardto the three criteria presented in Section 3.3. By means of a ‘+’, ‘–’ and ‘0’, weindicate how well a technology supports a particular requirement. An ‘x’ indicatesthat the access control technology does not provide the function. The symbolbetween brackets refers to how the technology is typically used. For example, RADdoes not provide an enforcement point, but this will be typically implemented bymeans of explicit access control checks that allow for a fine granular but non-transparent access control enforcement.

The evaluation is carried out according to the following three dimensions:expressiveness, system evolution and uniformity.

Expressiveness. All access control technologies that provide a policy enforce-ment point provide interface method granularity (indicated by ‘0’). The richnessof an access control technology is determined by the richness of on the one handthe policy decision point and on the other hand the policy information point.The former evaluates whether the PDP can cope with context information, e.g.by means of the specification of attribute functions (such as RAD [BDB+99])or an access decision function that takes an extra context argument (such asTivoli [Kar03]). Few access control technologies provide a PIP. OSA and ODMrequire the application to register attribute retrievers and domain managers,respectively. A number of technologies do not expose the interface to their policydecision point. For these cases, we have provided an overall quotation for therichness criterion.

System Evolution. A PIP that has a ‘0’ quotation for extensibility canbe extended with a programming effort. E.g., the access control information


in JAAS can be extended by the implementation of a new permission class.The system evolution-criterion evaluates in addition whether access control isenforced transparently to the application, and whether the policy decision pointis modularized, and therefore can be easily replaced with a new implementation.

Uniformity. In the abstraction column, it is indicated which abstraction is usedby the access control technology: permission(‘p’) , right (‘r’) and action-object (‘a-o’). For the latter, it is also indicated whether the action and object only representsthe application-specific method invocation (‘–’) or abstracts from it (‘+’), as is thecase in RAD [BDB+99] and Tivoli [Kar03]. The last column evaluates the supportprovided to manage the policy centrally.

3.5 Conclusion

In this chapter, we have discussed a number of access control technologies andconclude that they fail to reconcile the requirements stated in the beginning of thischapter. In general, it turns out that we have to choose between the enforcement ofa rich and granular policy, and a transparent enforcement of an invocation policy.Such an invocation policy only supports interface method granularity and failsto include context. A number of technologies allow to abstract from application-specific requests, such as RAD and Tivoli. The application developer is responsiblefor applying the abstraction before invoking the authorization engine, which resultsin access logic that is entangled in the application. These problems are symptomsof the fact that these access control technologies fail to modularize the enforcementof context-based policies.

The modularization of access control enforcement is a prerequisite to supportevolution of access control. To enable a uniform enforcement of one access controlpolicy, it is important that an access control technology provides support toabstract from application-specific details. We will show that this abstraction alsosupports evolution as it enables a traceable top-down integration of an accesscontrol policy in an application. In the next two chapters, we will present anapproach that allows to enforce a context-based policy in a uniform and adaptableway.

3.5

Conclu

sion

57

Figure 3.17: Evaluation of State-of-the-Art Technologies

Expressiveness System Evolution Uniformitygran. rich. ext. PIP transp. PEP modul. PDP abstr. centr. mgmt

PDP PIP

Embedded PDP

e.g. J2EE program. + + 0 – – – –Whitebox Framework

JAAS x(+) + 0 0 x(–)/0 + p 0Blackbox Framework

RAD x(+) + x(+) x(0) x(–) + +(a-o) +TAM x(+) + x(+) x(0) x(–) + +(a-o) +TAM + ResourceManager (WebSEAL) 0 + + – + + +(a-o) +Component Framework Service

J2EEdeclarative 0 0 – + x p 0J2EE + JACC 0 + + – + + p 0

CORBASecinvocation access policy (level1) 0 0 – + x r 0access policy (level2) x(+) 0 0 – x(–) + –(a-o) 0OSA 0 + + 0 + + –(a-o) 0ODM (alternative ado itf) 0 + + – + + –(a-o) 0sec.aware + RAD x(+) + x(+) x(0) x(–) + +(a-o) +

COM+/.NETdeclarative 0 0 – + x p 0

legend:+ well supported0 neutral– badly supportedx(. . . ) functionality is not provided (symbol

between brackets evaluates standard use)p permissionr righta-o action-object

Chapter 4

Uniform Enforcement of

Evolving

Application-Domain-Specific

Policies

State-of-the-art technologies fail in satisfying all the requirements that pertain tothe enforcement of application-domain-specific policies. In Chapter 1, we havediscussed that the contributions of this thesis are threefold:

1. the definition of an abstraction layer for access control that enables a uniformand centralized enforcement of one evolving organization-wide application-domain-specific policy in a number of applications that are deployed withinthe organization.

2. the definition of an access control service that binds this abstraction layerto each of these applications.

3. the specification of a comprehensive set of evaluation criteria that can beused to evaluate access control technologies

The abstraction layer is the topic of this chapter. In Chapter 5, the access controlservice is discussed. The evaluation criteria are specified and applied to ourapproach in Chapter 6. The content of this chapter is based on the followingtwo papers:

• T. Verhanneman, B. De Win, F. Piessens and W. Joosen, UniformApplication-level Access Control Enforcement of Organizationwide Poli-

59

60 Uniform Enforcement of Evolving Application-Domain-Specific Policies

cies, Twenty-First Annual Computer Security Applications Conference,2005 [VWPJ05]

• T. Verhanneman, F. Piessens, B. De Win and W. Joosen, RequirementsTraceability to Support Evolution of Access Control, Proceedings of the 2005workshop on Software Engineering for Secure Systems - building trustworthyapplications, 2005 [VPWJ05a]

4.1 Overview of the Approach

This section briefly overviews the new concepts, access interface and viewconnector.

An access interface provides an abstraction layer, providing a view on theapplication that reflects only information relevant for access control. An accessinterface can be seen as a subset of a domain model that specifies all informationneeded to formulate the access policy. Such an access interface should be relativelyconstant within one organization and its specification may be application-domain-specific, as it is driven by the high-level policy rules of the organization. Forexample, in a financial organization, the value of a transaction might be importantinformation to decide about an access request. In a hospital, on the other hand,it is important to know whether the access request represents an overrule accessor not.

The access interface may need to be bound to a number of applications. Thisis done by specifying an application-specific view connector for each application.This view connector is conceptually a deployment descriptor or configurationfile that maps application-specific concepts (such as methods) to the conceptsrepresented in the access interface. Figure 4.1 illustrates how these concepts enablethe top-down integration of an access control policy in an application.

Access Control Policy

Access Interface

security officer

Bindingapplication deployer

application developer

View Connector A View Connector B

Application A Application B

Figure 4.1: Top-down integration of an access control policy

4.1 Overview of the Approach 61

Separation of Concerns. Figure 4.1 also shows how these concepts supportthe delimitation of the responsibilities between the stakeholders involved in theintegration of access control enforcement in the application:

• The security officer manages the access interface and the policy centrallywithout requiring extensive knowledge of the internal operation of thedifferent applications.

• The application deployer configures the access control enforcement by theapplication, ensuring that it conforms to the policy.

• The application developer provides the application logic.

Centralized Authorization Engine. There are several alternatives to imple-ment the integration of an access control policy in an application. Figure 4.2illustrates how a centralized organization-wide authorization engine can be usedto evaluate access requests. The access interface captures the domain-specificconcepts that are common to all deployed applications. The authorization enginereceives notifications of access attempts from the application in terms of thisaccess interface, and can also query applications for additional application stateto decide whether to grant an access request or not. The authorization enginecan be configured by means of declarative policy rules that specify the accesscontrol policy in terms of the access interface, and consequently, are application-independent.

AuthorizationEngine

Access InterfaceView Connector A

Implementation


View Connector BImplementation

Access Control

Policy


Figure 4.2: Realization with a centralized authorization engine

The remainder of this chapter is organized as follows: Sections 4.2 and 4.3further elaborate on the access interface and view connector, respectively.Section 4.4 discusses the approach and evaluates to what extent it meets thespecified requirements. Section 4.5 concludes this chapter.


4.2 Access Interface

The access interface views the application as a set of target objects and subjects.A subject can make an access request to perform an action on a target object.

An access interface consists of a number of object interfaces and a numberof subject interfaces. A subject interface corresponds to a role, and an objectinterface corresponds to a policy group. These interfaces declare the informationthat the policy may need in the form of attribute declarations. An object interfacedeclares in addition semantic actions. These semantic actions abstract syntacticactions and represent the security sensitive operations to which the policy applies.In particular, an access interface must specify which application events representaccess requests for access objects, and which information must be provided for theevaluation of these requests.

Note that the precise syntax and semantics of the policy language that is usedto express the access control rules is open in our approach. The only assumptionis that the policy language is able to cope with the (common) abstractionssubject, object and action and with attributes for subject and object. Forexample, Ponder [DDLS01], and the extensible Access Control Markup Language(XACML) [OASa] are suitable policy languages.

A brief formalization of the access interface can be found in Section 4.2.3. First,an example is given in the health care application domain.

4.2.1 A Health Care-Specific Access Interface Example

We will illustrate the approach by means of a subset of the access control policyspecified in Chapter 2, and show that the specification of the access interface is thefirst step in refining a high-level abstract policy into a specification-level policy.

The High-Level Abstract Policy

The following rules are withheld from the policy in Section 2.4:

Rule 1 A physician will be granted access to a patient’s data if a contact existsto which he was assigned. The access rights are only valid until 30 days after thecontact was closed.

Rule 2 The system provides the possibility to overrule the access decision, oncondition that the user requesting access specifies a reason. The reason, therequesting user’s and the patient’s name, along with some context information(time, place) are logged.

Rule 3 The patient’s general practitioner (GP) has view access to all the patient’scontacts, whether these contacts have been closed or not.

4.2 Access Interface 63

To implement aggregation control, we keep track of the number of accessrequests per day by a physician, and introduce following (contrived) rule. If thenumber of accesses exceeds a given limit L, further access is denied.

Rule 4 If the number of view accesses by a physician in one day exceeds a limitL, further access to identifiable medical data is denied.

Figure 4.3 shows the formulation of this last rule in the Ponder policylanguage [DDLS01].

inst

auth- limitViewAccess {subject <PhysicianRole> s=/PhysicianRole;

target <MedicalData> t=/MedicalData;

action view;

when s.nbAccesses ≥ L;

}

Figure 4.3: Policy Specification in Ponder

The Access Interface

These high-level rules indicate which concepts should be included in the accessinterface.

Roles. Within the user -group, two roles can be distinguished: A PhysicianRole,who is a staff member and a licensed medical practitioner (e.g. a specialist), andthe GPRole (general practitioner), who maintains the overview of the patient’ssocial background, medical history and current health condition and acts as aconfidant for the patient.

Permissions. This policy only concerns objects that represent identifiablemedical data. The status of medical data can be open or closed, depending onwhether the contact the data is part of, has been closed or not. The operationsthat can be carried out on a medical data object are restricted to view, appendand close. The latter is invoked by the patient’s responsible physician to close thecontact. A special init action, create, is introduced to represent the permission tocreate medical data objects.

The above-mentioned rules can be formulated in terms of an access controlmatrix, as represented in Figure 4.4. The matrix represents a closed policy, whichimplies that access is only granted if at least one matching entry can be found.RBAC96 [SCFY96] lacks granularity to enforce these rules, because this accesscontrol model does not take into account context information. For an access


decision, the relationship between the user requesting access and the patient whosedata is about to be accessed should also be taken into account [Bez00]. Thepresented access interface includes both attributes that represent the application’sstate, as well as context information that pertains to a specific access request orsession, such as for example an access mode attribute that indicates whether theoverrule option is called upon.

A subset of an access interface for the health care application domain is shownin Figure 4.5. For completeness, the syntax for access interfaces in EBNF notationhas been included in Section 4.2.2.

Roles/status (Medical Data) open ≤ 30 days closed >30 days closed

PhysicianRole create N/A N/A

if responsible and nbAccesses < L view,append,close view -

if in overrule mode and nbAccesses <

L and log (licenseID, patientID, time,location, reason)

view view view

GPRole

if patient’s GP view view view

Figure 4.4: Access Control Matrix


AccessInterface HealthCare {

ObjectInterface MedicalData{

attribute: boolean closed;attribute: Date closingTime;attribute: String responsiblePhysician;attribute: String GP;attribute: String patientID;

action: view;action: append;action: close;init: create;

}

SubjectInterface PhysicianRole{

attribute: String licenseID;attribute: int nbAccesses;attribute: boolean accessmode;attribute: String reason;attribute: String location;

}

SubjectInterface GPRole{

attribute: String licenseID;}

}

Figure 4.5: Access Interface for the Health Care Domain


4.2.2 Access Interface Syntax

Figure 4.6 shows the concrete syntax of the access interface in EBNF notation.We assume that a library is available that contains frequently used types, such asfor example a Date or a String . The type of an attribute is either one of thesetypes or a primitive type, e.g. an integer or a boolean.

Access Interface

access-interface ::= ‘AccessInterface’ ai-name ‘{’{ object-interface | subject-interface}‘}’

I Object and Subject Interfaces

object-interface ::= ‘ObjectInterface’ oi-name ‘extends’ oi-name ‘{’{attribute}{action}‘}’subject-interface ::= ‘SubjectInterface’ si-name ‘extends’ si-name‘{’{attribute}‘}’attribute ::= ‘attribute’ ‘:’ type attr-name ‘;’action ::= (‘action’ | ‘init’) ‘:’ act-name ‘;’

II Types and Identifiers

type ::= ( ref-type | prim-type ) {‘[’ ‘]’}prim-type ::= ‘boolean’ | ‘char’ | ‘byte’ | ‘short’ | ‘int’ | ‘long’ | ‘float’ |‘double’ai-name, oi-name, si-name, attr-name, act-name, ref-type ::= identifier

Notation: ::= definition ‘bold’ terminal {. . . } repetition (0 times or more)[. . . ] optional | choice (. . . ) precedence

Figure 4.6: Access Interface EBNF notation

4.2.3 Access Interface Semantics

This section contains a brief formalization of the access interface. The accessinterface views the application as a set of target objects (referred to as accessobjects) and subjects (access subjects). An access interface A consists of a set O

of object interfaces (one per policy group) and a set S of subject interfaces (oneper role).

Object interfaces. An object interface O for a given domain is a pair (attr, act),whereby:

1. attr denotes a set of attribute names, specifying the information that theauthorization engine needs about objects, and V alues(a) denotes the set of


possible values for a given attribute a ∈ O.attr

2. act denotes the set of relevant actions, about which the authorization engineexpects to be notified. The act set contains a special subset init capturingthose actions that initialize the access object. In the evaluation of an accessrequest involving an init action, we cannot take into account the accessobject’s attributes, as these have not yet been initialized.

An object interface can extend another object interface. This is syntactic sugarto avoid a duplicate specification of actions and attributes. Osub ≺ Osuper impliesthat Osub.attr ⊂ Osuper .attr and Osub.act ⊂ Osuper .act.

Note that the object interface is application-independent: actions and at-tributes are specified at an appropriate level of abstraction for making accesscontrol decisions. Binding these attributes and actions to actual applicationconcepts, will be the task of the view connector.

Subject interfaces. A subject interface S for a given role specifies theinformation that the authorization engine needs about subjects in that role inthe form of a set of attributes attr. As for the object interface, V alues(a) denotesthe set of possible values for a given attribute a ∈ S.attr

A subject interface can extend another subject interface. Ssub ≺ Ssuper impliesthat Ssub.attr ⊂ Ssuper .attr.

Access objects and subjects. The access control view on an applicationconsists of a set O of access objects and a set S of access subjects. Each accessobject o ∈ O has one associated object interface objectinterface(o) and likewise,each access subject s ∈ S has one associated subject interface subjectinterface(s).As will be explained in the next section, the view connector defines the protectionstate of each access object and subject. The protection state of an access object orsubject is determined by the values of the attributes specified in their associatedobject interface and subject interface respectively. The protection state of anaccess object o can be written as σ(o) = (va)a∈objectinterface(o).attr , where eachva ∈ V alues(a). Similarly, the protection state of an access subject can be writtenas σ(s) = (va)a∈subjectinterface(s).attr , where each va ∈ V alues(a).

Implementing the policy. An access request is a triple (s, o, a) consisting ofan access subject s, an access object o and an action name a in the action name setact of objectinterface(o). The access policy is the function that, given an accessrequest (s, o, a) and the protection states σ(o) and σ(s) returns whether the accessis allowed or not.

We assume that the current time can be taken into account when evaluating anaccess request. In this definition of the access interface, we do not provide support


for the specification of other environmental state. The motivation is that wehave not yet encountered examples in practice that call for the ability to specifyadditional environmental state. The access interface can be extended easily toinclude this type of information, however.

4.3 View Connector

The access interface specifies access requests at an abstract level. At some point,this needs to be translated down to actual application concepts. This is the roleof the view connector. We say that a view connector binds an application to theaccess interface. For the remainder of this thesis, we assume that the applicationsthat need to be access controlled are written in an object-oriented programminglanguage. Each application will need its own view connector.

To implement a view connector one must:

• Decide how application objects map to access objects.

• Identify all operations on such data and map these operations to thecorresponding actions in the object interface. This also determines all placeswhere an access check needs to be performed.

• Determine how to compute the necessary attributes for access objects andsubjects.

The next section first illustrates the above-specified concepts by means ofan application example in the health care application domain. The syntax andsemantics of this view connector are specified in Section 4.3.2 and Section 4.3.3,respectively. In these sections, we will focus on how this view connector is specified,rather than how it is realized.

4.3.1 View Connector for a Health Care Application

The organization-wide policy specified above must now be enforced in allapplications running in the hospital, such as for example an appointment andprescription system. Given the increased use of information technology in healthcare, the number of applications can be quite high.

We describe a simplified model of one example application: an IntegratedCare Pathways (ICP) application. An Integrated Care Pathway [MBR03] is apredefined plan for care relating to a certain diagnosis, which serves as a guidelineto organize care more effectively and efficiently; e.g. to shorten hospital stays,to raise resource utilization and to reduce unnecessary variations in patient careand outcomes. In short, an ICP constitutes a workflow, which guides the healthcare provider through the different steps in the health care process by providinga template, indicating the health care services that should be provided at a

4.3 View Connector 69

Figure 4.7: Pregnancy ICP

visit1

visit2

visit3

visit4

visit5

visit6

visit7

visit8

visit9

visit10

wk 6-8 wk 10-12 wk 16-18 wk 22 wk 28 wk 32 wk 36 wk 38 delivery postpartum

Screening WeightBlood pressureFetal heart tones....

Immunization & Chemoprophy

Influenza...

Admin Schedule Next Visit

certain point in the treatment. Upon commencing the treatment, the responsiblephysician instantiates an ICP for his patient, and plans and executes the steps asthe treatment proceeds. These steps are, for example, examinations, medicationprescriptions and notes. In Figure 4.7 [Opd] a simplified care pathway forpregnancy is shown to illustrate the concept of an ICP.

Figure 4.8 shows a simplified class diagram for the ICP application. Theapplication contains support to construct a template for an Integrated Pathway.The ICP -object captures the workflow context and can be seen as a shared datarepository for the tasks in the workflow. These tasks are represented by theStepTemplate -classes. When a task is performed, a Step -instance is created, e.g.capturing results of an examination, and associated with the corresponding ICP .Different types of steps are supported, such as a basic action step (e.g. a weightmeasurement) and a decision step of which the next step to be taken depends onthe outcome of certain conditions. Step templates can be composed and reused tohierarchically build up care pathways.

We will now discuss the view connector that binds this ICP-application to theaccess interface for the health care domain that is presented in Figure 4.5. Theview connector for this ICP-application is shown in Figure 4.9.

Mapping. The medical data to protect is contained within the Integrated CarePathway (ICP ) and its associated steps (Step ). The application keeps a referenceto both the GP of the patient and the responsible physician.

Access enforcement points. The access enforcement points in the applicationare the points in the execution, where an access check needs to be done. Theinsertion of access checks at all these points is technology dependent. This canbe done, for example, by inserting the necessary calls to the authorization enginein the application code. In the view connector presented in Figure 4.9, everyinspector (getter) on an ICP -object is classified as a view action.

70

Uniform

Enfo

rcem

ent

ofE

volv

ing

Applica

tion-D

om

ain

-Spec

ific

Polici

es

Figure 4.8: ICP-application

ICP

+getPatient(): Patient

+getResponsiblePhysician(): Physician

+close(): void

+getSteps(): Step[]

+getCreationTime(): Date

+isClosed(): boolean

+validate(): void

Patient

+getGP(): GP

+getName(): String

+getSSN(): String

GP

+getLicenseID(): String

Personnel

+getDepartment(): Department

+getName(): String

Physician


Technician

Step

+planNextStep(): void

+getParentStep(): ComposedStep


StepTemplate

+perform(icp:ICP,c:Client): void

+getParentStepTemplate(): ComposedStepTemplate

+getNextStepTemplate(): StepTemplate

ComposedStep

+getStepAt(index:int)

ActionStep

+execute(pers:Personnel)

DecisionStep

1

*

responsible

*

11

*

1*

1

*

*

1


ViewConnector ICPConnector binds HealthCare {

obj-map : ICP binds MedicalData {

restricted Date closure defaultvalue null;after() close { closure = new Date();};

attributesresponsiblePhysician: wrappee.getResponsiblePhysician().getLicenseID();GP: wrappee.getPatient().getLicenseID();closed: wrappee.isClosed();closingTime: closure;patientID: wrappee.getPatient().getSSN();

actionsview : * getter(..);close: void validate();

initcreate: ICP.new(..);

}

subj: PhysicianRole {

final String licenseID;final String loc;restricted int accessCount defaultvalue 0;after(MedicalData+ m) view {accessCount = accessCount+1;};

boolean accessMode defaultvalue false;String reason defaultvalue “ ”;

attributeslicenseID: licenseID;nbAccesses: accessCount;accessmode: mode;reason: reason;location: loc;

}}

Figure 4.9: View Connector Specification


Attribute computation. The view connector specification needs to specify howeach of the access interface attributes is computed for the given application. Forinstance, an ICP object in the example application (Figure 4.8) is clearly medicaldata. The responsible physician for that object (referred to as “wrappee”) can becomputed via a getter on the ICP class. The patient’s GP must be computed byfirst getting the patient associated with the medical data, and then getting theGP of that patient. If possible, the attributes are retrieved from the application.Otherwise, the view connector can declare fields to hold additional state.

The part of the view connector that computes these attributes, is similar toBeznosov’s attribute functions [Bez02b], or to the DynamicAttributeService inCORBA’s Resource Access Decision (RAD) service [BDB+99].

Access Control Information (ACI) Update. Sometimes the access controlinformation that is withheld in the view connector needs to be updated in responseto an event. For example, keeping track of the number of accesses to medical datarequires that this number is updated after each access. An extensive treatmentof the update of access control information is out of scope for this thesis. TheaccessCount-attribute specified by the view connector in Figure 4.9 illustrates thisACI update. This counter is updated each time a physician accesses a MedicalDataobject.

In the remainder of this section, we elaborate further on the syntax and thesemantics of the view connector.

4.3.2 View Connector Specification Syntax

We keep the view connector simple and map object interfaces to application types.One such mapping consists of three parts, namely domain mapping, (for objectinterfaces only) enforcement points and attribute retrieval. Figure 4.10 presentsthe EBNF syntax for the view connector. The syntax for the type, parameter andmethod patterns is similar to aspectJ [aspb].


View Connector

view-connector ::= ‘ViewConnector’ vc-name ‘binds’ ai-name ‘{’{obj-intf-map}{subj-intf}‘}’

I Domain Mapping

obj-intf-map ::= ‘obj-map’ ‘:’ type ‘binds’ oi-name ‘{’ {aux-field | update }[‘attributes’ { attr }] [‘actions’ {act}] [‘init’ {init}] ‘}’

subj-intf ::= ‘subj’ ‘:’ si-name ‘{’ {aux-field | update }[‘attributes’ ‘:’ { attr }] ‘}’

aux-field ::= [ ‘final’ ] [ ‘restricted’ ] type field-name[‘defaultvalue’ java-expression] ‘;’

II Attribute Computation

attr ::= attr-name ‘:’ java-expression ‘;’update ::= (‘before’ | ‘after’) ‘(’ [(si-name | oi-name) [‘+’] ] var ‘)’

act-name ‘{’{ field-assignment}‘}’ ‘;’

III Access Enforcement Points and Initialization

act ::= act-name‘:’meth-pat ‘;’meth-pat ::= { [‘!’] mod-pat } ret-pat [ type-pat ‘#’] meth-name-pat

‘(’ [arg-pat [{ ‘,’ arg-pat }]] ‘)’

init ::= act-name ‘:’ construct-pat ‘;’const-pat ::= { [‘!’] mod-pat } [ type-pat ‘.’] ‘new’ ‘(’ [arg-pat [{ ‘,’ arg-pat }]] ‘)’

field-assignment ::= field-name ‘=’ java-expression ‘;’

Types, Patterns and Identifiers

arg-pat ::= type-pat | ‘..’ret-pat ::= ‘void’ | type-pattype-pat ::= ‘(’ type-pat ‘)’ | ‘!’type-pat | type-pat ‘&&’ type-pat |

type-pat ‘||’ type-pat | id-pat [‘+’] {[ ]}mod-pat ::= ‘public’ | ‘protected’ | ‘private’ | ‘static’ | ‘abstract’ | ‘final’

id-pat ::= prim-type | (identifier | ‘*’){ ( ‘.’ | ‘..’) (identifier | ‘*’)}meth-name-pat ::= identifier | ‘*’ | ‘getter’ | ‘setter’prim-type ::= ‘boolean’ | ‘char’ | ‘byte’ | ‘short’ | ‘int’ | ‘long’ | ‘float’ | ‘double’

vc-name, ai-name, oi-name, si-name, field-name, attr-name, act-name, param-name,var, type ::= identifier

java-expression supports ‘wrappee’-variable and the ability to retrieve an accessobject for a given application object: ‘@’oi-name‘(’var ‘)’

Notation: ::= definition ‘bold’ terminal {. . . } repetition (zero or more)[. . . ] optional | choice (. . . ) precedence

Figure 4.10: View Connector EBNF Syntax


4.3.3 View Connector Semantics

Conceptually, the view connector can be subdivided into two parts, namely anauthentication part that keeps track of the principal on behalf of whom access isrequested, and an access enforcement part that verifies whether an access requestconforms to the access policy. The latter deals with the binding of access objects,while the former is concerned with access subjects.

Access Objects

The object interface mapping is limited to a mapping on one or more applicationtypes. To ensure that an application object corresponds to at most one objectinterface in an object oriented language with single inheritance, an object interfacecan only be bound to a class type. This binding is indicated in the view connectorconfiguration by means of the binds keyword. An object interface that is bound toan application type, is automatically bound to all the latter’s subtypes, and thisbinding can not be overridden.

Attributes. The view connector has to ensure that the application can produceall the attributes that are introduced in the object interface. Such an attributemay be present in the application itself. In this case, the view connector declaresa mapping such that the attribute can be retrieved from the correspondingapplication object. A special construct, wrappee, refers to the application objectinstance that is associated with the given access object. In this definition of thesemantics of the view connector, an access object cannot exist without being linkedto an application object instance, and therefore the construct can be used at alltimes. We add the requirement that attribute retrieval functions have to be pureand should not have any side effects on the application. The retrieval of attributesis limited to those that can be obtained from the public interface of the object.

Sometimes, a required attribute is not present within the application and has tobe held by the view connector in the form of fields. The type of such a field can be atype declared by the application, a type from the library (Section 4.2.2), a primitivetype or an object interface. The view access allows to retrieve the access objectassociated with an application object, e.g. the MedicalData access object md foran ICP application object icp can be retrieved as follows: @MedicalData(icp) .

In its most general form, an attribute is a java-expression that takes intoaccount the state of the access object and the associated application object. Werequire that an access object is able to produce all declared attributes for all accessrequests for each action, except for init actions, presented in the object interface.Default values can be specified for fields.

Access Enforcement Points. The access control enforcement points aresimilar to so-called execution-joinpoints in aspect-oriented languages. This means


that the access control check occurs in the beginning of the method body execution.Application methods can be selected based on method name, return type andargument types. The application methods an action is mapped on, should bevalid methods on the type (or its subtypes) bound to the object interface. If thetype in the pointcut is omitted, the type to which the object interface is boundis assumed. The type can be included explicitly if for example a method declaredby a subtype needs to be mapped onto one of the actions in the object interface.Multiple statements that involve the same action are allowed and are composed ina disjunction. Not all actions declared in the object interface need to be presentin the view connector. Init actions are mapped onto constructors.

Access Subjects

During authentication an access subject is established, which represents a principalwithin the application. In our approach, a subject interface corresponds to thenotion of a role. The implementation needs to ensure that instances can be createdof all the subject interfaces that are declared in the access interface.

Access Control Information (ACI) Initialization and Update

Access control information may need to be updated to reflect a changingapplication’s protection state. This may be triggered by any application event. Tokeep the view connector description simple we limit these events to the securityrelevant events, i.e. access requests for an action in the access interface. Weonly allow updates of local fields that are declared by the binding to keep theinterference with the application to a minimum. A field may therefore only beupdated by the access object or subject that holds the field. The information thatthe subject or object has at its disposal to update its local fields is the access objector subject that is also involved in the access request. An update may be carried outeither before the access request evaluation or after the access. For init actions fieldupdates are only supported after the access. For an object interface binding an aciupdate before the action a is represented as follows: before(SubjectInterface

s) a { update of the fields } (s represents the caller)For a subject interface binding: before(ObjectInterface o) a { update of

the fields } (o represents the object being accessed)In the case multiple updates need to be carried out before or after an action, theaccess subject involved is updated first, and then the access object.

Fields that are declared final, cannot be changed after initialization. Therestricted field modifier indicates that a field in the subject interface, e.g. thenumber of accesses (nbAccesses ) may only be set by the access control component.Fields in an object interface are by default restricted. The non-restricted attributesof an access subject can be modified by a subject that acts on behalf of thataccess subject. Examples of attributes are the accessmode in the PhysicianRole




String responsiblePhysicianID defaultvalue null;after(PhysicianRole+ p) create { responsiblePhysicianID = p.licenseID;};

attributesResponsiblePhysician: responsiblePhysicianID;. . .

initcreate: ICP.new(..);

}}

Figure 4.11: Alternative ICP View Connector

subject interface. This restricted keyword reflects the requirement that accesscontrol information needs to be access controlled on its turn.

Figure 4.9 already illustrates how the number of view accesses of MedicalDataby a PhysicianRole can be updated. This way of updating fields also allows tosupport owner-based access control models easily, whereby ownership is assignedto the creator. In Figure 4.11 we rewrite the view connector in the assumptionthat the responsible physician for a piece of medical data cannot be retrieved fromthe application, and should be set to the identifier of the physician who has createdthe data.

4.4 Discussion

This section contains a discussion of the proposed approach. It starts with anevaluation with respect of the requirements introduced in Section 3.3. Section 4.4.2discusses how the view connector can be realized, and a number of possibleextensions are described in Section 4.4.3.

4.4.1 Evaluation

In the following paragraphs, we discuss the expressiveness, the evolvability andthe uniformity of the presented access interface - view connector approach.

Expressiveness: The Enforcement of Context-Based Policies

The Richness of the Access Interface. The amount information that canbe taken into account when evaluating an access request is fixed by the access

4.4 Discussion 77

interface. By means of the introduction of attributes, we can take into accountthe state of the access object and subject involved. These attributes can also beused to establish relationships between access object and subject, as was illustratedby the introduction of a responsiblePhysician-attribute in the MedicalData objectinterface. Attributes on a subject interface can be used to simulate history-basedaccess control to a certain extent, as illustrated by the nbAccesses-attribute inthe PhysicianRole interface. The access interface does not allow to take intoaccount the arguments of an access request. This was a conscious choice to limitthe complexity of the specification of the binding. We found the expressivenessoffered by the access interface is sufficient to support the implementation of theexample access control policy presented in Section 2.4.

Extension to Systems with Distributed Trust. The definitions of theaccess interface and view connector are tailored to a centralized access controlmanagement in a closed environment. This assumption still holds for a largenumber of organizations. However, there exist scenarios in which the principalswho request access to resources, are not known in advance to the local authority.In service-oriented architectures, for example, trust relationships often need to beestablished to authenticate principals or to delegate authorizations. In such anenvironment it may also be important to keep track of the intermediaries on thepath of an access request.

Support for open systems can be provided by extending the subject interfacewith support for more complex principals, and by capturing, for example,delegation between principals. Delegation allows a principal to act on behalf ofanother principal. A good starting point for the extension of the subject interfaceis the ABPL logic [LABW92] (by Abadi, Burrows, Plotkin and Lampson). Thiscalculus introduces the “speaks for” relation to describe who is trusted by whomand how authorization is propagated between principals. So-called compoundprincipals can capture quotation (A quotes B), delegation (A for B), and roleassumption (A as B).

Administration Scalability. A trade-off may need to be made betweenexpressiveness and other requirements. E.g., defining a large number of objectand subject interfaces should be avoided in order to keep the policy manageable.

The Granularity of the View Connector. The view connector supportsaccess control enforcement with interface method granularity. The authorizationengine can decide based on the subject’s and object’s attributes whether or not aparticular policy rule applies.


Separation of Concerns and Evolution

In Section 4.1, we have divided the responsibilities between the stakeholders asfollows: The security officer specifies the access interface and the deployer theview connector. We will now motivate how this facilitates the evolution of accesscontrol enforcement.

Policy Management. Firstly, the evolution of the policy is more straightfor-wardly supported. Consider for this purpose the following additional rules:

Rule 5 Each time the person accesses a patient’s medical data, the responsiblephysician for this medical data is notified of this access.

Rule 6 Psychiatric - and human heredity records are classified as highly sensitive,and cannot be viewed by the GP [UZL].

Since Rule 5 fully complies with the access interface introduced in Section 4.2.1,adding the rule suffices to enforce it uniformly.

Rule 6 requires an extension of the medical data access interface to support asensitivity attribute and the definition of the necessary attribute mappings in thecorresponding view connectors. Our approach provides better support to applythis extension, because the view connector captures explicitly which applicationobjects represent medical data. A limited consistency check can be carried outto verify whether mappings have been defined for each attribute in the accessinterface.

If the policy changes more radically, new object and/or subject interfaces mightneed to be introduced with corresponding view connectors.

System Evolution. In case the application or its setting changes (e.g. due tocode refactoring), it suffices to adapt the view connector.

Uniformity

The introduction of the access interface supports a central management of anorganization-wide policy. View connectors support its enforcement in diverseapplications. In a large-scale application, a large number of object types andmethods will be typically mapped onto a limited number of object interfaces andactions respectively. Referring to the small ICP example application introducedin Section 4.3.1, the pregnancy ICP in Figure 4.7 introduces approximately 30different actions steps. These are all regarded the same for the access controlpolicy, as the view connector allows to treat these steps uniformly as medicaldata.

4.4 Discussion 79

4.4.2 Realization of the View Connector

The view connector as described above can be used in a number of ways to integratethe enforcement of an access control policy in an application: First, it can serve asa mere design artifact that aids in coding access control checks in the application.This approach does not fully benefit from the ability to modularize access controlenforcement, but still improves the evolution of the access control enforcement,as is discussed in the previous section. In the same way, the view connector canbe used to generate (application server) deployment descriptors. However, theseoften lack expressive power as is discussed in Chapter 3.

Based on the view connector, the policy can also be woven in the application(with or without an explicit representation of the access interface abstractionlayer), by making use of aspect orientation. A change in the policy then requiresthe access control enforcement to be rewoven.

In our design described in the next chapter, aspect orientation is used to bindthe access interface to the application, and the access control request evaluationis deferred to an external authorization engine.

4.4.3 Implementation Alternatives and Extensions

Access Interface. In Section 4.4.1, we already suggest two extensions, namelyfor the subject interface and for the actions. We also considered an alternativedesign for the access interface, whereby an attribute can also represent anassociation with another access subject or object. This means that the type ofan attribute can be an object or a subject interface. This also results in thecomparison of references instead of values, whenever a relationship needs to bedetermined between an access object and subject involved in an access request.The number of attributes in the access interface decreases when these references areallowed. We found that relying on these references is less suitable in a distributedcontext. References to access subjects are volatile if, for example, a new one iscreated for each session.

View Connector. The proposal for the view connector that was described inthis chapter, closely corresponds to the application class diagram. In addition,support could be provided to map an access object on different program elements,such as the execution of a method or a group of application objects, e.g. a medicaldata object could be associated with an ICP and all its associated steps.

Another extension (included in the design presented in [VWPJ05]) is to notonly map access objects but also access subjects on the application. Sometimes,the application contains classes that conceptually correspond to an access subject,such as the Physician class in the ICP application. The advantage is that mappedsubject attributes are automatically kept in sync with changes in the application.On the other hand, the complexity of establishing an access subject (e.g. during


authentication) is increased, because the application object that corresponds tothe access subject has to be determined.

Application methods are grouped into actions according to their signature.This could easily be extended to incorporate other conditions, such as for examplethe value of the arguments.

When defining the access interface and view connector, we aimed at striking agood balance between expressive power, practicability and usability (of the viewconnector as a configuration artifact).

4.5 Conclusion

In this chapter, an abstraction layer for access control is defined that enables a uni-form and centralized enforcement of one evolving organization-wide context-basedpolicy in a number of applications that are deployed within an organization. Thisaccess interface specifies all the information that is needed by an authorizationengine to enforce the access policy. For each application, a view connector needsto be written to specify the binding of the access interface to the application.

Chapter 5

A Modular Access Control

Service for

Application-Domain-Specific

Policies

In this chapter, we will show how the access interface and view connector conceptscan be integrated in a modular access control service. This access control serviceshould be realized as a reusable component that can be bound to an applicationwithout requiring invasive changes to this application. The crosscutting nature ofthe interaction of the access control enforcement with the application mandatesthe use of aspect-oriented software development techniques in order to realize thismodular access control service.

In this chapter, we will first give a brief overview of Aspect-Oriented SoftwareDevelopment (AOSD) in Section 5.1. Then the design of the access control serviceis discussed in Section 5.2. The implementations of this service in JAC and CaesarJare discussed in Section 5.3 and Section 5.4 respectively. This chapter is wrappedup by a conclusion in Section 5.5. The contents of this chapter is based on followingpapers:

• For the JAC prototype:

– T. Verhanneman, F. Piessens, B. De Win and W. Joosen, ViewConnectors for the integration of Domain Specific Access Control,Report of the workshop on AOSD Technology for Application-levelSecurity (2004) [VPWJ05b]

81

82 A Modular Access Control Service for Application-Domain-Specific Policies

• For the CaesarJ prototype:

– T. Verhanneman, F. Piessens, B. De Win, E. Truyen and W. Joosen,A Modular Implementation of an Access Control Service that supportsApplication-specific Policies, IEEE Distributed Systems Online [VPW+06]

– T. Verhanneman, F. Piessens, B. De Win, E. Truyen and W. Joosen,Implementing a Modular Access Control Service to Support Application-Specific Policies in CaesarJ, AOMD ’05: Proceedings of the 1stworkshop on Aspect oriented middleware development [VPW+05]

5.1 Aspect-Oriented Software Development

This section briefly discusses aspect orientation. For a more complete overview ofAOSD, we refer the reader to [Cra01, p 29-97].

Aspect orientation is based on the observation that current paradigms,such as object orientation, fall short in modularizing so-called crosscuttingconcerns. Crosscuttingness characterizes a relationship between concerns. Animplementation with well-established separation-of-concern techniques (e.g. objectorientation), results in software that is decomposed according to one dominant con-cern (i.e. the application logic), and that spreads and entangles the implementationof the other concerns. An example of a crosscutting concern is application-levelaccess control logic: its implementation is spread all over the application and isoften entangled with application logic [DJP05].

A large variety of AOSD approaches have been presented. According toFilman et al., the additional concept that these approaches have in common toreduce scattering and entangling of the implementation of crosscutting concernsis quantification [FF00]. Quantification enables us to formulate statements thathave an impact on various points in the code. An example statement is “each timea method is invoked on an object, it should be verified whether the invoker hasauthorization to do so”.

The construct, with which this is realized, is called a joinpoint. A joinpoint is apoint in the program execution where the (in our case) access logic is superimposedon the application. Typical joinpoints are method invocations, exception handling,execution flows. So-called pointcuts allow us to select a set of joinpoints based onone or more of their characteristics; e.g. the name of the method invoked or thetype of the target object. Advice is the logic injected into the application at thejoin point; in this case we would like to inject access control enforcement checks.There are different kinds of advice: Before and after advice is respectively executedbefore or after the join point. Around -advice runs instead of the joinpoint. AOSD-approaches typically provide support for a proceed -construct to execute the originaljoinpoint in such an around-advice.

5.2 Access Control Service Overview 83

Authorization Engine

View Connector View Connector

Application a Application b

Access Interface

binding to the application

semantic actionsobject interfaces

subject interfaces (roles)attributes

evaluateAccessRequest

Access Policy

Collaboration

checkAccess

informationRetrieval

Figure 5.1: Access Control Service

Filman et al. [FF00] also mention obliviousness of the application developerregarding the applied aspect, as a second characteristic of aspect-oriented ap-proaches. This obliviousness is relevant in that the application developer shouldnot be concerned with writing or integrating security logic. At the level of thecomposition, it should be explicit in what ways a superimposed aspect affects theapplication and other aspects to be able to reason about the behavior of the overallsystem.

5.2 Access Control Service Overview

Access Control Service

The focus of this chapter lies on the implementation of a modular access controlservice that can enforce expressive policies taking into account application-specificstate. This access control concern crosscuts the application in an intricate way:whenever a security sensitive operation is performed, it has to be verified whetherthe corresponding access subject has the authorization to do so. Still, the accesscontrol service should be bound to an application without requiring invasivechanges to this application, so that the authorization policy can be changed (bypreference declaratively) without needing to modify the application itself.

Figure 5.1 shows that the access control service can be implemented as acollaboration between the following three entities: a (third party) authorization


engine, an access interface and the view connectors, each binding the accessinterface to a particular application. The view connector makes use of the accesscontrol decision functionality (checkAccess ) each time an application event occursthat is annotated as one of the semantic actions in the access interface. ThecheckAccess method takes three arguments: the access subject, the access objectand the access method being invoked. Either all (subject and object) attributesare pushed to the authorization engine, or alternatively, the authorization enginequeries the view connector, through the access interface, to pull the required objectand subject attributes. The authorization engine then evaluates whether an accessrequest conforms to the policy. The design of the access control service allows toplug in such an authorization engine easily.

The access control service realizes the three access control enforcementfunctions discussed in Section 3.2.1. The authorization engine represents thePolicy Decision Point (PDP). The Policy Enforcement Point (PEP) and PolicyInformation Point (PIP) are implemented by the implementation of the viewconnector. The latter is also referred to as the binding of the access control serviceto the application.

Binding. The implementation of the binding differs between the two approachesand will be discussed in depth in the following sections. They have in commonthat the view connector declares pointcuts so that advice is woven before theexecution of every security sensitive access. The following steps are performedin this advice: first the method execution is translated in terms of the accessinterface in accordance with the view connector specification, resulting in an accesssubject, an access object and action. Figure 5.2 illustrates this in the contextof the Integrated Care Pathways (ICP) application, which has been introducedin Section 4.3.1. The method PregnancyICP.getInfectiousDiseaseRisk() 1 istranslated to a view -access on a MedicalData -object. The AccessSubject isretrieved from the subject that is associated with the control flow. If the retrievalof the AccessSubject fails, then access is denied by default. This informationis sent to the authorization engine for evaluation. If access is granted, the callproceeds and otherwise an access error is reported.

Container Service. An interesting application for this access control service isits realization as a container managed service, provided by an application serverto the application without the application needing to be aware of it. The serviceshould be easily configurable by means of a deployment descriptor, i.e. the viewconnector specification. The service then enforces the desired access policy byintercepting critical operations, calling the authorization engine, and enforcingthe latter’s decision.

1The PregnancyICP -class is not shown in the class diagram of the ICP application (Figure 4.8).

5.2 Access Control Service Overview 85

pICP: PregnancyICPpICP.getInfectiousDiseaseRisk()

vc: ViewConnector

ae: AuthorizationEngine

[allowed] proceed()joinpoint

2/ boolean allowed=ae.checkAccess(phys,med,"view")

phys: Physician

med: MedicalData

1/ mapping -> phys,med,"view"

sub:Subject

Figure 5.2: Collaboration Diagram

Authentication

Both prototypes include support for simple password-based authentication. Forthe ICP application, a subject is created per ICP client. Similar to JAAS,this subject represents an active entity within the system and initiates the loginprocedure with the authentication module. The latter is responsible for verifyingusername and password, and for associating the corresponding principal(s) withthe subject. As shown in Figure 5.3, the subject holds these principals so that thelogin procedure only has to be carried out once. An access subject can be regardedas one of these principals. The assignment of an access subject to a subject can bedone in a number of ways, and will be discussed later on. The crosscuttingness ofthis simple authentication concern with the core application is very limited, as itonly consists in creating a subject that represents the client and carrying out thelogin procedure before the client is started. When implementing authentication,we need to take into account how the system is distributed and the (absence of)trust relations between the nodes of the system.

Subject

+getPrinipals(): Set<Principal>

Principal

+getName(): String

+equals(other:Principal): boolean

1

AccessSubject UserPrincipal ...

*

Figure 5.3: Subject and Associated Principals

In the next two sections we will discuss two prototypes of the access interfaceand view connector implemented in Java Aspect Components and CaesarJ. Thedescription of each of these prototypes will be introduced by a brief description ofthe characteristics of the language and execution model, illustrated by an exampleauthentication aspect.


5.3 Prototype Implementation in Java Aspect

Components

In this section, the Java Aspect Components (JAC) prototype is discussed. Theprototype was implemented in 2003-2004 by T. Denoulet and M. Desmet as partof their master’s thesis [DD04]. The definition of the access interface and viewconnector was still in an early stage according to the description in [VPWJ05b].

5.3.1 Java Aspect Components

JAC [PSDF01] is an extensible application container that was developed as anapplication of the research carried out by R. Pawlak [Paw02]. This platformprovides an aspect-oriented middleware layer that allows dynamic (un)loading ofaspect components. Below, we discuss JAC and refer to some details that arespecific for version 0.11.

Aspect Module Model: Aspect Components

A JAC container supports the deployment of two types of components, namelyso-called POJOs (Plain Old Java Objects) and Aspect Components. The lattersupport the modularization of crosscutting concerns. An aspect componentsupports a number of ways to modify a base application, including the weavingof method invocation interceptors (called wrappers) at specific joinpoints. JACimplements a so-called asymmetric aspect model as it distinguishes between thebase application on the one hand, and the aspect layer on the other hand. Thislayered approach implies that the wrappers cannot be advised on their turn.

An aspect component serves as a unit of deployment that can be loaded andunloaded dynamically.

Binding: Pointcuts, Wrappers and Advice

Listing 1, illustrates a simple authentication aspect component. This authen-tication aspect component is associated with one wrapper (a SubjectWrapper)that intercepts each method invocation that matches the declared pointcuts. Anaspect component allows to declare pointcuts by means of the pointcut -method(Listing 1 line 10).

Pointcuts. The joinpoint model of JAC supports constructor and methodexecution joinpoints, and thus only supports joinpoints at the interface of a(POJO) component. A pointcut expression in JAC can include following fourparts: the name and class of the object instances to be wrapped, the methodsto be advised, and the name of the container in which the object instances aredeployed. The method can be selected based on its signature, i.e. method name,

5.3 Prototype Implementation in Java Aspect Components 87

package authentication;

import org.objectweb.jac.core.*;

5 public class AuthenticationAC extends AspectComponent{

private AuthenticationModule am = new AuthenticationModule();

public void session(String objects, String classes, String methods){10 this.pointcut(objects, classes, methods, "authentication.SubjectWrapper",

"session", null, true);}

}

Listing 1: Authentication Aspect Component

parameter types and return type, but also based on its effect on fields, e.g. accessorand modifier.

Pointcuts can be declared by invoking one of the pointcut -methods imple-mented by the AspectComponent-class. Listing 2 shows the signature of one ofthese methods.

public Pointcut pointcut(String wrappeeExpr, String wrappeeClassExpr, String wrappeeMeth,String wrappingClassName,String wrappingMethodName,String exceptionHandler, boolean one2one);

Listing 2: Pointcut-method

The wrappeeExpr , wrappeeClassExpr , and wrappeeMeth determine thejoinpoints, as described before. At load-time a chain of interceptors (orwrappers) is built that wrap the target object (referred to as the wrappee). ThewrappingClassName parameter refers to the class of the wrapper to be insertedin the wrapping chain and the wrappingMethodName indicates the wrapping-method that has to be executed at that point. The exceptionHandler parameterconfigures the method to call when an exception occurs. Depending on theconfiguration of the aspect component, an interceptor instance is either createdfor each wrappee-pointcut pair or shared between all joinpoints (indicated by theone2one parameter).

By making use of this pointcut -method, pointcuts can be hard-coded in anaspect component. As an alternative, we can also make use of the support thatJAC provides for the specification of a lightweight domain-specific language todeclare these pointcuts. The methods that are declared by an aspect componentcan be used to configure the aspect component after it has been instantiated. Thisis illustrated in Figure 5.4. The method AuthenticationAC.session , which takesthree arguments, can be used to specify the points at which user authentication


session ALL icp.ICPClient "run.*";

classes methodsobjects

authentication.acc

method declared in AuthenticationAC and its arguments

Figure 5.4: Authentication Aspect Component Configuration

needs to be performed.

Wrappers. Listing 3 shows the code for the interceptor that is associated withthe authentication aspect component. Note that one interceptor instance isconstructed per pointcut-wrappee pair. The information that the interceptor hasat its disposal is encapsulated in an interaction object (Listing 3, line 20), whichallows to retrieve the wrappee object, the invoked method and its arguments. Theproceed method (Listing 3, line 26) continues the interaction by invoking thewrapping method of the next wrapper in the chain (if any), or the method on thewrappee.

Advice. Wrapping methods support around advice as they allow to insert logicbefore and after, or instead of, the method execution joinpoint. A configurationfile allows to specify the order in which the wrappers will be assembled in wrapperchains.

Collaboration Flows. Code listing 3 (line 25) shows another feature of JAC,namely the ability to pass contextual information by means of a so-calledcollaboration flow. By making use of thread local variables, a collaboration enablesto store and retrieve attributes. In the access control service, this feature hasbeen used to convey authentication information with the access request. The useof collaborations creates dependencies that are implicit and therefore cannot beverified. Also measures need to be taken to protect the data that is put on acollaboration, as it can be publicly accessed and modified.

In this simple example, we assumed that the username and password can beretrieved from the ICPClient . Note that we store an explicit reference to thewrappee object at the beginning of the login-method. Outside an interaction, it isnot possible to get hold of the wrappee wrapped by the wrapper. Also the fact thata wrapper is created per pointcut-wrappee pair instead of per wrappee, render theJAC wrappers less useful for maintaining additional state for a wrappee.


package authentication;import med.*;import org.objectweb.jac.core.*;

5 public class SubjectWrapper extends Wrapper implements PasswordLoginSubject{

private AccessSubject as;private ICPClient w;

10 public SubjectWrapper(AspectComponent ac){super(ac);}

public String getUserName(){return w.getUser();

}15

public byte[ ] getPassword(){return w.getPassword();

}

20 public void session(Interaction i){w=(ICPClient)i.wrappee;AuthenticationModule m = (AuthenticationModule)

Naming.getObject("authenticationmodule0");if(m.login(this)){

25 Collaboration.get().addAttribute("subject", as);proceed(i);m.logout(this);

}else reportLoginFailure();

30 }

public void storeAuthToken(AccessSubject a){this.as = a;}public void reportLoginFailure(){ System.out.println("Login Failed");}

}

Listing 3: SubjectWrapper

Weaving at Load-Time

At load-time hooks are inserted in the byte code of classes. These hooks can beused to build the wrapper chain at run-time. For each application an applicationconfiguration file determines which aspect components should be deployed. Thecorresponding aspect components are created and configured according to theaspect component configuration file (see Figure 5.4). As a result, wrapperchains are created according to the specified pointcuts. JAC provides supportto dynamically weave and unweave aspect components.


Figure 5.5: JAC prototype: run-time

ApplicationA

Generic View Connector Implementation

accesswrapper

AuthorizationAspect

Component

JAC-Container

calleecaller

InformationRetriever

AuthorizationEngine

1

43

policy rules

view connector authorizationAC

Access ControlMediation

Mapping & Attribute Retrieval

1

2

Access ControlDecision Request

3

4 Access Control Decision Enforcement

applicationA config:

authorization true

...

2

A

D

BC

5.3.2 Design of the JAC Prototype

Based on the description of Java Aspect Components, the design of the prototypeof the access interface and view connector approach will be discussed. Figure 5.5shows the realization of the access control service with a centralized authorizationengine on top of JAC. The view connector implementation is generic and can beconfigured for a particular application by means of configuration files.

Instantiation of an Authorization Aspect Component. The applicationruns on top of the aspect-oriented middleware layer provided by JAC, i.e. theJAC container. The application configuration file (A in Figure 5.5) specifiesthat an authorization aspect component should be deployed. The authorizationaspect component is configured by means of the aspect configuration file (B inFigure 5.5) and by means of an XML file that specifies the view connector (Cin Figure 5.5). The aspect configuration file specifies (1) the location of theXML file containing the view connector specification, and (2) the pointcuts thatrepresent a security sensitive operation. Based on the view connector specification,the AuthorizationAC initializes itself by constructing an AccessWrapper andan InformationRetriever-object. The wrapper acts as a reference monitorand is reused for all joinpoints. The InformationRetriever-object obtains thenecessary attributes of the access objects by making use of Java reflection.

Access Control Enforcement. In this paragraph, an overview is given of thesteps that are carried out by the view connector implementation to enforce theaccess control policy:


1. Access Control Mediation: The wrapper first intercepts the access requestsat the execution points specified by the view connector configuration file, asexplained in Section 4.3.

2. Mapping: Based on the view connector the application-specific access requestis mapped onto the access interface by:

• retrieving the object interface applicable to the callee, i.e. the target ofthe method invocation.

• determining to which action in the object access interface, the accessrequest corresponds.

• retrieving the attribute values needed by the authorization engine bymeans of an InformationRetriever .

• retrieving the access subject that has been added to the collaborationflow by the authentication aspect.

3. Access Decision: The request is subsequently sent to the authorizationengine, which is discussed below, for evaluation.

4. Access Enforcement: The access decision is enforced.

The Authorization Engine evaluates the access request based on the access rules(D in Figure 5.5). In the above-mentioned approach, no knowledge of the internalsof the specific application is required, since the access request is translated intoterms of the access interface. In the prototype implementation, we opted to pushthe attributes to the authorization engine. The drawback is that more attributesare retrieved than may be necessary for the access decision. The advantage isthat roundtrips are saved, if the attributes can be retrieved locally and the accessdecision function is deployed on a different node. Alternatively, a lazy evaluationstrategy can be used, in which attributes are pulled by the authorization by meansof callbacks.

5.3.3 Discussion

A Container Service. From the description in the previous sections, it followsthat the view connector can be generated completely based on configuration files.We note that the introduction of fields for access objects and the update of thesefields are not supported by this prototype, because this was not included in theearly version of the view connector design. However, it is feasible to extend theprototype to include this support.

The JAC prototype described above, has been deployed on one local JACcontainer. JAC can be regarded as an extensible application container. However,we found that the distribution aspect in this version of JAC was too unstable tocarry out experiments successfully.


The Use of Annotations. JAC provides support to associate metadata withRun-time Type Information (RTTI). This facility can be used to annotateapplication classes and methods with respectively, the object interface and actionthat they represent. JAC does not provide sufficient support to consumethese metadata annotations. Pointcut languages in more recent aspect-orientedapproaches (AspectJ5 [aspa], JBoss [Bur04]) incorporate the use of annotationsin their pointcut language, which allows to match joinpoints based on theseannotations.

Aspect Dependencies and Interactions. For the implementation of thisprototype, the authorization aspect relies on the authentication aspect to associatean access subject with the collaboration. This collaboration flow only provides anuntyped interface, resulting in a dependency that is implicit and cannot be checkedat deployment time. An approach has been presented by Desmet et al. [DPJV06]that uses contracts to specify data dependencies of components and to verifywhether all these dependencies are fulfilled in a given component composition.

In this prototype, we also have to deal with a minor case of featureinteraction: We have to ensure that method invocations that are performed bythe authorization aspect to retrieve context information are not intercepted againby the AccessWrapper , possibly resulting in an endless stream of access requests.Two possible work-arounds to avoid this, are either using an attribute on thecollaboration flow to indicate that the following methods invocations are performedon behalf of the authorization component, or making use of the backdoor providedby JAC to bypass some or all wrappers in the wrapping chain.

Dealing with Access Denials. An open challenge that we faced in thedevelopment of this access control service is how to deal with exceptions orexceptional conditions originating within that service. This problem pertains toall services that are applied transparently to the application. Supporting fine-granular access control tends to make this problem even worse: In our prototype,an access denial could potentially occur at each method invocation. Consequently,the application is left in a state that may be inconsistent. A full treatment of thisexception handling lies out of the scope of this thesis. Further research is requiredto see whether, for example, the use of transactions or fault isolation techniquescan be used to address this problem.

Security of the JAC Framework. Security was not a concern in thedevelopment of the JAC framework. Wrapper chains can be easily bypassed anddata that is put on the collaboration flow can be freely read and adjusted, unlesscryptographic techniques are used to protect it. In [DPJ06] De Win et al. discussesa number of security risks in current AOSD approaches and also proposes an aspectpermission system to deal with some of these risks.

5.4 Prototype Implementation in CaesarJ 93

Performance Overhead. The JAC framework introduces a considerable per-formance overhead both at load-time and at run-time. Inserting hooks rendersthe loading of a class approximately eight times as slow as loading a regularclass [Paw02]. The overhead at run-time is primarily caused by the fact thatthe framework heavily relies on Java reflection to invoke the consecutive methodsin the wrapper chain. The implementation of the prototype also introduces aconsiderable overhead as it also relies on Java reflection.

5.4 Prototype Implementation in CaesarJ

In this section, the CaesarJ prototype is discussed. The implementation of thefirst version of the prototype was carried out by K. Geebelen in the context of hismaster’s thesis [Gee05]. The CaesarJ prototype is discussed in [VPW+05], and inan extended version of this paper [VPW+06].

Analogous to the description of the JAC prototype, we will start by givingan overview of the CaesarJ language in Section 5.4.1. Authentication andauthorization are discussed in Sections 5.4.2 and 5.4.3 respectively, followed bya discussion in Section 5.4.4.

5.4.1 CaesarJ

CaesarJ is an extension to the Java language, which is focused at a bettermodularization of concerns into reusable components. The main ideas behindthe language have been presented by Mezini and Ostermann [MO02, MO03]. Thecompiler is developed at the Aspect-Oriented Programming & Software Technologygroup at the TU Darmstadt [cae].

Collaboration Interfaces: Conceptual Overview. Before elaborating onthe language constructs that CaesarJ provides, an overview is given of the conceptsthat lie at the basis of this language. Central to this approach is the notionof a collaboration interface. This collaboration interface differs from a standardinterface in that it not only specifies what is provided by an implementation of thatinterface, but also what is expected from the clients of that interface. The provided-part of this contract is implemented by an implementation, and the expected-partby a binding. A binding and an implementation need to be composed to obtain avalid component.

Secondly, a collaboration interface provides explicit support for collaborationsin that it captures the interactions between abstractions that are characteristic tothe implemented concern. Caesar provides support for the use of wrappers to bindthese abstractions to the core application.


<<Binding>>

PasswordModuleBinding+PasswordModuleBinding(c:ICPClient)+getPassword(): byte[]+getUserName(): String

<<Weavlet>>

PasswordModuleWeavlet

Mixin Composition

PasswordModuleCI

+<<provided>> login(): boolean+<<provided>> logout(): boolean

+<<expected>> getPassword(): byte[]+<<expected>> getUserName(): String

+<<provided>> getLoggedInPrincipal(): Principal

Principal+<<provided>> getName():String

<<Implementation>>

PasswordModuleImpl+login(): boolean+logout(): boolean+getLoggedInPrincipal(): Principal

Principal

+getName():String

X

Figure 5.6: PasswordModule Collaboration Interface

Aspect Module Model: Collaboration Interfaces

Provided and Expected. In CaesarJ, an aspect is modularized in a collab-oration. In Figure 5.6 a simple collaboration interface is shown of a passwordlogin module. This module provides three methods, namely login() , logout()and getLoggedInPrincipal() . In order for this module to operate, the moduleneeds to be able to retrieve username and password of the principal who isattempting to log on. The figure also shows that the provided-part of theinterface is implemented by the PasswordModuleImpl and the expected-part bythe PasswordModuleBinding . An aspect implementation and binding class aretwo mixins that are composed together to form a weavlet. This weavlet canbe instantiated and deployed. Code reuse is improved as implementations andbindings of a collaboration interface can be combined interchangeably.

Collaboration interfaces, aspect implementations, bindings and weavlets areimplemented in CaesarJ by means of a so-called Caesar class (cclass ). A Caesarclass differs from a plain Java class in a number of ways: Below we discuss how aCaesar class can introduce virtual nested classes and supports mixin composition.We also discuss their ability to declare pointcuts and wrappers.

We note that in the current CaesarJ syntax, the subdivision of a collaborationinterface into implementation and binding part is implicit. This allows more


general scenarios, e.g. the composition of more than two cclass es into a weavlet.In the description of the prototype, we will always add in comment whether amethod is provided or expected.

Virtual Classes and Family Polymorphism. The term collaboration refersto the ability of a collaboration interface to declare a set of collaborating nestedclasses. These nested classes are virtual classes that, analogous to virtual methods,are inherited by each subclass of the encompassing (or outer) collaboration, andcan be overridden as well. CaesarJ supports family polymorphism [Ern01]. ACaesar class instance can therefore be seen as one family of classes that cannot beinterchanged with another family. The type of nested classes instances is thereforedependent on the outer cclass -instance, i.e. a dependent type.

Mixin Composition. Caesar classes differ from Java classes in that they aremixins. A mixin is a class that has a parameterizable superclass, and supports aflexible definition of inheritance hierarchies. By means of mixin composition (&operator), a new mixin can be declared that extends the component mixins. Thenew mixin inherits the members and methods of all composing mixins, includingvirtual classes. Virtual classes with the same name and nesting depth are mixedtogether.

When composed, the mixins are linearized to fix the order in which themixins are invoked when calls to the super-class are made. The CaesarJ languagespecification incorporates an algorithm for this linearization, which is carried outat compile-time. An error is generated in case of a conflict in the mixin order.

Binding: Pointcuts and Wrappers

The real support for modularizing crosscutting concerns lies in the binding. Twoconcepts are introduced: wrappers and pointcuts.

Wrappers. A binding class is a Caesar class that contains pointcuts or thatdeclares wrappers. These wrappers can adapt a normal class or a Caesar class.The wrapped object is called wrappee, and can be accessed by means of the specialwrappee variable. Conversely, we can also retrieve the wrapper of a wrappedobject (given the type of the wrapper). The wrapper recycling principle ensuresthat every time the same wrapper is returned. The wrappers in CaesarJ differ fromthose in JAC in that they do not automatically intercept method-executions. Inorder to call a method on a wrapper, the wrapper for an object has to be retrievedfirst. Often this is implemented in the advice of a pointcut.

Pointcuts. A binding class can also define pointcuts to declare the points whereadvice needs to be introduced. The pointcut language is similar to the AspectJ


<<<<interface>>>>

PasswordModuleCI

<<<<interface>>>>

PasswordModuleImpl

<<<<interface>>>>

PasswordModuleBinding

<<<<interface>>>>

PasswordModuleComp

PasswordModuleCI_Impl

PasswordModuleBinding_Impl

PasswordModuleImpl_Impl PasswordModuleBinding_Impl_Mixin PasswordModuleComp_Impl

interfaces

implementations

Figure 5.7: Generated Classes

pointcut language, and thus provides support for call , cflow and execution

joinpoints. The supported types of advice include before , after and around

advice. CaesarJ can be classified as a clearbox approach. A clearbox approachis an approach that is able to quantify over the parsed structure of the programand to examine the program’s internals, as opposed to blackbox approaches thatquantify over the public interface of a component.

Deployment. Weavlets are Caesar classes that can be deployed. The effectof deployment is that the advice of the pointcuts defined in the collaboration isactivated. Aspects can be deployed statically (as a singleton) by means of thedeployed modifier, or can be deployed in the scope of a specific thread by meansof a deploy block.

Compilation and Weaving at Compile-Time

The outcome of a successful compilation is a number of plain java class files.The CaesarJ compiler [AGMO06] generates a Java interface and a class for eachdeclared cclass (as shown in Figure 5.7). The PasswordModuleComp extends

PasswordModuleBinding & PasswordModuleImpl mixin is implemented by cloningthe PasswordModuleBinding Impl and replacing all references to the superclassto point to PasswordModuleImpl Impl . In a similar way, both an interface andimplementation hierarchy is built for the Principal nested class. The Caesarcompiler uses the AspectJ weaver to weave the advice. A description of thiscompiler can be found in [HH04].

In the following section, we will first elaborate on the implementation ofauthentication, which provides support for pluggable authentication modules.Section 5.4.3 contains a discussion of the implementation of the access controlservice in CaesarJ.


5.4.2 Pluggable Authentication Module Framework

In this section, the authentication aspect will be discussed in further detail, forillustration purposes. The authentication aspect implements a pluggable authen-tication framework (Figure 5.8) that allows to plug in different authenticationmechanisms in a so-called authentication stack. JAAS (Java Authentication andAuthorization Service), for example, provides such a pluggable authenticationmodule (PAM) framework. Central to this framework is a LoginContext

that determines how this stack should be built for a particular setting. TheLoginContext implements a two-phase commit algorithm. In the first round, themodules start the authentication procedure. This round is followed by a commit,if the overall authentication of the stack succeeds, or an abort otherwise.

In order to perform the authentication protocol, the modules may requireadditional information, such as for example the username and password of the userwho is trying to log on. In JAAS this is implemented by sending generic callbacksto the application’s callbackhandler. It cannot be verified whether the applicationwill be able to effectively provide the information required by the module.

In our CaesarJ version of the authentication framework shown in Figure 5.8,we have implemented these callbacks in a type-safe way by specifying each of thesecallbacks as an expected method in the module’s interface. E.g., for the Captcha-Module the binding needs to display a captcha and retrieve the user’s response.Listing 4 shows how the LoginContext can be deployed on the application.

import javax.security.auth.login.LoginException;

public deployed cclass Login{

5 void around(ICPClient c) : (execution(void ICPClient.run()) && this(c){try{

ICPLoginContextComp l = new ICPLoginContextComp(c);l.login();proceed(c);

10 l.logout();}catch(LoginException l){ System.out.println("Login Failed!");}

}}

Listing 4: Deployment of a LoginContext

5.4.3 Implementation of the Access Control Service

Analogous to the discussion of the JAC prototype, we discuss the implementationof the access control service in CaesarJ. In this section, we apply the approach to


LoginContext

+<<expected>> getModuleStack():ArrayList+<<provided>> getPrincipals():ArrayList+<<provided>> login():void

LoginContextImpl

+<<provided>> logout():void

ModuleInfo+ModuleInfo(Module m, Flag f, Map o)+getModule():Module+getFlag():int+getOptions():Map

ICPLoginContextComp

PasswordModuleImpl+<<expected>>getPassword(): byte[]+<<expected>>getUserName(): String+initialize(options:Map): void+login(): boolean+logout(): boolen+abort(): boolean+commit(): boolean+getLoggedInPrincipal(): Principal

CaptchaModuleImpl+<<expected>>getResponse(c:Captcha): String+initialize(options:Map): void+login(): boolean+logout(): boolen+abort(): boolean+commit(): boolean+getLoggedInPrincipal(): Principal

Binding

ICPClient+displayCaptcha(c:Captcha): String+displayLoginForm(): [String,byte[]]

ICPPasswordModuleComp ICPCaptchaModuleComp

ICPModuleBinding+ICPModuleBinding(c:ICPClient)+getUserName(): String+getPassword(): byte[]+getResponse(c:Captcha): String

Module

+<<provided>> login():boolean+<<provided>> logout():boolean+<<provided>> commit():boolean+<<provided>> abort():boolean

+<<provided>> initialize(options:Map):void

+<<provided>> getLoggedInPrincipal():Principal

Principal+getName():String+equals(Principal p):boolean

ICPLoginContextBinding+ICPLoginContextBinding(c:ICPClient)+getModuleStack():ArrayList

XX

X

Appl

Figure 5.8: Pluggable Authentication Module Framework in CaesarJ


AccessInterface

AccessObject

AccessMethod

AccessSubject

HealthCare

AccessSubject Physician+<<expected>>getLicenseID(): String+<<expected>> getAccessMode(): boolean+<<expected>>getNbAccesses(): int+<<expected>>getLocation(): String+<<expected>>getReason(): String

MedicalData

AccessMethod

ViewCreate Append

+<<expected>>getGP():String

+<<expected>>getResponsiblePhysician():String

GP+<<expected>>getLicenseID(): String

+<<expected>>isClosed():boolean

+<<expected>>getClosingTime():Date+<<expected>>getPatientID():String

AccessObject

AccessMethod Close

Figure 5.9: HealthCare Access Interface in CaesarJ

AuthorizationEngine+checkAccess(as:AccessSubject,ao:final AccessObject,am:o.AccessMethod): boolean

dependent type

Figure 5.10: Authorization Engine

the example application in this thesis, namely the ICP application. In [VPW+06,VPW+05], the approach is applied to a Calendar application.

Access Interface

The access interface is modeled as an abstract top-level Caesar class. This classdeclares two nested classes, namely AccessSubject and AccessObject . Thelatter, on its turn, declares a nested class AccessMethod . When an access interfacefor a specific application domain is to be implemented, the AccessInterface

is extended, and the necessary object- and subject interfaces are provided. Forexpected attributes, an (abstract) getter is provided. The access interface for thehealth care application domain then may look like in Figure 5.9.



The choice for a specific authorization engine can be left open. The interface ofthe authorization engine, shown in Figure 5.10, is independent of the specificaccess interface bound to the application. It only makes use of the abstractAccessInterface class, presented in Figure 5.9. As can be noticed, the typeof the parameter m depends on the object instance o, i.e. a dependent type. Thisguarantees that m is a valid action on o.

For the prototype, we have implemented the authorization engine ourselves.Integrating existing authorization engines is reasonable straightforward, however:One has to write an adaptor to translate the access request in a format the engineunderstands. The only assumption here is that the engine is able to cope withthe (common) abstractions principal, object and action, and with attributes forprincipal and object. We could for example integrate with the Ponder [DDLS01],or with the XACML framework [OASa].

In the implementation of this adaptor, we can choose to push all theinformation that the authorization engine might possibly need. Alternatively, alazy strategy can be used, whereby the authorization engine pulls the attributesby means of callbacks, whenever needed for the evaluation of an access request.

View Connector

In this prototype, we have implemented a view connector as a cclass , which bindsan AccessInterface to the application. In Listings 5 and 6, a small part of thisimplementation is shown, which binds the HealthCare access interface to the ICPapplication according to the view connector presented in Figure 4.9. It does thisby extending the corresponding access interface. Two parts can be distinguished,namely the declaration of wrappers and pointcuts.

Wrappers. Wrappers (Listing 5) implement the retrieval of attributes for(target) objects. These attributes may be retrieved from the application objectitself (by means of the wrappee construct) or may be declared by the wrapper.The view connector also implements the subject interfaces.

Pointcuts. Pointcuts (Listing 6) translate application-specific requests in termsof the access interface, wherever applicable, and invoke the authorization engine.Depending on its decision, the call proceeds or an access failure is reported.

In the pointcuts, we can get hold of the AccessSubject (Listing 6 line 12) onwhose behalf the access request is made. The view connector retrieves this accesssubject, by interacting with the subject deployed on the thread, which holds theactive roles for a user or process.

The pointcut specification also explicitly checks whether the joinpoint lieswithin the control flow of a checkAccess -method invocation, so that the retrieval


public deployed cclass ICPViewConnector extends HealthCareAccessInterface{

public cclass Physician {//fields

5 private String id;private int nbAccesses = 0;

. . .public Physician(String s, String loc){

id=s; location=loc;10 }

//implementation of the expected methodspublic String getLicenseID(){return id;}

public int getNbAccesses(){return nbAccesses;}15 public void setNbAccesses(int i){nbAccesses =i;}

. . .}

//[WRAPPERS]20 public cclass ICPMedicalData extends MedicalData wraps icp.icp.ICP{

public String getGP(){ return wrappee.getPatient().getGP().getLicense();}public String getResponsiblePhysician(){

return wrappee.getResponsibleCareGiver().getLicenseID().getLicense();25 }

. . .}

. . .}

Listing 5: View Connector for ICP Application (Wrappers)

of attributes by the authorization engine does not result in sending new accesscontrol requests to the engine.

5.4.4 Discussion

The choice to implement the prototype in CaesarJ was driven by the supportthe language offers to modularize aspects. A Caesar class allows to introduceabstractions as nested classes that are characteristic for the concern that needs tobe modularized. Expected and provided methods (although not explicitly enforcedin the current CaesarJ language) make explicit what functionality the aspectprovides and needs so that it can be bound to an application.

We have implemented semantic actions as virtual classes in the AccessInterface(Figure 5.9). This construction is needed because CaesarJ does not provideexplicit support to represent semantic actions. Reifying the semantic action allowsus to keep the interface of the access control service generic. CaesarJ’s familypolymorphism and dependent types, moreover, render the interface type safe.


public deployed cclass ICPViewConnector extends HealthCareAccessInterface {. . .

private AccessDecisionEngine ade;

5 //[PointCuts]pointcut verifyingAccess():cflow(execution(boolean ViewConnector+.checkAccess(. .)));

//MedicalData.VIEWObject around(ICP i): execution(* ICP+.get*(. .)) && this(i) && (!verifyingAccess()){

10

if(getSubject() == null) throw new AccessError();AccessSubject as = (AccessSubject)getSubject().getAccessSubject();

final ICPMedicalData sm = ICPMedicalData(i);15 boolean access = ade.checkAccess(as,sm,sm.new View());

if(access){Object o = proceed(i);if(as instanceof Physician) {

Physician p = (Physician)as ;20 p.setNbAccesses(p.getNbAccesses() + 1) ;

}return o;

}getSubject().handleAccessDenial(new AccessDenial("Access Denied"));

25 throw new AccessError();}

. . .}

Listing 6: View Connector for ICP Application (Pointcuts)

Below, we summarize how the concepts CaesarJ offers, are used to implementthe Access Control Service collaboration (Figure 5.1).

Access Control Service - CaesarJAuthorizationEngine - Collaboration Interface (provided operation)AccessInterface - Collaboration Interface

objects & subjects - abstract nested classesactions - concrete nested classesattributes - expected operations (declaration)

View Connector - bindingdomain mapping - wrappersinformation retrieval - expected operations (implementation)semantic actions + checkAccess - pointcuts

Figure 5.11: Access Control Service in CaesarJ

An Alternative Implementation. Instead of instantiating an AccessMethod

object (Listing 6 line 15), we could have implemented the semantic actions as(provided) methods on the AccessObject and invoked these in the advices of the

5.5 Conclusion 103

declared pointcuts. Implementing the semantic actions like this, would require thatwe repeat the checkAccess -call in the implementation of every provided method.This duplication of code can be avoided by declaring a generic pointcut in theAccessInterface that intercepts each provided method declared by an Access-

Object . Also, provisions should be made that the access subject is conveyed tothe authorization engine.

A Container Service. In the prototype implementation, we have implementedthe view connector ourselves by hand. In future research, we aim at generatingthe code of the view connector based on its descriptor.

Access Denials - Security - Implicit Dependencies. In this prototype,we face the same drawbacks as in the JAC prototype. Similar to the JAC-prototype, we have to deal with access denials. Measures need also to be takento ensure that the security mechanism cannot be subverted by, for instance, thesuperimposition of another aspect or an (unwanted) feature interaction. This callsfor the development of a permission system for aspects, to which the initial impetuswas given in [DPJ06]. Also in this prototype, there is an implicit dependencybetween the statically deployed access control aspect and the subject deployed onthe thread.

Type-System. CaesarJ includes a type system that enables us to write typesafe programs. At times, this type system proved too restrictive for what we need,however. The integration of two (or more) independently developed collaborationsmay be very cumbersome. We had this experience in the design of the PAMmodules, which create and associate access subjects with a deployed subject. Weended up writing a new binding that declares a nested wrapper class for eachsubject interface declared in the access interface.

Performance Overhead. It takes more time to compile the application, incomparison to a regular java application. A performance overhead is introducedat compile-time. The AspectJ compiler is roughly twice or three times slowerthan a standard java compiler [HH04]. The CaesarJ compiler will be slower as itgenerates additional class files, and performs additional type checks. Weaving alsointroduces an overhead at run-time. This overhead is small in comparison to therun-time overhead introduced by JAC, which uses Java reflection.

5.5 Conclusion

In this chapter, we have demonstrated by means of two prototypes that aspect-oriented software development techniques are capable of modularizing the enforce-


ment of context-based access policies. The reason is that aspect orientation is ableto capture the crosscutting interaction between the application and the accesscontrol concern. Further research is needed to make the aspect-oriented approachesthemselves more secure, so that it can be ensured that the access control logic isnot circumvented, and to deal with access denials.

Figure 5.12 summarizes the differences between the two aspect-orientedapproaches and Figure 5.13 gives a high-level comparison of the two prototypes.We note that the approaches were developed with a different goal in mind. The keydifference between the two approaches is that CaesarJ is realized as a language,and JAC as a framework. Both employ the notion of “wrappers”. In JAC thesewrappers are in fact interceptors that are composed in a wrapping chain arounda method. CaesarJ uses the wrapper design pattern to bind the abstractions thatare declared in the collaboration interface, to the application. The methods thatare provided by these wrappers have to be invoked explicitly in the advice of apointcut.

Collaboration interfaces in CaesarJ support the declaration of abstractionsthat are common to the modularized concern, and the specification of a providedand expected interface. This expected interface has proven useful in the designof the access control service to ensure that the application can produce all theinformation that is necessary for the access control decision.

The implementation of the view connector differs in both prototypes. The JACprototype includes a generic view connector implementation that can be configuredfor a particular application by means of an aspect component configuration file.The view connector implementation in the CaesarJ prototype is custom made for aparticular application and access interface. Generating this view connector basedon its specification is left for future work.

5.5

Conclu

sion

105

Java Aspect Components CaesarJ

Approach middleware (extensible container) languagetailored to non-functional concerns design patterns

Aspect ModelSymmetry 2 layers: POJOs and Aspect Components one type of module: cclass

Unit of Modularization AspectComponent (and associated wrappers) collaboration interfaceinterface only includes provided functionality interface includes both provided and expected

functionality

Abstractions reification of method call:Interaction, Wrappee

nested classesbound by means of the wrapper design-pattern

Advice Model - interceptors (providing around advice) - before(), after() and around() advice- wrapping methods- one interceptor per pointcut-wrappee pair orper application

- invocation of provided functionality

Joinpoint Model blackbox approach whitebox approachmethod execution joinpoints also support for call and cflow joinpoints

Pointcut Language syntactic + ACCESSOR, MODIFIERobject instances and host

syntactic (with wild cards)

WeavingWrapping chain is built for each method. Hooks are statically woven and cclass objects

are (un)registered dynamically.Deployment

Unit of Deployment AspectComponent Caesar classScope of Deployment per application (as dictated by the application

config file)per thread or statically

Configuration declaratively (can be updated at run-time) per thread deployment needs to be codedExperience

Compilation type-unsafe (e.g. use of reflection wheninvoking role methods)unchecked dependencies (e.g. collaborations)

type-safe (harder to get it compiled, errormessages make sense)

Runtime unclear error messages once it compiles, it mostly works

Figure 5.12: Summarizing Table: JAC and CaesarJ


JAC-prototype CaesarJ-prototypeFeatures mapping mapping, fields and update of

these fields

Design - Generic view connector imple-mentation

- Application-specific view con-nector implementation that bindsa specific access interface

- The InformationRetriever

translates an application-specificrequest in terms of the accessinterface.

- The translation is performed inthe advice of the pointcuts.

PIP - Attributes are retrieved by theInformationRetriever .- Java reflection- pushed to the engine

- A reference to a wrapper-object is conveyed to the engine,and attributes can be retrievedby invoking methods on thesewrappers.- expected interface

PEP one interceptor pointcuts

Type-Safety Java reflection typesafe

Configuration an authorization aspect config-uration and a view connectorspecification

(future work) generation of viewconnector

Adaptation at run-time at compile-time

Instrumentation at load-time at compile-time

Figure 5.13: Comparison of the two prototypes

Chapter 6

Evaluation and Related

Work

In this chapter, we will place the approach presented in Chapter 4 and 5 ina broader perspective. This is done in Section 6.1 by carrying out a morecomprehensive evaluation of our approach (and in particular the modular accesscontrol service). For this purpose, we list a set of criteria that can be usedto evaluate access control technologies. These criteria extend the requirementsthat have been put forward in Chapter 3. In Section 6.2, the applicability ofour approach with respect to state-of-the-art middleware technologies and model-driven engineering is briefly discussed. Subsequently, in Section 6.3, we discussrelated work with a different goal than ours, but which is relevant because ofits focus on, for example, the security engineering process, or the use of AOSD-techniques for security.

6.1 A Thorough Evaluation of the Access Control

Service

In this section, we place ourselves in the position of the security engineer (orapplication deployer), whose responsibility it is to design and implement the accesscontrol enforcement for an application. One of the subtasks is to select an accesscontrol technology based on its ability to enforce the articulated access controlpolicy, and other specified requirements. The criteria presented below, aid thesecurity engineer to evaluate a technology objectively. We focus on those criteriathat are relevant for access control technologies that centralize the access control(information) management. In these closed environments, all principals are knownby the system, and all access control information is managed by a central authority.

107

108 Evaluation and Related Work

I. Expressiveness Evolution

II. Policy Management III. System Evolution

- mediation gran.- richness- obligations- access denials

V. AssuranceIV. Scalability


- uniformity- administration scalability- access control policy mgmt- access control information mgmt- administrative policy- access control models- meta-policies- usability



Figure 6.1: Access Control Criteria

We have subdivided the criteria in five categories, namely expressiveness, policymanagement, system evolution, scalability and assurance. An overview of thesecriteria is given in Figure 6.1. In this section, the description of each criterionwill be immediately followed by an evaluation of our approach with respect tothat criterion. We will compare our approach with state-of-the-art access controltechnologies by referring back to the evaluation carried out in Chapter 3. In theconclusion of this section, this evaluation is summarized by an extended versionof the overview table presented in Figure 3.17.

6.1.1 Expressiveness

Policy expressiveness refers to the range of access control policies that can beenforced. As discussed in Section 3.3.1, this category evaluates (1) the mediationgranularity and (2) the richness of the access control technology. To this, we add(3) the support for obligations and (4) the settlement of access request denials.

Mediation Granularity

In Section 3.3.1, we defined the mediation granularity as a technology’s ability toselect access control mediation points.

Evaluation: One of the conclusions of Chapter 3 is that state-of-the-arttechnologies typically either only support interface method granularity, or leavethe mediation granularity to the developer’s discretion, in case the invocations tothe access logic are embedded in the application. The view connector in Chapter 4supports access control enforcement with interface method granularity, and istherefore less granular than access control solutions that embed access checks inthe application. To our knowledge, all proposed joinpoint models are capable ofsupporting this interface method granularity, and often allow a more fine-granularselection of joinpoints. E.g., JAC supports instance-based weaving by making use

6.1 A Thorough Evaluation of the Access Control Service 109

of a naming service. CaesarJ is a clearbox approach that allows a more intrusiveweaving, and for instance supports the advising of field accesses.

Richness

In Section 3.3.1, richness has been defined as the variety of information that canbe taken into account when evaluating an access request. Section 3.1.3 containsa classification of information that can be taken into account during an accessrequest.

Evaluation: With respect to state-of-the-art approaches, our approach consid-erably improves the ability to retrieve and take into account application-domain-specific attributes in the evaluation of an access request. The Resource AccessDecision Facility (RAD) [BDB+99] and Tivoli Access Manager (TAM) [Kar03]provide the ability to plug in a Policy Information Point (PIP), but they do notprovide support to bind this PIP to an application. The context-handlers inJava Authorization Contracts for Containers [Mon03] (JACC) allow to retrieveadditional contextual information concerning an access request. Contrary toJACC, our approach provides support to abstract from application details and todeclare additional security attributes, such as a sensitivity level for a target object.The Object Security Attributes (OSA) [Bez02b] approach allows the application toregister attribute retrievers (in CORBA). These attribute retrievers only provide ageneric interface to retrieve attributes, whereas the access interface in our approachmakes explicit which information can be provided by the application. The viewconnector specifies how attributes can be retrieved. Based on this specificationthe view connector implementation realizes the PIP.

As discussed in Section 4.4.1, the access interface can be extended to providesupport for request arguments, and distributed trust. The inclusion of the historyof access requests and decisions can be encapsulated by the authorization engineand therefore does not affect the interface between the application and the accesslogic.

Obligations

Typically, the outcome of an authorization decision is either grant or deny.Additional actions that should be performed in conjunction with the enforcementof this authorization decision can be supported. These actions are known asobligations or also as provisional actions [OASa]. Obligations can be requiredfor audit or non-repudiation purposes. E.g., an obligation may state that anemergency (overrule) access should be digitally signed by the access requester andis reported to the administrator for review before the access is granted.Obligations can declare inbound or outbound data filters to exercise fine-granularcontrols on for example method arguments or return results. E.g., an outbound


filter can be applied to ensure that only data is returned that originated from oneof the departments the user is assigned to.

Evaluation: Tivoli Access Manager can specify obligations by means of POPs(protected object policies). Our approach does not provide direct support forobligations. Obligations vary strongly in their interaction with the application.The implementation of a module that logs every access attempt is straightforward(e.g. consider Rule 2 in Section 4.2.1). AOSD techniques can be used to intercepteach invocation to the authorization engine, as an application of the aspects-on-aspects idea. Other obligations may involve complex interactions with therequesting subject, e.g. to obtain non-repudiable evidence of the request. Anoption is to extend the subject in Figure 5.3, so that it does not only provide theprincipals, but also deals with obligations that, for instance, necessitate interactionwith the user. Support for such an obligation can be included in the expected -interface of the access control service collaboration.

The Settlement of Access Denials

Expressiveness of a policy is also determined by the ability to specify the actionsthat should be undertaken when an access request is denied. An action denial mayfor example result in the abortion of an ongoing transaction. Depending on theway access control is integrated, this is typically dealt with in two ways. Whenaccess control checks are embedded in the application, the application can alsoembed logic to cope with occurring exceptions (at the expense of adaptability).Component platform services that are transparent for the application throw aruntime exception that needs to be dealt with by the client.

Evaluation: The modular access service exhibits the same problem as thecomponent framework services. In its implementation the subject is notified whenan access is denied so that it can take the appropriate actions. Employing theaccess control aspect in conjunction with a transaction aspect may prove usefulto bring the application back in a consistent state. The superimposition of theaccess control aspect modifies the component’s behavior, because this behaviornow also depends on the time, the protection states of the target object and theprincipal on whose behalf the component is invoked. Our approach may aggravatethe problem in the sense that access denials can occur in more places due to anincreased granularity of the mediation.

6.1.2 Policy Management

The set of criteria that belong to the policy management category, have in commonthat they measure the ease with which the policy is specified, deployed and updatedto cope with new requirements. Policy management is the first category thataddresses evolution. The second, system evolution, will be discussed in the nextsection.


Uniformity

In Section 3.3.3 uniformity has been defined as the degree to which one commonpolicy can be specified and enforced in a number of applications. Uniformityencompasses the requirement that the access control technology should shieldapplication specifics, such as the complex semantics of the diverse methods, fromthe security officer [Bez02a]. In addition, it requires the ability to centrally managethe policy.

Evaluation: In Section 4.4.1, we argue that the access interface introduces anabstraction layer that provides a uniform view on a number of applications, e.g.within the same application domain. This view is then bound to the applicationsby means of a view connector. Chapter 5 discusses one option to implementthis view connector as part of an access control service that uses an externalauthorization engine to evaluate access requests. This engine can be configuredby one policy that is then consistently enforced in all the applications.

The Resource Access Decision Facility [BDB+99] also supports the abstractionof application-specific requests by conveying a protected resource name and accessoperation to the access decision function. It is up to the developer to apply theseabstractions consistently before sending an access request, however. The sameholds for the Tivoli Access Manager [Kar03] that uses a protected object space.The URL mappings that the resource manager WebSEAL uses to map dynamicURLs on protected objects can be regarded as (limited) view connectors.

The grouping of application methods by means of roles in J2EE, permissions in.NET and rights in CORBAsec, also improves uniform access control enforcement.

Administration Scalability

Application-level access control may involve a large number of objects, principalsand actions, resulting in a large number of access control rules. To limit the numberof rules within the system, objects, actions and principals need to be grouped.

In Section 3.1.2, we have discussed how relationships can be defined betweenprincipals. Group and role principals are useful to keep the number of access rulesmanageable. This grouping can also be based on a principal’s attributes, such asfor example the department the principal is associated with. In [GFW02] resourcesand users are grouped implicitly based on their properties.

Object-oriented systems typically involve a large number of object types andinstances, and deal with a large variety of specific methods. Therefore, the accesstechnology should scale on a large number of objects and methods [Bla99, Bez02a].This can be done by formulating an access policy that protects a group of objects.This group is sometimes referred to as a policy group or domain.

There should be support to base group membership on the sensitivity or valueof the object, rather than on its name [Bla99] or location [Bez02a]. Also, transientobjects should be assigned automatically to a policy group, without requiring


human intervention or the knowledge of the objects’ names to roll out the policy.

With respect to methods, the system should provide a means to apply a policyto all methods with similar functionality or sensitivity [Bla99].

In a number of access control technologies, e.g. JAAS and .NET, this groupingis based on the permission that is demanded.

Evaluation: As the access interface allows for grouping of application objectsin policy domains and methods (in actions), scalability is assured. In general, theaccess interface should be far more concise than the application, such that a largenumber of application methods can be mapped onto one action. This shifts thescalability problem to the view connector that needs to enumerate the applicationmethods that map onto an action. Using a powerful pointcut language (partially)alleviates this problem. A pointcut may group a large number of applicationmethods based on the syntax of their signature, e.g. by using wildcards for methodnames and parameters. The specification of syntax-based pointcuts entails the riskto miss a sensitive access or to label too many methods as sensitive. Pointcuts maygroup application methods based on a number of their properties. JAC for examplesupports the grouping of methods that access a particular field. Annotations canbe used as an alternative. In addition to this domain mapping, attributes inobject and subject interfaces support implicit grouping. A policy rule can specifyconditions on the values of these attributes.

Access Control Policy Management

Access control policy management evaluates the ability to specify and update anaccess control policy. A policy may need to be updated because of a number ofreasons [Bro01], such as a change in the organization’s requirements, the failureof the original policy to meet the stated requirements, or the introduction ofnew objects and principals in the system. An adaptation of the policy may benecessitated by a change in the application itself, such as the passing of a workflowfrom one stage to another. In the View Policy Language [Bro02] (VPL), this typeof changes is supported by the use of schemas that update the access controlmatrix in response to application events. This criterion evaluates the support thatis provided to specify a policy and the ease with which this policy is updated.

Evaluation: Our approach supports a specification of the policy that is separatefrom the application. The additional policy rules introduced in Section 4.4.1illustrate that the approach supports policy evolution. Note that only securityrelevant operations are notified to the engine. To support schemas as in VPL,we could label these events as security relevant, or extend the access interface tosupport the specification of these application events.

The prototype implementations do not yet include a management interfacethat supports the specification of policy rules, or the management of objects andprincipals.


Access Control Information Management

A criterion that is strongly related to access control policy management isaccess control information management. Access control information managementevaluates the ability to manage access control information that is taken intoaccount when evaluating an access request. This includes the specification, theinitialization, and the update of access control information, e.g. as a response toan application event.

The authenticity of this information must also be safeguarded, and therefore,an administrative policy should be in place that specifies by whom this informationcan be updated. This can be seen as part of the administrative policy, a criterionthat is discussed next.

Evaluation: The access interface specifies access control information in the formof attributes. The view connector implementation can collect these attributes fromfollowing sources of access control information:

• Application-supplied information that is retrieved from the business logic.

• Externally supplied information refers to information that can be retrievedfrom a source external to the application, such as a database that containsuser data.

• Binding-supplied information is defined by the binding. An example is thesensitivity-level of an application object that is assigned to the object atconstruction time. A binding-supplied attribute may be modified eitherthrough an administration interface or as a response to an (application)event. The modification of the value of a binding-supplied attribute is initself a security sensitive operation that has to be subjected to access control.

The view connector supports the update of binding-supplied attributes before orafter the execution of a security sensitive operation.

Administrative Policy

The administrative policy determines who is authorized to modify the accesscontrol policy [SS94]. A policy domain can be seen as the “jurisdiction” under thecontrol of a certain authority. This may include a set of target objects (resources),principals, and the policy itself. By the term policy, we refer to the set of rulesdefined by one authority on a policy domain.

• Centralized Administration: The authority lies with one person or group ofadministrators.

• Hierarchical Administration: Authority is still exercised centrally, but canbe (partially) delegated to other administrators.


• Cooperative Administration: Several authorities have to cooperate to autho-rize access to particular target objects.

• Ownership: Each object has an owner (typically the creator) who can grantaccess rights to other principals.

• Decentralized Administration (Discretionary Access Control): Decentralizedadministration adds to ownership that the owner can also delegate the rightto administer the access rights on the objects s/he owns, and possibly transferownership.

Evaluation: Our approach is in principle neutral to the administrative policyused. However, the administrative policy in place might influence the informationthat is captured in the access interface. An owner-based or discretionary accessmodel may motivate the inclusion of an owner attribute for each target object.The support for a number of widely adopted access control models is discussed inthe next section.

Access Control Models

The support for access control models requires features that already have beendiscussed in other criteria. However, access control models like Mandatory AccessControl (MAC), Discretionary Access Control (DAC) and Role-Based AccessControl (RBAC), are so widely adopted that it makes sense to explicitly evaluatewhether they are supported by the technology under consideration.

Evaluation: In general, our approach does not provide explicit support for oneof these models, nor does it impede their implementation. The notion of an accesssubject is most closely related with the role concept in RBAC. In order to fullysupport RBAC, support is needed for role (de)activation, the specification of rolehierarchies and constraints.

To support DAC, an extension of the administrative policy is required. Theowner of an object can be captured by means of the specification of an attribute inthe object interface. However, the (limited) administrative model in our approachdoes not allow the owner of an access object to pass authorizations or ownershipon to other principals.

MAC can be supported by associating a security level to each access objectand a clearance to each access subject. It is the responsibility of the deployerto correctly label methods as either “read” of “write”. A write-access may evenrequire that the label of an object changes, e.g. when a sensitive record is appendedto a less sensitive record. We note that the enforcement of information flow policiesand the elimination of covert channels are out of scope for this thesis.


Meta-Policies

This criterion evaluates the support an access control technology provides formeta-policies. This includes for example composition of access decisions, andconflict resolution strategies. Meta-policies are needed in case multiple policies (ina cooperative or hierarchical administrative setting) or policy rules are applicableto a particular access request.

Regarding this criterion, an access control technology can be evaluated on thefollowing points:

• Policy Rules: An access control technology may support the specification ofpositive and negative rules that respectively grants or denies authorizationto a principal.

• Decision Policy [JSSS01]: The decision policy specifies the action thatshould be taken when the access is neither denied nor granted. A decisionpolicy can be either open or closed. The first grants access if no negativerule applies, whereas the later denies access if no positive rule applies.

• Rule Specialization: Sometimes, a relation between rules can be defined thatdetermines whether one rule is more specific than another rule. This is, forexample, the case if target objects are structured in a hierarchy (as is the casein Tivoli Access Manager). Another example is that a policy rule involvinga user principal may be considered more specific than the rules that applyto the group the user belongs to. Jajodia et al. [JSSS01] define a number ofauthorization rule propagation options: no propagation, no overriding, mostspecific overrides, path overrides. Examples of conflict resolution options aredenial/permission takes precedence, or the application of the decision policy.

• Policy Composition: This criterion evaluates whether the access technologyallows to specify which authorization authority prevails. For example,Tivoli Access Policy allows to assign weights to the decision of the externalauthorization services. For hierarchical administration it might make senseto give precedence to policies formulated by those authorities that are nearerto the source of authority (i.e. the owner) in the delegation chain.

Evaluation: Our approach is neutral with respect to this criterion, as thisdecision is encapsulated by the authorization engine.

Usability

The usability criterion measures the ease with which users, e.g. security officerand application deployer, of an access control technology can learn to employthe technology in an efficient, effective and satisfying way. The coverage of thiscriterion is out of scope of this thesis.


Evaluation: In the development of the prototype we did not focus on theusability criterion.

6.1.3 System Evolution

System evolution measures the degree to which an access control technology canbe evolved to support new requirements. As opposed to policy managementcriteria, system evolution focuses on the impact of changes in architecture ormechanism, rather than on access control policy specification. These changescan, for example, be driven by the requirement to enforce a new policy, theobservation that the access control system is badly implemented, and thus requirespatching, a migration towards a new application deployment platform/middleware,or application code refactoring.

In Section 3.3.2, we have mentioned three characteristics that positivelyinfluence the adaptability of an access control technology:

1. An extensible Policy Information Point (PIP) allows to support moreexpressive access policies

2. A modularized Policy Decision Point (PDP) allows to specify the policyseparately from the application, and moreover supports the replaceability ofthe security mechanism (the authorization engine).

3. A transparent Policy Enforcement Point (PEP) allows to relocate the accesscontrol checks. The absence of hard-coded access checks also implies thatthe application can be easily ported to another deployment platform withits own access control service.

This system evolution-criterion also evaluates at which point adaptations canbe carried through. A system may, for instance, support adaptation at compiletime or at run-time. The configurability of a system measures the ability to adapta system in a declarative manner.

Evaluation: The access control service in its entirety can be deployed andundeployed. In the JAC prototype this can be done at run-time, whereas in theCaesarJ prototype a deployment-statement is woven at compile-time.

The access control service itself is built in a modular fashion, so that it isstraightforward to plug in a different authorization engine, and to support anumber of policy specification languages.

The use of AOSD techniques allows us to keep the application logic free fromhard-coded access checks. An adaptation of the pointcuts suffices to relocate accesschecks as may be necessitated by new requirements. However, improvements canbe made to make these pointcuts more robust. The problem that pointcuts are totightly connected to the program’s structure, and therefore may become invalidwhen the program changes, is referred to as the fragile pointcut problem.


The policy information point can be extended by adding extra interfaces andattributes in the access interface. This requires that the view connector is extendedto support the retrieval of the necessary attributes. This approach allows us toascertain that all these attributes can be provided by the application, contrary tothe attribute functions (e.g. in RAD [BDB+99]) that provide a generic interface.

In the near future, we aim at raising the configurability of the access controlservice by generating the view connector automatically from its specification.

6.1.4 Scalability

The enforcement of access control adversely affects both run-time performanceand architectural scalability.

Run-time Performance

Access control enforcement results in an additional performance overhead. De-pending on the application and its environment (e.g. application server orembedded device) this overhead may be acceptable or not. Often performancecan be increased at the expense of adaptability. Below, two characteristics ofrun-time performance are described: throughput and delay.

The throughput of an access control technology equals the number of accessrequests that can be evaluated by the policy decision point in an interval oftime. There exist highly performant rule engines that can be used to increasethis throughput.

The delay is the time that is needed to dispatch, evaluate an access request andto enforce the resulting access decision. This time can be high if the access controlinfrastructure is distributed. Both Tivoli [Kar03] and Ponder [Dam02] supportthe use of local policy decision points to reduce this overhead. Another techniqueto lower this overhead is to estimate an access decision based on previously cachedaccess decisions [CLB06].

Evaluation: In the development of the prototypes, we did not focus on reducingthe introduced performance overhead. We will briefly discuss what can be doneto improve this requirement. The first observation is that the performance of theCaesarJ prototype is better than that of the JAC prototype by using compile-time instead of run-time weaving. This indicates that a trade-off needs to bemade between the adaptation and performance. The choice of a particular AOSDapproach therefore has already a major impact on the performance of the accesscontrol system.

In Section 4.4.2, a number of alternatives have been discussed to realize theaccess interface and view connector approach. In our prototype implementations,we opted for an explicit representation of the abstraction layer and an externalauthorization engine. Another option would be to weave a given policy in the


application based on the view connector specification. In this case, the policy canonly be adapted at run-time if the AOSD approach supports run-time weaving.

Architectural Scalability

Architectural scalability evaluates how well the access control infrastructurescales to a large-scale environment, e.g. with a large number of machines andapplications. Examples of this criterion are the ability to replicate components(e.g. the policy decision point) to remove a performance bottleneck within thesystem. Another example is a measurement of the effort to install the system.This installation may involve the configuration of a large number of heterogeneousdeployment descriptors. An access control technology may also include a policydeployment infrastructure that shields this complexity and allows to centrallymanage one policy on all the platforms. A last example is closely related withadaptability and evaluates the effort that needs to be done to carry throughchanges. E.g., if a policy is woven in an application, an update might requirethat all the affected applications are redeployed within the system.

Evaluation: In case the access control service is incorporated as a componentframework service the effort to specify the view connectors is expected to becomparable to the effort to specify J2EE deployment descriptors. When apolicy needs to be adapted, our approach scores better since it does not requirethe adaptation of all the descriptors (at least if the new policy is supportedby the access interface). The prototypes do not provide a policy deploymentinfrastructure.

6.1.5 Assurance

In [Sno05], Snow defines assurance work as a number of confidence buildingactivities that make a user more confident that the system works as intendedwithout flaws or surprises. These activities should assume the presence of malicerather than random failure. Below we have enumerated the five key points thataccording to Snow [Sno05] need to be demonstrated to build confidence:

1. The system’s security policy is internally consistent and reflects the require-ments of the organization.

2. There are sufficient security functions to support the security policy.

3. The system functions meet a desired set of properties and only thoseproperties.

4. The functions are implemented correctly.

5. The assurances hold up through the manufacturing, delivery, and life cycleof the system.


The level of assurance can, for example, be raised by means of the use of formaltechniques, code review, and testing. The latter includes stress testing with invalidinputs, boundary-condition checks.

Evaluation: Our approach raises the level of assurance by explicitly capturingthe policy of an organization and by enforcing this policy in a consistent manner.Still, a lot of work needs to be done to raise the level of assurance. In particular,work needs to be done that guarantees that the principle of complete mediation isfulfilled. This principle states that every sensitive access to an object should besubjected to access control.

6.1.6 Conclusion

In this section, we have specified a comprehensive set of criteria to evaluateaccess control technologies. Our approach scores well on a number of criteria, e.g.expressiveness, uniformity, administration scalability, system evolution. Figure 6.2summarizes this evaluation with respect to the key criteria that have beenaddressed in this thesis. The main drawback of the approach is that there is adegradation in performance, but we showed that this degradation can be minimizedat the expense of adaptability. Further research is also required to incorporateassurance-building activities in the presented approach.

120

Eva

luation

and

Rel

ate

dW

ork Figure 6.2: Evaluation of the Access Control Service


PDP PIP

Embedded PDP







Access Control Service(Access Interface - View Connector) 0 + + + + + +(a-o) +

(Section 6.1.1) (Section 6.1.3) (Section 6.1.2)

legend:+ well supported0 neutral– badly supportedx(. . . ) functionality is not provided (symbol


6.2 Applicability 121

6.2 Applicability

In this thesis, we realized the presented access interface and view connectorapproach as an aspect-based subsystem that manages the separation of concernsbetween security-specific components (such as the authorization engine) and theapplication logic.

Realizing this approach on state-of-the-art middleware technologies requiresthat the middleware provide support for retrieving application state and additionalcontext information. Consequently, applying the approach to standard J2EEor COM+ environments requires trade-offs. Supporting access interfaces thatonly need information provided by the middleware platforms is easy. But, ifthe application needs a more expressive access interface, implementing the viewconnector might require that you modify the application code before it can retrievethe necessary information.

In future work, we intend to use model-driven architecture (MDA) [Obja] togenerate the view connector automatically based on (1) the access interface, (2)the application class diagram, and (3) the view connector. Different generators canbe provided to support this generation for various target platforms. This model-driven security engineering offers a promising road to cope with the complexitythat arises from the heterogeneity of the systems deployed in an organization.

6.3 Positioning in a Broader Perspective

In Section 3.4, a number of state-of-the-art technologies have been discussed thatare closely related to our work. In this section, the presented results are placed ina broader perspective by discussing the research domains that are related to ourapproach.

6.3.1 Security Engineering

Policy Refinement. Policy refinement is the translation of a high-level abstractpolicy to a low-level (operational) policy. The main motivation for policyrefinement [MS93] is (1) to determine how a low-level policy should be createdor adapted if the high-level policy is defined or modified, and (2) to perform ananalysis to check whether the low-level policy conforms to the high-level policy. Anumber of approaches have been presented to translate organizational policies orhigh-level policies in general into an operational policy [BLMR04]. The definitionof an approach to refine a policy and analyze its correctness is beyond the scope ofthis thesis, but it is related in the sense that the abstraction layer that is definedby the access interface closes the gap between the organizational security policyand the specification level policy. The view connector improves the traceability ofthe translation of the latter in a low-level policy.


Model-Driven Security. Burt et al. propose in [BBR+03] a unified accesscontrol model as a Platform Independent Model (PIM). The goal in theirapproach is to generate Platform Specific Models (PSMs), e.g. for JAAS [Gon],RAD [BDB+99] and XACML/SAML [OASa, OASb], to integrate access controlsolutions in heterogeneous environments. Access control points and protectedresources serve as parameters for the PIM.SecureUML [BDL06] is a model-driven approach for security that aims at theintegration of security in the development process. SecureUML provides a platformindependent meta-model that is based on RBAC and that can be customizedto a design language, e.g. component class diagrams or process state charts,by identifying the protected resources and actions. Generators automaticallytranslate the policies formulated in these dialects to deployment descriptorelements and programmatic access control checks, e.g. for EJBs [LBD02] and JavaServlets [BDL03]. The crosscutting nature of the access control concern manifestsitself in the need to define a dialect to specify what constitutes a protected resourceand an action. The drawback is that a generator is needed for each dialect, becauseit cannot be expressed how the access control aspect interacts with the application.

Manageable Access Control. The motivation behind SecureUML is that theintegration of security with current approaches is too low-level and often needs tobe carried out post-hoc by a developer with a lack of experience in the area ofsecurity [LBD02]. In SecureUML actions can be bound to a group of applicationmethods (e.g. side-effect free methods) and they can be grouped in a hierarchy.The View Policy Language [Bro02] aims at a better separation of concerns so thataccess control is manageable. VPL aggregates access rights in a type-safe mannerinto views, which can be assigned to a role. In VPL these views are constructedbased on the application’s use-cases and assigned to roles that correspond to theactors of the use cases.In our approach, actions label a group of application events as security sensitiveand object interfaces abstract the application-specific resources.

6.3.2 Policy Languages and Frameworks

The design of the access control service exhibits the same decomposition aspresented by the ISO/IEC 10181-3 Access Control Framework [ISO] and theXACML dataflow model [OASa]. The authorization engine is essentially the PolicyDecision Point (PDP). The view connector implementation acts as both PolicyEnforcement Point (PEP) and Policy Information Point (PIP): It intercepts accessrequests that are labeled as security sensitive and retrieves the attributes for boththe access object and subject involved in the access request.

The presented approach benefits from research that has been carried out

6.3 Positioning in a Broader Perspective 123

regarding policy languages and authorization engines. The domain modelpresented by the access interface can be used to formulate policies in policylanguages, such as Ponder [Dam02] and XACML [OASa]. These languagesuse the abstractions subject-resource-action, and support the association ofattributes (or parameters) with these abstractions. The presented approachalso complements work being done concerning authorization engines, such as theFlexible Authorization Framework (FAF) [JSSS01].

The policy framework that is presented by Verlaenen et al. [VWJ07], proposesa generic policy model that can be used to create different types of policies, suchas for example an authorization policy. The framework allows to tune such apolicy to a particular application domain by mapping application-domain conceptsto concepts of the policy ontology. This mapping, for instance, results in thespecification of additional attributes for subject, action, resource and environment.The specification of an access interface for a particular application domain can beseen as an application of this methodology.

6.3.3 AOSD and the Security Concern

AOSD has proven useful in the modeling of the access control concern. Ray etal. [RRF04] start from the observation that security policies should be specifiedand maintained separately from the application. This is a prerequisite to clearlydocument requirements, and to analyze, change and centrally manage policies.They address the integration of a separately specified policy in an applicationdesign by using an aspect-oriented modeling approach that consists of an aspectmodel and a primary model (for the functional design). The composition of thesetwo models is called weaving. Song et al. [SRF+05] apply this aspect-orientedmodeling approach to compose the access control concern and the applicationin a verifiable manner. This approach thus focuses on the design phase of theapplication, and composes the RBAC model with the application.

Our approach can be seen as an application of the Multidimensional Separationof Concerns (MDSOC) idea tailored to the security concern. In [TOHS99], theproblems that software systems face regarding reusability, traceability and thehigh impact of changes is put down to the fact that existing modularizationmechanism typically only support one single dominant decomposition (in termsof the dominant concern). This is also referred to as the ‘tyranny of the dominantdecomposition’. To encapsulate the other concerns, the MDSOC approachintroduces hyper slices that only capture what is pertinent to the hyper slice’sconcern. A hyper module is then a set of hyper slices together with a set ofcomposition rules that determine how these hyper slices are to be composed. Adefault composition rule is to match the units with the same name. More complexrule can be specified, however.

The work presented in this thesis, builds on the research that is carried out byDe Win et al. [DJP05, De 04], which demonstrates that AOSD techniques can be


used to modularize the implementation of application-level access control. Theyused the aspect-oriented language aspectJ [aspa] to integrate access control logicin a Personal Information Management application and in jFTP. De Win [De 04]discusses the need for composition contracts as a prerequisite to reuse aspects. Acomposition contract specifies what is required and provided by an aspect so thata correct composition can be obtained.

6.3.4 Policy Enforcement Mechanisms

Inlined Reference Monitors use program rewriting to integrate a reference monitorin an application prior to execution. Erlingsson et al. list in [ES00] the followingthree requirements for this reference monitor. First the monitor must mediate allevents that are relevant for the policy. The monitor must moreover be protectedfrom being subverted, and its presence must be transparent for applications. ThePolicy Enforcement Toolkit (PoET) [ES00] implements inlined reference monitorsby inserting checking code in Java byte code at load time. PoET is more suitablefor the enforcement of code access policies.

Naccio [ET99] integrates policies by means of wrapper functions that performthe necessary checks and then call the original system function. The enforcedpolicies are defined in a platform independent way as these are specified in termsof abstract resource manipulations. The Naccio system is divided into a policygenerator and an application transformer. The policy generator generates a newversion of a platform library that includes checking code to enforce the policy.The application transformer then replaces all system calls with calls to this newversion of the platform library.

The Polymer system [BLW05] also uses program monitors to enforce a (codeaccess) security policy. These monitors can modify the application’s behavior atrun-time, either by halting the execution, inserting some other code, replacing thereturn value of an action, or throwing a security exception. Polymer moreoverprovides support for composing policies and defining abstract actions.

6.3.5 Context-Based Access Control

There exist a large number of approaches that extend established access controlmodels with the ability to take into account context information. A number ofexamples have been given in Section 3.1.3.

Strembeck and Neumann [SN04] present an approach to engineer and enforcecontext constraints in RBAC. These context constraints provide support for con-ditional permissions that are constrained by conditions on contextual attributes,such as the current GPS location, the proximity of another device, CPU loadand the status of applications and services. A scenario-based engineering processis presented to elicit these context constraints and to trace them back to thegoals and obstacles (as for example presented in [vL00]) they originate from.

6.3 Positioning in a Broader Perspective 125

Their implementation (called xoRBAC) allows to dynamically (un)register contextconstraints for permissions objects.

In [McD03] McDaniel presents the design of the Antigone Condition Framework(ACF). This general-purpose condition service allows to integrate complex anddistributed condition evaluation in the enforcement of an authorization policy.These conditions are used to model context in an authorization policy, and arecharacterized based on how they are retrieved, how they are evaluated, and howthey need to be secured. While the integration of these conditions in mostsystems is often ad hoc, the Antigone framework provides explicit support forthe specification, instantiation and evaluation of conditions.

Chapter 7

Conclusion

The growing computerization in our society requires applications to meet highsecurity standards. Examples of application domains where this trend is observedare government, finance and health care. This thesis describes the requirements inthe health care application domain, and motivates the need to enforce context-based access control policies as an adequate answer to these demands.

In our study of the health care domain we observe that periodical reviewis a key requirement in the implementation of an access control policy. At alltimes, appropriate measures must be in place to protect health care data andfunctionality. The appropriateness of the measures taken evolves, for example,under the impulse of the availability of new technologies, or the sanction of newlegislation. Our objective is to support evolvable access control such that accesscontrol enforcement can be configured and adapted to incorporate changes. Thesechanges may be necessitated by new requirements, or changes in the application,or the observation that the current access control enforcement does not meetexpectations.

A uniform enforcement of a given access policy in a number of applicationsis the third challenge that is addressed in this thesis. The fact that the burden isplaced on the developer to integrate a high-level (expressive) policy jeopardizes auniform enforcement of an access control policy. Also the lack of an abstractionlayer between the high-level organizational security policy and the low-level policyresults in a poor traceability and renders it hard to maintain consistency.

This chapter sums up the contributions of this thesis in Section 7.1, drawsconclusions in Section 7.2, and discusses possible extensions and research tracksfor future work in Section 7.3.

127

128 Conclusion

7.1 Contributions

Access Interface and View Connector Approach. An access interface isa domain model that reflects all the required information to formulate the accesscontrol policy, and provides a view on the application from the access controlperspective. This view can include application-domain-specific information, andthus supports the enforcement of a context-based policy. An access interfaceenables a uniform and centralized enforcement of one evolving organization-wideapplication-domain-specific policy in a number of applications that are deployedwithin the organization, as it abstracts from application specifics.

The access interface is bound to the application by means of a view connector.Per application one view connector is specified to map application-specific conceptsonto the abstractions introduced by the access interface. E.g., application objectsare mapped on an object interface, and application methods on actions.

Access Control Service. State-of-the-art access control technologies fail tosupport the enforcement of rich and granular policies, or to modularize the accesscontrol concern in a service that is clearly separated from the application logic.This is due to the crosscutting nature of the interaction between the access controlconcern and the application. Aspect-Oriented Software Development (AOSD)techniques claim to be capable of modularizing these crosscutting concerns. Wehave designed an access control service as a collaboration between an authorizationengine, access interface and view connector. This service is implemented bymeans of two prototypes using the aspect-oriented framework JAC and the aspect-oriented language CaesarJ.

Evaluation Criteria. The third contribution is an evaluation of our approachagainst a comprehensive set of criteria. This set can be seen as a checklistthat enables a security engineer to evaluate whether a particular access controltechnology satisfies the requirements. These criteria are categorized in five classes,namely (1) expressiveness, (2) policy management, (3) system evolution, (4)scalability and (5) assurance. In this thesis, we focus mainly on the first threeclasses.

7.2 Conclusion

The introduction of an access interface to describe the high-level access controlview on the application has several advantages. First, it naturally delineates theresponsibilities between the security officer and the application deployer. Theformer does not have to be aware of the internal details of the application towrite the policy. The latter specifies how the access interface is bound to theapplication by means of a view connector. A clear separation of concerns also

7.3 Future Work 129

results in a better support for evolution whenever the requirements of one of thesestakeholders change. Requirements traceability is improved, regardless of how theview connector is realized. Besides enabling uniform access control enforcementin multiple applications, the access interface also closes the gap in the translationof a high-level, organizational policy into a low-level, application-specific policy.Moreover, the access interface explicitly captures the information required by theaccess control policy from the application. In this sense, the latter can be seen asa contract that the application can be held to.

In this thesis, we demonstrate that aspect-oriented software developmenttechniques can be used to decouple the access control concern from the application.The support for collaborations offered by a number of AOSD approaches provesuseful for modularizing the access control concern. We show that it is feasibleto regard this view connector as a deployment descriptor from which the bindingcan be automatically generated for each application. There is still work to bedone to mitigate access denials that originate from the access control aspect andto provide a security model for aspects. To our knowledge, none of the existingAOSD approaches are designed with security in mind.

When going through the list of requirements, we conclude that the presentedapproach does not adversely affect most of the other requirements. There is adegradation in performance, but we show that this degradation can be minimizedat the expense of adaptability. It is an interesting track for future research toprovide a security engineer with the possibility to make these trade-offs based onspecific requirements.

7.3 Future Work

In this thesis, we mainly focus on the development of an access control service witha centralized access control (information) management in a closed environment.This setting is very common in practice. There are scenarios whereby not allthe principals that request access, are known in advance by the local authority.This is, for example, the case in service-oriented architectures whereby a part ofthe business logic can be accessed by (partially trusted) customers or suppliers.To support these scenarios, the subject interface can be extended to support, forexample, delegation and the conjunction of principals.

In its current definition, the view connector includes a limited administrativeaccess control model for the update of access control information. Attributes ofan access object can only be updated centrally (i.e. by the access control serviceitself). To support a more decentralized management, as is required by the DACmodel, we need to extend this basic administrative access control model.

The observation that the access interface can be extended to support obliga-tions, filters and application events, needs to be confirmed.

Although we show that the view connector can be generated automatically

130 Conclusion

based on their description, they are currently still custom-made by hand. Theuse of program generation techniques to automate this generation still needs tobe validated in more depth. The Model-Driven Architecture (MDA) approachalso seems to be a promising road to generate these view connectors for differentplatforms and aspect-oriented approaches.

In this thesis, we have implemented the access interface and view connectorapproach by means of research aspect-oriented prototypes. The implementationof the presented approach on top of an industrial component platform, such asJBoss [jbo] , enables its validation for large-scale applications. For this validation,we propose to broaden the scope to other application domains, such as the financialand governmental application domain.

Another track of future research is to investigate how to evolve towards amore integrated approach, in which policy rules are directly specified in termsof pointcuts. In the current access control service design, pointcuts are used tospecify the policy enforcement points.

The access control evaluation criteria can be used to design a benchmark toassess access control technologies.

Bibliography

[AGMO06] I. Aracic, V. Gasiunas, M. Mezini, and K. Ostermann. An Overviewof CaesarJ. Transactions on Aspect-Oriented Software Development,I:135–173, 2006.

[And96a] R.J. Anderson. Patient Confidentiality - At Risk from NHS WideNetworking. In B. Richards, editor, Health Care ’96: CurrentPerspectives in Healthcare Computing Conference, pages 687–692,March 1996.

[And96b] R.J. Anderson. Security in Clinical Information Systems, 1996.British Medical Association.

[And96c] R.J. Anderson. A security policy model for clinical informationsystems. In SP ’96: Proceedings of the 1996 IEEE Symposium onSecurity and Privacy, page 30, Washington, DC, USA, 1996. IEEEComputer Society.

[aspa] AspectJ homepage: http://www.aspectj.org.

[aspb] The AspectJ Programming Guide :http://www.eclipse.org/aspectj/doc/released/progguide/index.html.

[BBF01] E. Bertino, P.A. Bonatti, and E. Ferrari. TRBAC: A temporal role-based access control model. ACM Transactions on Information andSystem Security, 4(3):191–233, 2001.

[BBR+03] C.C. Burt, B.R. Bryant, R.R. Raje, A. Olson, and M. Auguston.Model Driven Security: Unification of Authorization Models forFine-Grain Access Control. In EDOC ’03: Proceedings ofthe 7th International Conference on Enterprise Distributed ObjectComputing, page 159, Washington, DC, USA, 2003. IEEE ComputerSociety.

[BCE+06] J. Ball, D. Carson, I. Evans, K. Haase, and E. Jendrock. The JavaTM

EE 5 Tutorial. Sun Microsystems, May 2006.

131

132 BIBLIOGRAPHY

[BCK03] L. Bass, P. Clements, and R. Kazman. Software Architecturein Practice, Second Edition. SEI Series in Software Engineering.ADDISON-WESLEY, 2003.

[BDB+99] K. Beznosov, Y. Deng, B. Blakley, C. Burt, and J. Barkley. AResource Access Decision Service for CORBA-based DistributedSystems. In ACSAC ’99: 15th Annual Computer SecurityApplications Conference, pages 310–319, 1999.

[BDL03] D. Basin, J. Doser, and T. Lodderstedt. Model Driven Security forProcess-Oriented Systems. In SACMAT ’03: Proceedings of the eighthACM Symposium on Access Control Models and Technologies, pages100–109, New York, NY, USA, 2003. ACM Press.

[BDL06] D. Basin, J. Doser, and T. Lodderstedt. Model Driven Security: fromUML Models to Access Control Infrastructures. ACM Transactionson Software Engineering and Methodology, 15(1):39–91, January2006.

[Bez00] K. Beznosov. Engineering Access Control for Distributed EnterpriseApplications. PhD thesis, Florida International University, July 2000.

[Bez02a] K. Beznosov. Access Control Mechanisms in Commercial Middleware,June 2002. tutorial at SACMAT’02.

[Bez02b] K. Beznosov. Object Security Attributes: Enabling Application-Specific Access Control in Middleware. In DOA’02: 4th InternationalSymposium on Distributed Objects & Applications, pages 693–710,London, UK, October 2002. Springer-Verlag.

[BGH+02] S. Bodoff, D. Green, K. Haase, E. Jendrock, M. Pawlan, andB. Stearns. The J2EE tutorial. Addison-Wesley Longman PublishingCo., Inc., Boston, MA, USA, 2002.

[BJH+04] P. Bowen, A. Johnson, J. Hash, C.D. Smith, and D.I. Steinberg. AnIntroductory Resource Guide for Implementing the Health InsurancePortability and Accountability Act (HIPAA) Security Rule - NISTSpecial Publication 800-66 - Draft, May 2004.

[BL73] D. Bell and L. LaPadula. Secure Computer Systems, Vol. I:Mathematical Foundations and Vol. II : Mathematical Model.Technical Report MTR-2547, MITRE Corp., Bedford, MA, 1973.

[BL75] D. Bell and L. LaPadula. Secure Computer System Unified Expositionand Multics Interpretation. Technical Report MTR-2997, MITRECorp., Bedford, MA, July 1975.

BIBLIOGRAPHY 133

[Bla99] B. Blakley. CORBA Security: Computing with Objects. series editors.ADDISON-WESLEY, 1999.

[BLMR04] A.K. Bandara, E.C. Lupu, J. Moffett, and A. Russo. A Goal-basedApproach to Policy Refinement. In Proceedings of the 5th IEEEWorkshop on Policies for Distributed Systems and Networks, 2004.

[BLW05] L. Bauer, J. Ligatti, and D. Walker. Composing Security Policies withPolymer. In PLDI ’05: Proceedings of the 2005 ACM SIGPLANconference on Programming language design and implementation,pages 305–314, New York, NY, USA, 2005. ACM Press.

[Bro01] G. Brose. Access Control Management in Distributed Object Systems.PhD thesis, Freie Universitat Berlin, October 2001.

[Bro02] G. Brose. Manageable Access Control for CORBA. Journal ofComputer Security, 10(4):301–337, 2002.

[BRR99] S.A. Buckovich, H.E. Rippen, and M.J. Rozen. Driving TowardGuiding Principles, A Goal for Privacy, Confidentiality, and Securityof Health Information. Journal of the American Medical Association,6(2):122–133, March-April 1999.

[Bur04] B. Burke. Aspect-Oriented Annotations. ONJava, September 2004.

[cae] CaesarJ Homepage: http://caesarj.org/.

[CLB06] J. Crampton, W. Leung, and K. Beznosov. The Secondary andApproximate Authorization Model and its Application to Bell-LaPadula Policies. In SACMAT ’06: Proceedings of the eleventhACM symposium on Access control models and technologies, pages111–120, New York, NY, USA, 2006. ACM Press.

[CLS+01] M.J. Covington, W. Long, S. Srinivasan, A.K. Dey, M. Ahamad, andG.D. Abowd. Securing context-aware applications using environmentroles. In SACMAT ’01: Proceedings of the sixth ACM symposium onAccess control models and technologies, pages 10–20, New York, NY,USA, 2001. ACM Press.

[Cou97] Counsel of Europe. Recommendation R(97)5, On the protection ofmedical data, February 1997.

[Cra01] D. Crawford. Special issue on AOP. Communications of the ACM,44(10), October 2001.

[Cra05] L. Cranor. Towards Usable Web Privacy and Security. Keynote atthe 14th International World Wide Web Conference, 2005.

134 BIBLIOGRAPHY

[Dam02] N. Damianou. A Policy Framework for Management of DistributedSystems. PhD thesis, Imperial College London, February 2002.

[Dam04] J. Van Damme. De kern van het elektronisch dossier van de huisarts(dutch), January 2004.

[DD04] T. Denoulet and M. Desmet. Beveiliging van medische informatiesys-temen. Master’s thesis, Katholieke Universiteit Leuven, 2003-2004.

[DDLS01] N. Damianou, N. Dulay, E. Lupu, and M. Sloman. The Ponder PolicySpecification Language. LNCS, 1995:18–28, 2001.

[De 04] B. De Win. Engineering Application-level Security through Aspect-Oriented Software Development. PhD thesis, Katholiek UniversiteitLeuven, March 2004.

[Dep83] Department of Defense. Trusted computer system evaluation criteria(orange book), 1983.

[Dij82] E.W. Dijkstra. On the role of scientific thought. LNCS, 1982.

[DJP05] B. De Win, W. Joosen, and F. Piessens. Developing SecureApplications through Aspect-Oriented Programming. In Robert E.Filman, Tzilla Elrad, Siobhan Clarke, and Mehmet Aksit, editors,Aspect-Oriented Software Development, pages 633–650. Addison-Wesley, Boston, 2005.

[DNdB04] J. Van Damme, H. Nys, and B. Van den Bosch. Het elektronischmedisch dossier: de communicatie van gegevens en de digitalehandtekening (dutch presentation), May 2004.

[DPJ06] B. De Win, F. Piessens, and W. Joosen. How secure is AOP andwhat can we do about it? In SESS ’06: Proceedings of the 2006International Workshop on Software Engineering for Secure Systems,pages 27–34, New York, NY, USA, 2006. ACM Press.

[DPJV02] B. De Win, F. Piessens, W. Joosen, and T. Verhanneman. On theimportance of the separation-of-concerns principle in secure softwareengineering. In C. Serban, editor, ACSA Workshop on the Applicationof Engineering Principles to System Security Design - Final Report,November 2002.

[DPJV06] L. Desmet, F. Piessens, W. Joosen, and P. Verbaeten. StaticVerification of Indirect Data Sharing in Loosely-coupled ComponentSystems. In Software Composition, volume 4089 of Lecture Notes inComputer Science, pages 34–49. Springer Berlin / Heidelberg, 2006.

BIBLIOGRAPHY 135

[DS00] P.T. Devanbu and S. Stubblebine. Software Engineering for Security:a Roadmap. In ICSE ’00: Proceedings of the Conference on TheFuture of Software Engineering, pages 227–239, New York, NY, USA,2000. ACM Press.

[EAC98] G. Edjlali, A. Acharya, and V. Chaudhary. History-based AccessControl for Mobile Code. In CCS ’98: Proceedings of the 5th ACMconference on Computer and communications security, pages 38–48,New York, NY, USA, 1998. ACM Press.

[EC95] European Parliament and Council of Europe. Directive 95/46/EC, onthe protection of individuals with regard to the processing of personaldata and on the free movement of such data, October 1995.

[Ern01] E. Ernst. Family Polymorphism. In ECOOP ’01: Proceedings of the15th European Conference on Object-Oriented Programming, pages303–326, London, UK, 2001. Springer-Verlag.

[ES00] U. Erlingsson and F.B. Schneider. IRM enforcement of java stackinspection. In IEEE Symposium on Security and Privacy, pages 246–255, 2000.

[ET99] D. Evans and A. Twyman. Flexible Policy-Directed Code Safety. InIEEE Symposium on Security and Privacy, pages 32–45, 1999.

[FF00] R.E. Filman and D.P. Friedman. Aspect-Oriented Programmingis Quantification and Obliviousness, October 2000. Workshop onAdvanced Separation of Concerns, OOPSLA 2000.

[FK92] D. Ferraiolo and R. Kuhn. Role-Based Access Controls. In 15th NIST-NCSC National Computer Security Conference, pages 554–563, 1992.

[FSG+01] D.F. Ferraiolo, R. Sandhu, S. Gavrila, D.R. Kuhn, and R. Chan-dramouli. Proposed NIST standard for role-based access control.ACM Transactions on Information and System Security, 4(3):224–274, 2001.

[GED03] L. Gong, G. Ellison, and M. Dageforde. Inside Java 2Platform Security, Second Edition, Architecture, API Design, andImplementation (The Java Series). Addison-Wesley, May 2003.

[Gee05] K. Geebelen. Flexibele toegangscontrole voor moderne toepassingen.Master’s thesis, Katholieke Universiteit Leuven, 2004-2005.

[GFW02] R. Goodwin, S.F. Foh, and F.Y. Wu. Instance-level access controlfor business-to-business electronic commerce. IBM Systems Journal,41(2), Januari 2002.

136 BIBLIOGRAPHY

[Gon] L. Gong. Java 2 Platform Security Architecture, version 1.2.

[Gro02a] Object Management Group. Security domain membership manage-ment specification - final adopted specification, May 2002.

[Gro02b] Object Management Group. Security Service specification, v1.8,March 2002.

[HH04] E. Hilsdale and J. Hugunin. Advice Weaving in AspectJ. In AOSD’04: Proceedings of the 3rd International Conference on Aspect-Oriented Software Development, pages 26–35, New York, NY, USA,2004. ACM Press.

[ISO] ISO. Information technology - open systems interconnection - securityframework for open systems: access control framework. ISO/IEC10181-3 (ITU-T X.812).

[Jaw00] J. Jaworski. Java Security Handbook. Sams White Book. Sams,September 2000.

[jbo] Jboss homepage: http://jboss.com.

[JSSS01] S. Jajodia, P. Samarati, M.L. Sapino, and V.S. Subrahmanian.Flexible Support for Multiple Access Control Policies. ACMTransactions on Database Systems, 26(2):214–260, 2001.

[Kal02] D. Kalra. Clinical Foundations and Information Architecture for theImplementation of a Federated Health Record Service. PhD thesis,University College London, May 2002.

[Kar03] G. Karjoth. Access Control with IBM Tivoli Access Manager.ACM Transactions on Information and System Security, 6(2):232–257, 2003.

[LABW92] B. Lampson, M. Abadi, M. Burrows, and E. Wobber. Authenticationin Distributed Systems: Theory and Practice. ACM Transactions onComputer Systems, 10(4):265–310, 1992.

[LBD02] T. Lodderstedt, D. A. Basin, and J. Doser. SecureUML: A UML-Based Modeling Language for Model-Driven Security. In UML, pages426–441, 2002.

[MBR03] S. Middleton, J. Barnett, and D. Reeves. What is an integrated carepathway? What is . . . ? series, 3(3), 2003. http://www.evidence-based-medicine.co.uk/What is series.html.

BIBLIOGRAPHY 137

[McD03] P. McDaniel. On Context in Authorization Policy. In SACMAT ’03:Proceedings of the eighth ACM Symposium on Access Control Modelsand Technologies, pages 80–89, New York, NY, USA, 2003. ACMPress.

[MO02] M. Mezini and K. Ostermann. Integrating Independent Componentswith On-Demand Remodularization. In OOPSLA ’02: Proceedings ofthe 17th ACM Conference on Object-Oriented Programming, Systems,Languages, and Applications, 2002.

[MO03] M. Mezini and K. Ostermann. Conquering aspects with Caesar.In AOSD ’03: Proceedings of the 2nd International Conference onAspect-Oriented Software Development, pages 90–99, New York, NY,USA, 2003. ACM Press.

[Mon03] R. Monzillo. JAVA Authorization Contract for Containers, Version1.0, 2003.

[MS93] J.D. Moffett and M.S. Sloman. Policy Hierarchies for DistributedSystem Management. IEEE Journal on Selected Areas inCommunications, Special Issue on Network Management, 11(9):1404–1414, December 1993.

[OASa] OASIS. Core Specification: eXtensible Access Control MarkupLanguage (XACML) Version 2.0.

[OASb] OASIS. Security Assertion Markup Language (SAML) Version 2.0.

[Obja] Object Management Group. OMG Model Driven Architecture.www.omg.org/mda/.

[Objb] Object Management Group. Resource Access Decision FacilitySpecification.www.omg.org/technology/documents/formal/omg security.htm#RAD.

[OG] The Open Group. Authorization (azn) API - Technical Standard.

[Opd] H. Opdebeeck. Routine Prenatal Care.

[Par72] D.L. Parnas. On the Criteria To Be Used in Decomposing Systemsinto Modules. Communications of the ACM, 15(12):1053–1058, 1972.

[Paw02] R. Pawlak. La Programmation Orientee Aspect Interactionnelle pourla Construction d’Applications a preoccupations Multiples. PhDthesis, CNAM Paris, December 2002.

138 BIBLIOGRAPHY

[PSDF01] R. Pawlak, L. Seinturier, L. Duchien, and G. Florin. JAC: A FlexibleFramework for AOP in Java. In Reflection’01, volume 2192 of LectureNotes in Computer Science, pages 1–24. Springer-Verlag, September2001.

[RRF04] I. Ray and G. Georg R. France, N. Li. An aspect-based approachto modeling access control concerns. Information and SoftwareTechnology, 46(9):575–587, July 2004.

[SCFY96] R.S. Sandhu, E.J. Coyne, H.L. Feinstein, and C.E. Youman. Role-Based Access Control Models. IEEE Computer, 29(2):38–47, 1996.

[Sec00] Secretary of the Department of Health and Human Services. ProposedSecurity Rule, December 2000.

[Sec02a] Secretary of the Department of Health and Human Services. FinalPrivacy Rule, August 2002.

[Sec02b] Secretary of the Department of Health and Human Services. FinalSecurity Rule, February 2002.

[Smi01] H.E. Smith. A Context-Based Access Control Model for HIPAAPrivacy and Security Compliance - v1.2e (SANS Security Essentials(GSEC)), July 2001.

[SN04] M. Strembeck and G. Neumann. An Integrated Approach to Engineerand Enforce Context Constraints in RBAC Environments. ACMTransactions on Information and System Security, 7(3):392–427,2004.

[Sno05] B. Snow. We need assurance! In ACSAC ’05: Proceedings of the21st Annual Computer Security Applications Conference, pages 3–10,Washington, DC, USA, 2005. IEEE Computer Society.

[SRF+05] E. Song, R. Reddy, R. France, I. Ray, G. Georg, and R. Alexander.Verifiable Composition of Access Control and Application Features.In SACMAT ’05: Proceedings of the tenth ACM Symposium on AccessControl Models and Technologies, pages 120–129, New York, NY,USA, 2005. ACM Press.

[SS75] J.H. Saltzer and M.D. Schroeder. The Protection of Information inComputer Systems. In Proceedings of IEEE, volume 63, pages 1278–1308, 1975.

[SS94] R.S. Sandhu and P. Samarati. Access Control: Principles andPractice. IEEE Communications Magazine, 32(9):40–48, 1994.

BIBLIOGRAPHY 139

[Ste91] D. Sterne. On The Buzzword “Security Policy”. In Proceedings ofthe 1991 IEEE Computer Society Symposium on Research In SecurityAnd Privacy, pages 219–230, May 1991.

[Szy02] C. Szyperski with D. Gruntz and S. Murer. Component Software -Beyond Object - Oriented Programming (Second Edition). Addison-Wesley and ACM Press, 2002.

[TAPH05] W. Tolone, G.-J. Ahn, T. Pai, and S.-P. Hong. Access Control inCollaborative Systems. ACM Computing Surveys, 37(1):29–41, 2005.

[tiv03] The IBM Tivoli Access Manager Base Administration Guide -Version 5.1, November 2003.http://publib.boulder.ibm.com/tividd/td/ITAME/SC32-1360-00/en US/HTML/am51 admin.htm.

[TOHS99] P. Tarr, H. Ossher, W. Harrison, and S. M. Sutton, Jr. N Degreesof Separation: Multi-Dimensional Separation of Concerns. In ICSE’99: Proceedings of the 21st International Conference on SoftwareEngineering, pages 107–119, Los Alamitos, CA, USA, 1999. IEEEComputer Society Press.

[UZL] U.Z. Leuven: Leuvense Internet Samenwerking Artsen (LISA).http://www.uzleuven.be/UZroot/content/Zorgverleners/login/lisa/(dutch).

[Van96] B. Van den Bosch. The design and the development of the hospitalinformation system of the U.Z. Leuven. PhD thesis, KatholiekeUniversiteit Leuven, 1996.

[VJP+03] T. Verhanneman, L. Jaco, F. Piessens, B. De Win, and W. Joosen.Adaptable Access Control Policies for Medical Information Systems.In Distributed Applications and Interoperable Systems, 4th IFIP WG6.1 International Conference, DAIS 2003, pages 133–140. Springer-Verlag, November 2003.

[vL00] A. van Lamsweerde and E. Letier. Handling Obstacles in Goal-Oriented Requirements Engineering. IEEE Transactions on SoftwareEngineering, 26(10):978–1005, 2000.

[VPW+05] T. Verhanneman, F. Piessens, B. De Win, E. Truyen, andW. Joosen. Implementing a Modular Access Control Service toSupport Application-Specific Policies in CaesarJ. In AOMD ’05:Proceedings of the 1st workshop on Aspect Oriented MiddlewareDevelopment, pages 1–6, New York, NY, USA, 2005. ACM Press.

140 BIBLIOGRAPHY

[VPW+06] T. Verhanneman, F. Piessens, B. De Win, E. Truyen, and W. Joosen.A Modular Access Control Service for Supporting Application-Specific Policies. IEEE Distributed Systems Online, 7(6), June 2006.

[VPWJ05a] T. Verhanneman, F. Piessens, B. De Win, and W. Joosen.Requirements Traceability to Support Evolution of Access Control. InSESS ’05: Proceedings of the 2005 workshop on Software Engineeringfor Secure Systems - building trustworthy applications, pages 1–7, NewYork, NY, USA, 2005. ACM Press.

[VPWJ05b] T. Verhanneman, F. Piessens, B. De Win, and W. Joosen. ViewConnectors for the integration of Domain Specific Access Control.In Report of the workshop on AOSD Technology for Application-levelSecurity, pages p 42–48, 2005.

[VWJ07] K. Verlaenen, B. De Win, and W. Joosen. Towards simplifiedspecification of policies in different domains. In 10th IFIP/IEEESymposium on Integrated Management (IM2007), Munich, Germany,May 2007.

[VWPJ05] T. Verhanneman, B. De Win, F. Piessens, and W. Joosen. UniformApplication-level Access Control Enforcement of OrganizationwidePolicies. In Twenty-First Annual Computer Security ApplicationsConference, pages 389–398. IEEE Computer Society, December 2005.

[WFSM02] M. Wilikens, S. Feriti, A. Sanna, and M. Masera. A Context-Related Authorization and Access Control Method Based on RBAC:A case study from the health care domain. In SACMAT ’02:Proceedings of the seventh ACM Symposium on Access Control Modelsand Technologies, pages 117–124, New York, NY, USA, 2002. ACMPress.

List of Publications

Articles in international, reviewed journals

• T. Verhanneman, F. Piessens, B. De Win, E. Truyen, and W. Joosen. AModular Access Control Service for Supporting Application-Specific Policies.IEEE Distributed Systems Online, 7(6), June 2006.

Contributions at international conferences

• B. De Win, F. Piessens, W. Joosen, and T. Verhanneman. On the impor-tance of the separation-of-concerns principle in secure software engineering.In C. Serban, editor, ACSA Workshop on the Application of EngineeringPrinciples to System Security Design - Final Report, November 2002.

• T. Verhanneman, L. Jaco, F. Piessens, B. De Win, and W. Joosen.Adaptable Access Control Policies for Medical Information Systems. InDistributed Applications and Interoperable Systems, 4th IFIP WG 6.1International Conference, DAIS 2003, pages 133-140. Springer-Verlag,November 2003.

• T. Verhanneman, F. Piessens, B. De Win, and W. Joosen. View Connectorsfor the integration of Domain Specific Access Control. In Report of theworkshop on AOSD Technology for Application-level Security, pages p 42-48, 2005.

• T. Verhanneman, F. Piessens, B. De Win, and W. Joosen. RequirementsTraceability to Support Evolution of Access Control. In SESS’05: Pro-ceedings of the 2005 workshop on Software Engineering for Secure Systems- building trustworthy applications, pages 1-7, New York, NY, USA, 2005.ACM Press.

• T. Verhanneman, F. Piessens, B. De Win, E. Truyen, and W. Joosen.Implementing a Modular Access Control Service to Support Application-Specific Policies in CaesarJ. In AOMD ’05: Proceedings of the 1st workshop

141

142 List of Publications

on Aspect Oriented Middleware Development, pages 1-6, New York, NY,USA, 2005. ACM Press.

• T. Verhanneman, B. De Win, F. Piessens, and W. Joosen. UniformApplication-level Access Control Enforcement of Organizationwide Policies.In Twenty-First Annual Computer Security Applications Conference, pages389-398. IEEE Computer Society, December 2005.

Technical Reports

• L. Desmet, L. Jaco, K. Mertens, and T. Verhanneman. COTS, the safetynightmare of component-oriented frameworks, CW367, September 2003

• T. Verhanneman, L. Jaco, B. De Win, F. Piessens, and W. Joosen. Adapt-able Access Control Policies for Medical Information Systems: requirementsanalysis and case studies, CW363, August 2003

• B. De Win, B. Jacobs, W. Joosen, G. Neven, F. Piessens, and T.Verhanneman. Formal technologies for information and software security:An annotated bibliography, CW423, September 2005

Biography

Tine Verhanneman was born on June 8, 1979 in Leuven, Belgium. She receiveda Bachelor’s degree of Science in Engineering (Kandidaat Burgerlijk Ingenieur)and a Master’s degree of Science in Engineering in Computer Science (BurgerlijkIngenieur in de Computerwetenschappen) from the Katholieke Universiteit Leuvenin Belgium. She graduated magna cum laude in July 2002 with the thesis“The design and implementation of a flexible PKI client”, supervised by FrankPiessens. She started working as a Ph.D student at the DistriNet research groupof the Department of Computer Science at K.U.Leuven in September 2002. FromJanuary 2003, she was funded by the Institute for the Promotion of Innovationthrough Science and Technology in Flanders (IWT-Vlaanderen).

143

144 Biography

Uniforme en Modulaire Contextgebaseerde

Toegangscontrole voor Software Toepassingen

Samenvatting

De tendens van een almaar prominentere computerisatie van onze samenleving ma-nifesteert zich, bijvoorbeeld, in de ontwikkeling van toepassingen voor de overheiden gezondheidszorg. We dienen echter voor ogen te houden dat deze computeri-satie niet alleen aanleiding geeft tot een grotere automatisatie en efficientie, maarook het risico op misbruik op grote schaal verhoogt. Het is daarom cruciaal datdeze toepassingen beveiligd worden door alleen correct gebruik toe te staan. Ditcorrect gebruik wordt gespecificeerd in een beleid dat vastlegt wanneer een toegangtot een object (zoals data of functionaliteit) moet worden ingewilligd of geweigerd.Dit beleid wordt afgedwongen door middel van toegangscontrole. De gevoeligheidvan de data die wordt verwerkt, is doorgaans zo hoog dat toegang tot deze data ge-limiteerd moet worden tot het strikte minimum. Het afdwingen van een expressieftoegangscontrolebeleid wordt des te crucialer naarmate de organisatie de interneinfrastructuur ter beschikking stelt aan buitenstaanders, zoals bijvoorbeeld klan-ten en leveranciers. Om een dergelijk expressief beleid te kunnen afdwingen, dientde gebruikte toegangscontroletechnologie ondersteuning te bieden voor contextge-baseerde toegangscontrole, waarbij een toegangscontrolebeslissing wordt genomenop basis van informatie omtrent de context van de toegangsaanvraag. Voorbeeldenvan contextinformatie zijn de toestand waar de toepassing zich in bevindt, en deomstandigheden waarin een toegang wordt aangevraagd.

De complexiteit en de grootschaligheid van huidige software systemen maakthet moeilijk een toegangscontrolebeleid op uniforme wijze af te dwingen in detoepassingen die draaien binnen de organisatie. Bovendien wordt deze uniformi-teit ondermijnd door een voortdurende evolutie van het toegangscontrolebeleiden de toegangscontrolelogica. Toegangscontroletechnologieen dienen ondersteu-ning te bieden voor een aanpasbare toegangscontrole om tegemoet te komen aande veranderlijke vereisten. Een evaluatie van state-of-the-art technologieen toontaan dat deze technologieen er niet in slagen om een contextgebaseerd beleid opeen uniforme en aanpasbare manier af te dwingen. Aan de basis hiervan ligt hetonvermogen om het afdwingen van een contextgebaseerd beleid te modulariseren.

De oplossing die wij voorstellen, kan worden beschreven in termen van volgendetwee contributies, namelijk (1) de definities van de concepten access interface enview connector, en (2) de ontwikkeling van een toegangscontroledienst.

i

Een access interface ondersteunt het afdwingen van een contextgebaseerd toe-gangscontrolebeleid op een uniforme en gecentraliseerde manier in een aantal toe-passingen. Deze access interface is een voorstelling van een domeinmodel in termenvan de voor toegangscontrole gebruikelijke abstracties object - principaal - actieen omvat enkel de informatie die nodig is om het toegangscontrolebeleid te formu-leren. Voor elke toepassing wordt dan een view connector gespecificeerd, die deaccess interface bindt aan de toepassing.

Op basis van deze concepten, hebben we een toegangscontroledienst ontwikkelddie een contextgebaseerd toegangsbeleid afdwingt met behulp van aspectorientatie.Onze bevinding is dat de ondersteuning die aspectgeorienteerd software ontwikke-ling (Aspect-Oriented Software Development (AOSD)) biedt om een doorsnijdendaspect te modulariseren, nuttig en nodig is voor het modulariseren van het toe-gangscontroleaspect. Deze bevinding wordt ondersteund door twee prototypes, dierespectievelijk gebaseerd zijn op het AOSD-raamwerk JAC (Java Aspects Compo-nents) en de aspecttaal CaesarJ.

Ten derde, werd ook een lijst opgesteld met evaluatiecriteria voor toegangscon-troletechnologieen en werd onze aanpak geevalueerd aan de hand van deze criteria.

ii

1 Inleiding

1.1 Uitdagingen voor de implementatie van toegangscon-trole in hedendaagse, gedistribueerde toepassingen

Dankzij de computerisatie in een aantal toepassingsdomeinen, kan vandaag de dageen grotere automatisatie worden bekomen. Deze computerisatie houdt echter ookhet risico in dat er misbruik wordt gepleegd op grotere schaal. Het is daarombelangrijk om het correct gebruik van een toepassing vast te leggen in een beleiden dit beleid vervolgens af te dwingen. Een veelgebruikte techniek hiervoor istoegangscontrole. Hierbij wordt geverifieerd of elke toegangsaanvraag strookt methet geldende toegangscontrolebeleid. Dit beleid legt vast onder welke voorwaardendeze aanvraag wordt ingewilligd of geweigerd, en is specifiek voor een bepaaldeorganisatie of toepassingsdomein.

Een aantal toepassingsdomeinen, zoals bijvoorbeeld gezondheidszorg, hebbenhoge beveiligingsvereisten, aangezien ze met zeer gevoelige data omgaan. Het im-plementeren van deze beveiliging is echter niet triviaal. Vooreerst dient men bijhet afdwingen van het toegangscontrolebeleid rekening te houden met contextin-formatie, zoals de toestand van de toepassing of andere omstandigheden. Het isimmers niet voldoende om enkel de perimeter te beveiligen. De infrastructuurvan een bedrijf wordt immers steeds vaker (gedeeltelijk) ter beschikking gesteldaan derden, zoals bijvoorbeeld klanten en leveranciers. Bovendien moeten ookrestricties worden opgelegd op de toegang door ingewijden, zoals bijvoorbeeld per-soneelsleden.

Naast het afdwingen van een expressief en contextgebaseerd beleid, zijn ernog een aantal andere uitdagingen die moeten worden aangegaan. Een organisatiedient immers een groot aantal toepassingen te beheren die bovendien op heterogenesystemen geınstalleerd kunnen zijn. Het is een uitdaging om de toegangscontrolebinnen deze toepassingen consistent te houden, te meer daar het beleid en detoegangscontrolemechanismen zelf constant evolueren.

In deze thesis focussen we in het bijzonder op toegangscontrole op niveau vande toepassing. Het implementeren van toegangscontrole op dit niveau stelt ons instaat om bronnen binnen de toepassing zelf te beveiligen, en is daarom comple-mentair aan beveiliging op netwerk-, besturingssysteem- en databank niveau.

Er zijn een aantal toegangscontroletechnologieen beschikbaar die ondersteu-ning bieden voor toegangscontrole op toepassingsniveau. We tonen aan in dezethesis dat deze technieken te kort schieten, ofwel omdat ze geen ondersteuningbieden voor het afdwingen van een expressief beleid, ofwel omdat de toegangscon-trolelogica moet worden verstrengeld met de toepassingslogica. Dit laatste maakthet zeer moeilijk om de toegangscontrole aan te passen aan veranderende vereisten.De uitdaging voor deze thesis ligt derhalve in de modularisatie van het afdwingenvan een expressief toegangscontrolebeleid.

iii

De uitdagingen voor deze thesis. De uitdagingen die worden aangegaan indeze thesis, kunnen worden samengevat als volgt:

1. Het afdwingen van een contextgebaseerd toegangscontrolebeleid om tegemoette komen aan de hoge vereisten van huidige software toepassingen.

2. Het ondersteunen van evolutie van zowel het toegangscontrolebeleid als hetafdwingen van dit beleid, zodanig dat veranderingen in het beleid, de om-geving en de toepassing zelf kunnen worden opgevangen op een adequatemanier.

3. Het ondersteunen van het uniform afdwingen van een toegangscontrolebeleidin de verschillende toepassingen die draaien binnen een organisatie.

1.2 Onze aanpak: scheiding van belangen voor toegangs-controle

Scheiding van belangen voor toegangscontrole. Het uitgangspunt van de-ze thesis is dat het principe van de scheiding van belangen, zoals het werd geın-troduceerd door Dijkstra [Dij82], cruciaal is voor het bouwen van veilige syste-men [DPJV02]. Dit principe van scheiding van belangen is de basis van proce-dureel programmeren en objectorientatie. De stelling van Parnas [Par72] steltnamelijk dat software decompositie dient te worden gedreven door het afschermenvan informatie zodanig dat de complexe en veranderlijke ontwerpbeslissingen wor-den geencapsuleerd in modules. In deze thesis zal het principe van scheiding vanbelangen worden gebruikt in twee betekenissen. We duiden hiermee de afbakeningaan van de verantwoordelijkheden van de betrokkenen (of belanghebbenden), maarook de implementatie van het belang van elke betrokkene in goedgedefinieerde enafgescheiden modules.

Het modulariseren van toegangscontrole op toepassingsniveau is echter bijzon-der moeilijk door het doorsnijdend karakter van de interactie tussen de toepassings-en de toegangscontrolelogica. De implementatie van toegangscontrole wordt danook vaak verspreid over en verstrengeld met de toepassing. Het gevolg is dat hetbijzonder moeilijk wordt om aanpassingen consistent door te voeren.

Een veelbelovende aanpak: aspectgeorienteerd software ontwikkeling.

Het scheiden van de toegangscontrolelogica van de toepassing zodanig dat hetbeleid extern kan worden gespecificeerd, is geen nieuw idee. De meeste state-of-the-art toegangscontroletechnologieen encapsuleren de beslissingslogica in eenautorisatiemodule, of worden gerealiseerd als een toegangscontroledienst voor eenbepaald componentplatform. Ofwel bereiken deze aanpakken nog niet het gewensteniveau van scheiding van belangen, ofwel bieden ze geen ondersteuning voor hetafdwingen van een contextgebaseerd beleid. Aspectorientatie is een veelbelovende

iv

techniek die betere ondersteuning biedt voor de modularisatie van doorsnijdendebelangen.

Contributies. Vooreerst stellen we een aanpak voor die een toegangscontrole-gezichtspunt op de toepassing introduceert. Dit gezichtspunt is een abstractielaagdie ondersteuning biedt voor het afdwingen van een contextgebaseerd beleid entegelijk abstractie maakt van de interne werking van de toepassing. Dit stelt onsin staat om een gegeven organisatieoverkoepelend beleid op een uniforme wijze afte dwingen in de toepassingen die geınstalleerd zijn binnen de organisatie. Dezeaanpak ondersteunt een duidelijke afbakening van verantwoordelijkheden tussende beveiligingsverantwoordelijke - die het beleid formuleert - en de toepassingsop-steller (deployer) - die de toegangscontrolelogica configureert voor de toepassing.Deze scheiding van belangen ondersteunt de evolutie van het toegangscontrolebe-leid en toegangscontrolelogica.

Contextgebaseerde toegangscontrole is een doorsnijdend belang, omwille vande sterke koppeling met de toepassingslogica. Als de tweede contributie van dezethesis, zullen we aantonen dat aspectorientatie kan worden aangewend om dezetoegangscontrole op een modulaire wijze te implementeren. Dit wordt aangetoondaan de hand van een ontwerp van een modulaire toegangscontroledienst. Vandeze dienst werden twee prototypes gemaakt, die respectievelijk geımplementeerdzijn met het aspectgeorienteerde raamwerk Java Aspect Components (JAC) en deaspectgeorienteerde taal CaesarJ.

Ten derde, werd een uitgebreide lijst van criteria opgesteld om toegangscon-troletechnologieen te evalueren. We hebben deze criteria ook toegepast op devoorgestelde aanpak.

2 Contextgebaseerde toegangscontrole voor me-

dische toepassingen

In de vorige sectie, hebben we de uitdagingen opgesomd voor de implementatievan toegangscontrole in huidige, gedistribueerde toepassingen. In deze sectie gaanwe na wat de beveiligingsvereisten zijn in de context van het medische toepassings-domein en argumenteren dat er nood is aan contextgebaseerde toegangscontrole.

2.1 Beveiliging voor medische toepassingen

2.1.1 Wetgeving

De wetgeving formuleert een aantal bepalingen met betrekking tot het verwer-ken, verzamelen, opslaan van medische data en het autoriseren van toegang totdeze data. Daarnaast wordt ook vastgelegd aan welke standaarden deze bevei-liging dient te voldoen. Zo bepaalt de Europese richtlijn 95/46/EG [EC95] met

v

betrekking tot de bescherming van persoonsgegevens dat passende technische enorganisatorische maatregelen dienen te worden getroffen voor de bescherming vanpersoonsgegevens. De recommandatie R(97)5 [Cou97] van de Europese Raad ad-viseert bovendien dat deze maatregelen periodiek moeten worden herzien.

In de USA is er een specifieke wetgeving voor de bescherming van individu-eel identificeerbare medische data. Deze wetgeving is een onderdeel van HIPAA(Health Insurance Portability and Accountability Act (1996)). De twee regels dierelevant zijn voor beveiliging zijn de privacy regel [Sec02a] (Privacy Rule) en debeveiligingsregel [Sec02b] (Security Rule). De eerste regel bepaalt het beleid datvan toepassing is op persoonlijke informatie. De beveiligingsregel specificeert welkeimplementatie nodig is voor het afdwingen van dit beleid en bepaalt dat passendemaatregelen moeten worden getroffen gegeven het risico.

2.1.2 Beveiligingsprincipes en uitdagingen voor medische systemen

De wetgeving specificeert dat passende technische en organisatorische maatrege-len dienen te worden geımplementeerd om ongeautoriseerde toegang tot data teverhinderen. Beveiligingsexperts, onderzoekers en federale agentschappen heb-ben beveiligingsprincipes geformuleerd als een leiddraad voor een organisatie omdeze maatregelen te implementeren. In de thesis hebben we een compilatie ge-maakt van deze principes, waarbij we deze principes hebben onderverdeeld in driecategorieen, met name organisatorische maatregelen, technische maatregelen enautorisatie. Van elke categorie geven we hier een aantal voorbeelden.

Een belangrijke organisatorische maatregel die door een organisatie dient teworden genomen, is ondermeer de specificatie van een beleid en procedures die be-palen hoe schendingen van het beleid wordt vermeden, gedetecteerd, ingeperkt engecorrigeerd, en hoe autorisatie op een consistente manier wordt bepaald. Anderevoorbeelden van organisatorische maatregelen zijn het aanstellen van een verant-woordelijke die instaat voor de implementatie, en het periodiek herzien van hetorganisatorisch beleid en procedures.

Medische zorgprocedures kunnen erg complex zijn. Het team van zorgverle-ners van een patient kan groot zijn. De data kan worden gedecentraliseerd enopgevraagd worden van buiten de instelling. Deze complexiteit vereist dat deorganisatorische maatregelen ondersteund worden door technische maatregelen.Deze technische maatregelen dwingen ondermeer af dat geen ongeautoriseerde toe-gang kan plaatsvinden, de integriteit van de data gevrijwaard wordt en een auditspoor wordt opgetekend waarbij relevante informatie omtrent een toegangsaan-vraag wordt bewaard.

Het toekennen van autorisatie is een balansoefening tussen de beschikbaarheiden de bescherming van data. Veelal wordt autorisatie toegekend op basis vande noodzaak om de informatie te weten voor de taak die men uitvoert. Ander-son [And96] argumenteert dat de toestemming van de patient primeert. Toegangkan verleend worden aan verschillende personen en omwille van verschillende re-

vi

denen. Zo kan de patient zijn eigen data opvragen bij het uitoefenen van zijninzagerecht. In het kader van onderzoek, kan toegang gegeven worden tot medi-sche data op voorwaarde dat deze data geanonimiseerd is.

2.2 Contextgebaseerde toegangscontrole

Een typische toegangsaanvraag omvat het (doel)object, een actie en een princi-paal. Deze laatste is de oorsprong van de toegangsaanvraag en vertegenwoordigtbijvoorbeeld een gebruiker, een groep of een rol. Om een expressief beleid af tedwingen hebben we daarenboven nood aan bijkomende informatie alvorens eentoegangscontrolebeslissing te kunnen treffen. Deze informatie heeft bijvoorbeeldbetrekking op de context van de toegangsaanvraag, zoals het tijdstip, de locatievanwaar de aanvraag werd gedaan, of het zich voordoen van een noodsituatie. Eenander voorbeeld van relevante toegangscontrole-informatie is het bestaan van eenzekere relatie tussen de gebruiker en de data die wordt opgevraagd. We zouden opdeze manier kunnen afdwingen dat een arts alleen informatie kan opvragen van depatienten die bij hem of haar in behandeling zijn. Ook domeinspecifieke attribu-ten van object en principaal kunnen relevant zijn voor het toegangscontrolebeleid,zoals bijvoorbeeld de gevoeligheid van medische data.

Een medische organisatie dient een beleid te specificeren om medische dataadequaat te beschermen. In deze sectie hebben we gemotiveerd dat ondersteuningnodig is voor het afdwingen van een contextgebaseerd toegangscontrolebeleid.

3 Evaluatie van state-of-the-art toegangscontro-letechnologieen

Het objectief van deze thesis is de integratie van een contextgebaseerd toegangs-controlebeleid in toepassingen. De bescherming van bronnen binnen de toepassingvereist dat toegangscontrole wordt afgedwongen op het niveau van de toepassing.We focussen hierbij op de integratie van toegangscontrole in objectgeorienteerdesystemen. Voorbeelden van dergelijke bronnen zijn: object instanties en de uitvoe-ring van een functie of methode. De waaier van technologieen die ondersteuningbieden voor toegangscontrole op toepassingsniveau omvat ondermeer toegangscon-trolediensten in middleware platformen, toegangscontrolebibliotheken of raamwer-ken die kunnen worden geıntegreerd in de toepassing. Het hard coderen van toe-gangscontrolelogica in de toepassing is een ander alternatief om toegangscontroleop toepassingsniveau te implementeren.

We presenteren een set van criteria die kunnen gebruikt worden om toegangs-controle technologieen te evalueren. We focussen hier in het bijzonder op driecriteria die belangrijk zijn voor de implementatie van toegangscontrole in toe-passingen met hoge beveiligingsvereisten, zoals het medische toepassingsdomein.

vii

Deze vereisten omvatten ondermeer de ondersteuning voor het afdwingen van een(1) contextgebaseerd toegangscontrolebeleid. Ondersteuning voor de (2) evolutievan het toegangscontrolebeleid en de integratie van dit beleid, is nodig om tege-moet te komen aan de steeds veranderende vereisten. Dit evoluerende beleid dientdaarenboven (3) uniform te worden afgedwongen in de toepassingen binnen eenorganisatie. We hebben geopteerd voor deze drie vereisten omdat ze slecht wordenondersteund door state-of-the-art technologieen. Deze stelling wordt ondersteunddoor een evaluatie van de mate waarin state-of-the-art technologieen erin slagenom een contextgebaseerd beleid af te dwingen en daarbij ondersteuning biedenvoor de evolutie en het uniform afdwingen van toegangscontrole.

Zoals wordt besproken in de volgende sectie, hebben we deze technologieen ge-classificeerd volgens de decompositie van de toegangscontrolelogica. In Sectie 3.2bespreken we de evaluatiecriteria. Een overzicht van de evaluatie volgt in Sec-tie 3.3.

3.1 Toegangscontrolefuncties en decomposities

Voor de evaluatie van de toegangscontroletechnologieen hebben we deze technolo-gieen onderverdeeld op basis van de decompositie van de toegangscontrolelogica.Deze decompositiestrategie bepaalt hoe de toegangscontrolefunctionaliteit wordtgeımplementeerd door de verschillende modules.

3.1.1 Toegangscontrolefuncties

In deze samenvatting beperken we ons tot de bespreking van de kernfuncties dieinstaan voor het afdwingen van het beleid. We baseren onze discussie op de func-ties zoals ze beschreven staan in de XACML (eXtensible Access Control MarkupLanguage) specificatie [OAS].

1. Het toegangscontroleafdwingpunt (PEP - Policy Enforcement Point), ookreferentiemonitor genoemd, vormt deel van het toegangspad van het sub-ject, die de toegangsaanvraag doet, naar het doelobject. Deze monitor on-derschept elke toegangsaanvraag en consulteert het beslissingspunt om na tegaan of de toegangsaanvraag conform is met het beleid. Vervolgens voertdeze monitor de toegangscontrolebeslissing uit door bijvoorbeeld de toegangte weigeren of toe te staan. De functie van deze monitor is dus tweeledig enbestaat uit toegangscontrolemediatie en het afdwingen van de beslissing.

2. Het beslissingspunt (PDP - Policy Decision Point) beslist of een bepaaldetoegangsaanvraag wordt toegestaan door het beleid.

3. Het informatiepunt (PIP - Policy Information Point) levert op vraag vanhet beslissingspunt informatie omtrent de context van de toegangsaanvraag.

viii

3.1.2 Toegangscontrole software decompositie

De software decompositiestrategie bepaalt nu hoe deze functies worden gereali-seerd door de verschillende modules. Deze decompositie bepaalt ook hoe de toe-gangscontrolelogica wordt gebonden aan de toepassing, aangezien deze decompo-sitie vastlegt hoe de PEP en PIP worden geımplementeerd. Hieronder worden debelangrijkste software decompositiestrategieen toegepast op toegangscontrole ominzicht te krijgen in de wijze waarop een technologie kan worden uitgebreid enworden aangepast voor een specifieke toepassing.

1. Hard gecodeerde toegangscontrole - We maken hierin onderscheid tus-sen het hard coderen van de PDP enerzijds, en het enkel hard coderen vande PEP, anderzijds. In het eerste geval kan geen onderscheid meer wordengemaakt tussen de toepassings- en de toegangscontrolelogica. In het tweedegeval, worden enkel de mediatiepunten geıntegreerd in de toepassing waar dePDP wordt opgeroepen. Deze PDP is extern aan de toepassing en doorgaansgeımplementeerd als een toegangscontroleraamwerk.

2. Toegangscontroleraamwerken - Een raamwerk legt een aantal gemeen-schappelijke concepten vast en laat daarnaast nog een aantal extensiepuntenopen die uitbreidingen en aanpassingen van het raamwerk toelaten. Dit kanbijvoorbeeld door overerving (zoals bijvoorbeeld in JAAS) of door composi-tie.

3. Toegangscontroledienst voor een componentplatform - Een compo-nentplatform implementeert diensten die het componentmodel implemen-teren. Diensten die niet-functionele vereisten implementeren en waarvancomponenten niet expliciet afhankelijk zijn (zoals beveiliging), worden vaakhard gecodeerd in het componentraamwerk. De interceptietechniek wordtvaak toegepast om de PEP te implementeren en de dienst transparant voorde toepassing op te roepen.

3.2 Criteria

In deze sectie bespreken we een aantal criteria op basis waarvan we de state-of-the-art technologieen evalueren, met name expressiviteit, evolutie en uniformiteit.In de volgende sectie, zal worden aangetoond dat bestaande technologieen er nietin slagen de combinatie van deze drie criteria goed te ondersteunen. In Sectie 6geven we een meer compleet overzicht van criteria voor de evaluatie van toegangs-controletechnologieen.

1. Expressiviteit is de mate waarin een toegangscontroletechnologie erin slaagtom een contextgebaseerd beleid af te dwingen. Dit criterium kan worden uit-gesplitst in de volgende criteria:

ix

· Mediatiegranulariteit bepaalt de fijnkorreligheid waarmee de mediatie-punten kunnen worden geselecteerd. In [Bez00] wordt de volgende clas-sificatie voorgesteld: toepassing - interface methode - andere bronnen.

· De rijkdom van een technologie kan worden omschreven als de varieteitvan contextinformatie die in rekening kan worden gebracht bij de eva-luatie van een toegangsaanvraag. Deze rijkdom is bepaald door deinterface van het beslissingspunt (PDP) en ook door de kracht van hetinformatiepunt (PIP).

2. Het evolutiecriterium meet de ondersteuning die een technologie aanbiedtom de toegangscontrole te adapteren als respons op veranderingen van hetbeleid en het systeem:

· Het beheer van het beleid omvat ondermeer het toevoegen of verwijderenvan gebruikers, rollen, groepen, objecten en beleidsregels.

· Tal van veranderingen kunnen een evolutie van het systeem vereisen,zoals veranderingen in het beleid, in de toepassing of het toegangscon-trolemechanisme. Een uitbreidbaar informatiepunt (PIP), een gemodu-lariseerd beslissingspunt (PDP) en een transparant afdwingpunt (PEP)dragen bij aan de evolueerbaarheid van het toegangscontrolesysteem.

3. Het criterium uniformiteit meet in welke mate een technologie ondersteu-ning biedt voor het uniform afdwingen van een gegeven (organisatieoverkoe-pelend) beleid in verschillende toepassingen.

· Uniformiteit vereist vooreerst dat de technologie abstractie maakt vantoepassingsspecifieke details, zodanig dat de beveiligingsverantwoorde-lijke geen uitgebreide kennis dient te hebben van de interne details vanelke toepassing.

· Het uniform afdwingen van een beleid wordt vereenvoudigd door eengecentraliseerd beheer van het beleid.

3.3 Conclusie

Op basis van de bovenvermelde evaluatiecriteria, hebben we state-of-the-art toe-gangscontroletechnologieen geevalueerd. De volgende technologieen worden be-sproken in de thesis: de Java authenticatie- en autorisatiedienst (JAAS), de toe-gangscontroledienst in J2EE en .NET, de CORBA beveiligingsdienst (CORBAsec)en extensies, en tot slot, de Tivoli autorisatiemanager (TAM). Het overzicht vandeze evaluatie wordt weergegeven in Figuur 1.

x

Figuur 1: Evaluatie van State-of-the-Art Technologieen


PDP PIP

Embedded PDP







Access Control Service

(Access Interface - View Connector) 0 + + + + + +(a-o) +(Section 6.1.1) (Section 6.1.3) (Section 6.1.2)

legend:

+ well supported0 neutral– badly supportedx(. . . ) functionality is not provided (symbol


xi

4 Het uniform afdwingen van een evoluerend toe-passingsdomeinspecifiek beleid

Centraal in onze aanpak staan de concepten access interface en view connector.Hieronder bespreken we hoe deze concepten een topdown integratie van een toe-gangscontrolebeleid ondersteunen (Figuur 2). Een access interface kan men be-schouwen als een gezichtspunt op de toepassing die enkel toegangscontrolespeci-fieke informatie bevat. Het is als het ware een domeinmodel dat alle termen de-clareert die nodig zijn om het toegangscontrolebeleid te specificeren. Deze accessinterface is typisch stabiel voor een bepaalde organisatie, en kan ook toepassingsdo-meinspecifieke concepten introduceren. Een dergelijke access interface zou in eenfinanciele context het concept van een risicovolle transactie kunnen introduceren.In een medische context, is de notie van een toegang in een medische noodsituatiezinvol.

Deze access interface dient gebonden te worden aan de toepassingen die draaienbinnen de organisatie. Dit kan door een toepassingsspecifieke view connector tespecificeren voor elk van deze toepassingen. Deze view connector kan beschouwdworden als een configuratie die toepassingsspecifieke concepten (zoals methodesgedefinieerd binnen de toepassing) associeert met concepten in de access interface.

Scheiding van Belangen. Figuur 2 geeft ook aan hoe de introductie van dezetwee concepten de scheiding van de verantwoordelijkheden van de verschillendebelanghebbenden (bij de integratie van toegangscontrole in een toepassing) onder-steunt.

· De beveiligingsverantwoordelijke onderhoudt de access interface en beheertde toegangscontrolebeleidsregels op gecentraliseerde wijze zonder dat hij ofzij daarbij de interne werking van de toepassingen in detail dient te kennen.

Access Control Policy

Access Interface

security officer

Bindingapplication deployer

application developer



Figuur 2: Topdown integratie van een toegangscontrolebeleid

xii

· De toepasssingsopsteller (deployer) configureert de toegangscontrole die wordtafgedwongen in elk van de toepassingen, zodanig dat deze conform is aan hetorganisatieoverkoepelend beleid.

· De toepassingsontwikkelaar levert de toepassingslogica.

Gecentraliseerde autorisatiemodule. Figuur 3 geeft een overzicht van onzeaanpak in een opstelling met een organisatieoverkoepelende, centrale autorisatie-module. Elke poging om een gevoelige operatie uit te voeren, wordt onderschepten voorgelegd aan deze module. Deze autorisatiemodule evalueert deze toegangs-aanvraag en kan zich daarbij baseren op toestandsinformatie van de toepassing, enmeer specifiek op de informatie vervat in de access interface. De toegangscontro-leregels worden geformuleerd op basis van deze access interface, en zijn derhalveonafhankelijk van een bepaalde toepassing.

AuthorizationEngine

Access InterfaceView Connector A

Implementation


View Connector BImplementation

Access Control

Policy


Figuur 3: Realisatie met een gecentraliseerde autorisatiemodule

4.1 De Access Interface

Het opstellen van een access interface wordt gedreven door het hoogniveau toe-gangscontrolebeleid van de organisatie. In de thesis wordt dit geıllustreerd aan dehand van een beleid in het medisch toepassingsdomein.

4.1.1 Illustratie: een Access Interface voor het medisch toepassings-

domein

We illustreren de voorgestelde aanpak door middel van een aantal regels en tonenaan dat de specificatie van een access interface kan worden beschouwd als de eerstestap in de verfijning van een hoogniveau beleid in een specificatiebeleid. Een spe-cificatiebeleid kan automatisch worden afgedwongen, maar biedt toch voldoendeabstractie zodanig dat dit beleid kan worden geformuleerd door de beveiligings-verantwoordelijke.

xiii

Het hoogniveau toegangscontrolebeleid. Hieronder worden een aantal be-leidsregels besproken die gebaseerd zijn op het toegangscontrolebeleid voor eenziekenhuis dat is besproken in de dissertatie van Van den Bosch [Van96] en op hetLISA-project voor huisartsen [UZL].

Regel 1 Een arts krijgt toegang tot de medische data van een patient op voor-waarde dat er een contact bestaat dat aan hem of haar werd toegewezen. Dittoegangsrecht is maar geldig tot 30 dagen nadat het contact werd afgesloten.

In bovenstaande regel moet het begrip contact worden opgevat als een logischemedisch geheel dat bijvoorbeeld overeenstemt met een ambulante raadpleging,een opname, chemotherapie.

Regel 2 Het systeem voorziet de mogelijkheid om een toegangsweigering te over-rulen, op voorwaarde dat de gebruiker een reden specificeert. Deze reden, de naamvan de gebruiker, de naam van de patient, alsook additionele contextinformatiezoals tijd en plaats worden gelogd.

Regel 3 De huisarts van de patient kan het medisch dossier van de patient tenalle tijden inkijken, ongeacht het bijhorend contact reeds afgesloten werd.

We hebben zelf nog een (gekunstelde) regel toegevoegd die het aantal toegangenvan een arts beperkt per dag, om de aggregatie van grote hoeveelheden data teverhinderen.

Regel 4 Als het aantal toegangsaanvragen door een arts voor medische data eengegeven daglimiet L overschrijdt, dan wordt verder elke toegang geweigerd.

Figuur 4 toont de formulering van deze laatste regel in Ponder. Figuur 5illustreert deze regels in de vorm van een toegangscontrolematrix.

inst

auth- limitViewAccess {subject <PhysicianRole> s=/PhysicianRole;

target <MedicalData> t=/MedicalData;

action view;

when s.nbAccesses ≥ L;

}

Figuur 4: Beleidsregel in Ponder

xiv

Roles/status (Medical Data) open ≤ 30 days closed >30 days closed

PhysicianRole create N/A N/A

if responsible and nbAccesses < L view,append,close view -

if in overrule mode and nbAccesses < L

and log (licenseID, patientID, time, lo-cation, reason)

view view view

GPRole

if patient’s GP view view view

Figuur 5: Toegangscontrolematrix

De Access Interface. Deze hoogniveau regels geven aan welke concepten moe-ten worden geıntroduceerd in de access interface. Er is zo bijvoorbeeld nood aande twee rollen arts en huisarts. De objecten voor dit beleid kunnen worden ge-catalogeerd als identificeerbare, medische data. De status van deze data is ofwelopen ofwel gesloten. De operaties op deze data zijn inzage, toevoeging en het af-sluiten. Deze laatste operatie wordt opgeroepen door de verantwoordelijke arts omhet contact af te sluiten. De access interface voor het medisch toepassingsdomeinwordt getoond in Figuur 6.

Vanuit het gezichtspunt van de access interface wordt de toepassing gezienals een set van access objecten en access subjecten. Elk access object en accesssubject wordt gekarakteriseerd door respectievelijk een object interface en subjectinterface. Een dergelijke interface introduceert attributen. Een object interfacespecificeert daarenboven ook de acties die kunnen worden uitgevoerd op het object.

4.2 De View Connector

De access interface abstraheert toegangsaanvragen. De view connector bindt dezeabstractielaag aan elke toepassing. In de thesis zijn we uitgegaan van toepassingendie zijn geschreven in een objectgeorienteerde programmeertaal. Om een dergelijkeview connector te implementeren, dient men:

1. te beslissen hoe objecten binnen de toepassing moeten worden geassocieerdmet access objecten.

2. de beveiligingsgevoelige operaties op objecten binnen de toepassing te identi-ficeren en te associeren met acties gedefinieerd door de corresponderende ob-ject interface. Deze associatie bepaalt de toegangscontrole-interceptiepunten.

3. te bepalen hoe de nodige attributen voor zowel access objecten en subjectendienen te worden berekend.

xv

AccessInterface HealthCare {

ObjectInterface MedicalData{

attribute: boolean closed;attribute: Date closingTime;attribute: String responsiblePhysician;attribute: String GP;attribute: String patientID;

action: view;action: append;action: close;init: create;

}

SubjectInterface PhysicianRole{

attribute: String licenseID;attribute: int nbAccesses;attribute: boolean accessmode;attribute: String reason;attribute: String location;

}

SubjectInterface GPRole{

attribute: String licenseID;}

}

Figuur 6: Access Interface voor het medisch toepassingsdomein

xvi

In deze sectie, zal dit alles worden geıllustreerd aan de hand van een voorbeeld-toepassing in het medisch toepassingsdomein.

4.2.1 Voorbeeld: Een view connector voor een medische toepassing

Het hierboven gespecificeerde organisatieoverkoepelend beleid dient nu te wordenafgedwongen binnen alle toepassingen die draaien binnen een ziekenhuis. Voor-beelden zijn toepassingen om afspraken te maken en om medicatie voor te schrij-ven. We hebben de aanpak toegepast op een vereenvoudigde toepassing die on-dersteuning biedt voor geıntegreerde zorgpaden. Een geıntegreerd zorgpad (ICP- Integrated Care Pathway) is een vooropgesteld plan dat een leiddraad vormtvoor de zorgverlening voor een specifieke diagnose. Het klassendiagram van dezetoepassing wordt getoond in Figuur 7.

Associatie. De medische data die dient beschermd te worden binnen deze toe-passing, zit vervat in de klassen Step en ICP. De toepassing heeft een referentienaar de huisarts (GP - General Practitioner) en naar de verantwoordelijke arts.

Toegangscontrole-interceptiepunten. De toegangscontrole-interceptie pun-ten zijn die punten binnen de uitvoering van de toepassing waar toegang moetworden gecontroleerd. De manier waarop deze toegangscontrolechecks wordengeıntegreerd in de toepassing is technologieafhankelijk. Dit kan door de integratievan invocaties van een autorisatiebeslissingsmodule. In de view connector gespe-cificeerd in Figuur 8 worden alle inspectiemethodes (getters) op een ICP geclassi-ficeerd als een inzageactie op medische data.

Attribuutberekening. De specificatie van de view connector geeft ook aan hoealle attributen in de access interface in een bepaalde toepassing dienen te wordenberekend. Een ICP -object wordt beschouwd als medische data. Het “huisarts”-attribuut kan worden bekomen door eerst de patient op te vragen, en vervolgensde huisarts van de patient. Indien mogelijk, worden de attributen opgehaald uitde toepassing. De view connector kan ook bijkomende velden declareren om toe-standsinformatie bij te houden. Dit deel van de view connector gelijkt sterk opBeznosov’s attribuutfuncties [Bez02], en de DynamicAttributeService in CORBA’sResource Access Decision (RAD) service [BDB+99].

Toegangscontrole-informatie update. Soms dient de toegangscontrole infor-matie vervat in de view connector, te worden aangepast bij een bepaalde gebeur-tenis. Het bijhouden van het aantal toegangsaanvragen door een arts vereist datdit aantal wordt opgehoogd na elke toegang. Deze toegangscontrole-informatieupdate wordt geıllustreerd door het accessCount -attribuut gespecificeerd in deview connector in Figuur 8.

xvii

Figuur 7: ICP-toepassing

ICP

+getPatient(): Patient


+close(): void

+getSteps(): Step[]

+getCreationTime(): Date

+isClosed(): boolean

+validate(): void

Patient

+getGP(): GP

+getName(): String

+getSSN(): String

GP


Personnel

+getDepartment(): Department

+getName(): String

Physician


Technician

Step

+planNextStep(): void

+getParentStep(): ComposedStep


StepTemplate

+perform(icp:ICP,c:Client): void

+getParentStepTemplate(): ComposedStepTemplate

+getNextStepTemplate(): StepTemplate

ComposedStep

+getStepAt(index:int)

ActionStep

+execute(pers:Personnel)

DecisionStep

1

*

responsible

*

11

*

1*

1

*

*

1

xviii



restricted Date closure defaultvalue null;after() close { closure = new Date();};

attributes

responsiblePhysician: wrappee.getResponsiblePhysician().getLicenseID();GP: wrappee.getPatient().getLicenseID();closed: wrappee.isClosed();closingTime: closure;patientID: wrappee.getPatient().getSSN();

actions

view : * getter(..);close: void validate();

init

create: ICP.new(..);}

subj: PhysicianRole {

final String licenseID;final String loc;restricted int accessCount defaultvalue 0;after(MedicalData+ m) view {accessCount = accessCount+1;};

boolean accessMode defaultvalue false;String reason defaultvalue “ ”;

attributes

licenseID: licenseID;nbAccesses: accessCount;accessmode: mode;reason: reason;location: loc;

}}

Figuur 8: View connector specificatie

xix

Voor een gedetailleerde beschrijving van de syntax en semantiek wordt verwe-zen naar de thesis (Secties 4.3.2 en 4.3.3).

4.2.2 Realisatie

De view connector specificatie kan op verschillende manieren worden gerealiseerd.Vooreerst kan deze specificatie louter dienst doen als een ontwerpartefact. Dezeaanpak verhoogt de ondersteuning voor evolutie, maar slaagt er nog niet in de toe-gangscontrolelogica te modulariseren. Als tweede realisatieoptie, kan op basis vande view connector een configuratiebestand (deployment descriptor) gegenereerdworden. Een dergelijk configuratiebestand ondersteunt doorgaans geen expressie-ve beleidsregels.

Het toegangscontrolebeleid kan rechtstreeks worden geweven in de toepassingop basis van de view connector specificatie. Elke wijziging van dit beleid vereistdan wel dat de logica opnieuw geweven wordt. In onze aanpak (Sectie 5) wordt deaccess interface gebonden met behulp van aspectorientatie. De toegangscontroleaanvraag wordt hierbij gedelegeerd naar een externe autorisatiemodule.

4.3 Conclusie

In deze sectie hebben we een abstractielaag voor toegangscontrole gedefinieerd dieondersteuning biedt voor het uniform en gecentraliseerd afdwingen van een ver-anderlijk organisatieoverkoepelend contextgebaseerd toegangscontrolebeleid. Dezeaccess interface specificeert alle informatie die nodig is door de autorisatiemodulevoor het afdwingen van het beleid. Voor elke toepassing dient dan een view con-nector te worden geschreven die de binding specificeert van de access interface aande toepassing.

5 Een gemodulariseerde toegangscontroledienst ter

ondersteuning van een toepassingsdomeinspeci-fiek beleid

In deze sectie zal worden beschreven hoe de concepten access interface en viewconnector kunnen worden toegepast in een modulaire toegangscontroledienst. Wezullen hierbij aantonen dat aspectgeorienteerde software ontwikkeling (AOSD) onsin staat stelt om de toepassingslogica en toegangscontrolelogica beter te scheiden.Deze sectie is gestructureerd als volgt. Eerst wordt een kort overzicht gegevenvan aspectgeorienteerd programmeren in Sectie 5.1. Vervolgens bespreken we hetontwerp van de modulaire toegangscontrole dienst in Sectie 5.2. Het Java AspectComponent (JAC) en CaesarJ prototype wordt besproken in Sectie 5.3.1 en 5.3.2,respectievelijk. In Sectie 5.4 sommen we tot slot de conclusies op.

xx

5.1 Aspect-Oriented Software Development (AOSD)

In deze sectie wordt een kort overzicht gegeven van aspectgeorienteerd softwareontwikkeling. Voor een vollediger overzicht verwijzen we de lezer naar [Cra01].Aspectorientatie is ontstaan op basis van de observatie dat huidige paradigma’s,zoals bijvoorbeeld objectorientatie te kort schieten in het modulariseren van zoge-naamde doorsnijdende belangen. De implementatie van een dergelijk belang metbehulp van huidige technieken (zoals bijvoorbeeld objectorientatie) resulteert insoftware waarvan de compositie in de eerste plaats bepaald is door het dominanteprobleem, met name de functionaliteit. De implementatie van de overige facettenvan het software programma, zoals bijvoorbeeld toepassingsniveau toegangscontro-le, wordt dan doorgaans verspreid over en verstrengeld met deze toepassingslogica.

Er zijn een aantal AOSD aanpakken voorgesteld. Deze aanpakken hebbenmet elkaar gemeen dat ze deze verspreiding en verstrengeling verminderen doormiddel van kwantificatie [FF00]. Kwantificatie stelt ons in staat om uitspraken tedoen die een impact hebben op meerdere punten in de code. Een voorbeeld vaneen uitspraak is “toegangscontrole moet worden afgedwongen bij elke methode-invocatie op een object”.

Het concept van een samenvoegingspunt (joinpoint) is hierin essentieel. Een sa-menvoegingspunt is een punt in de uitvoering van de toepassing waar de toegangs-controlelogica dient te worden ingeweven in de toepassing. Typische voorbeeldenvan samenvoegingspunten zijn methode-invocaties, het afhandelen van excepties,uitvoeringsstromen. Een zogenaamde doorsnede (pointcut) laat ons toe een setvan samenvoegingspunten te selecteren op basis van bepaalde eigenschappen, zo-als bijvoorbeeld de naam van de methode die wordt uitgevoerd, en het type van hetdoelobject. De logica die wordt geweven, wordt advies genoemd. In het voorbeeldvan toegangscontrole, bestaat dit advies uit het afdwingen van toegangscontrole.

De tweede kenmerkende eigenschap van een AOSD-aanpak [FF00], is dat hettoepassen van een aspect transparant gebeurt voor de toepassingslogica. Dezetransparantie bevordert de scheiding van belangen tussen de toepassingsopsteller(deployer) en de ontwikkelaar van de toepassing. Deze laatste dient zich idea-liter niet bewust te zijn van de beveiligingslogica waaraan de toepassing wordtonderworpen.

5.2 Overzicht van de toegangscontroledienst

De doelstelling is de implementatie van een modulaire toegangscontroledienst diein staat is een contextgebaseerd beleid af te dwingen. De toegangscontrolecol-laboratie doorsnijdt de toepassing op een zeer subtiele wijze: telkens wanneereen beveiligingsgevoelige operatie wordt uitgevoerd, dient te worden nagegaan ofhet corresponderende access subject hiervoor geautoriseerd is. Deze dienst moetkunnen worden gebonden aan de toepassing zonder invasieve wijzigingen aan detoepassing. Het toegangscontrolebeleid kan dan gewijzigd worden zonder enige

xxi


View Connector View Connector

Application a Application b

Access Interface

binding to the application

semantic actionsobject interfaces

subject interfaces (roles)attributes

evaluateAccessRequest

Access Policy

Collaboration

checkAccess

informationRetrieval

Figuur 9: Toegangscontroledienst

aanpassing aan de toepassing.Figuur 9 illustreert dat de toegangscontroledienst kan worden geımplementeerd

als een collaboratie tussen volgende drie entiteiten: een externe autorisatiemodule,de access interface en de view connectoren. Een view connector maakt gebruikvan de toegangscontrolebeslissingsfunctionaliteit (checkAccess ) telkens als eengebeurtenis voorvalt die overeenkomt met een van de semantische acties in de ac-cess interface. De checkAccess -methode wordt opgeroepen met drie argumenten:het access subject, het access object en de actie. De autorisatiemodule evalueertvervolgens of de toegangsaanvraag conform is met het beleid.

Binding. De implementatie van de binding verschilt bij de twee prototypes dierespectievelijk gebaseerd zijn op JAC en CaesarJ. De prototypes hebben met elkaargemeen dat de view connector implementatie doorsneden (pointcuts) declareertzodanig dat toegangscontrolelogica geweven wordt voor elke beveiligingsgevoeligetoegang. Zoals geıllustreerd wordt in Figuur 10, worden volgende stappen door-lopen in het advies: vooreerst wordt de toegang vertaald in termen van de accessinterface conform de view connector specificatie. Deze vertaling resulteert in eenaccess object, subject en actie. Bijvoorbeeld, de methode PregnancyICP.get-

InfectiousDiseaseRisk() wordt vertaald naar een inzage -actie op medischedata. Dit wordt vervolgens naar de autorisatiemodule gestuurd voor evaluatie.Indien toegang is toegestaan, gaat de uitvoering van de methode gewoon verderen anders wordt een foutmelding gegeven.

xxii

pICP: PregnancyICPpICP.getInfectiousDiseaseRisk()

vc: ViewConnector

ae: AuthorizationEngine

[allowed] proceed()joinpoint

2/ boolean allowed=ae.checkAccess(phys,med,"view")

phys: Physician

med: MedicalData

1/ mapping -> phys,med,"view"

sub:Subject

Figuur 10: Collaboration Diagram

Containerdienst. Een interessante toepassing voor deze toegangscontroledienstis de realisatie als een containerdienst voor een toepassingsserver. Deze dienstzou gemakkelijk moeten kunnen geconfigureerd worden door middel van de viewconnector. Deze laatste kan beschouwd worden als een configuratiebeschrijving.

5.3 Prototypes

In de context van dit doctoraat werden twee prototypes geımplementeerd. Heteerste prototype werd geımplementeerd bovenop het AOSD-raamwerk Java AspectComponents. Het tweede werd gerealiseerd met behulp van de aspectgeorienteerdeprogrammeertaal CaesarJ. Deze prototypes worden hieronder kort besproken.

5.3.1 Prototype-implementatie met Java Aspect Components

Java Aspect Components [PSDF01] (JAC) is een uitbreidbare toepassingscontai-ner, die het resultaat is van het onderzoek uitgevoerd door R. Pawlak [Paw02].Dit platform biedt ondersteuning voor het dynamisch in- en uitladen van zoge-naamde aspect-componenten. De toegangscontroledienst is geımplementeerd alseen dergelijk aspect-component.

JAC biedt ondersteuning voor het associeren van interceptoren (wrappers) meteen aspect-component. Op basis van de aspect-componenten die voor een toepas-sing worden opgesteld, zal voor elke methode een keten van interceptoren gebouwdworden. Deze keten zal dan doorlopen worden voor en na elke uitvoering vande corresponderende methode. In het geval van de toepassingsdienst zal voorelke methode die geassocieerd is met een actie in de access interface, eenzelf-de toegangscontrole-interceptor worden toegevoegd. Deze interceptor vertaalt detoegang in termen van de access interface en roept dan de autorisatiemodule aan.Het toegangscontrole aspect-component wordt geconfigureerd door middel van eenaantal configuratiebestanden. Bij deze configuratie werd ook gebruik gemaakt vande ondersteuning die JAC biedt voor het definieren van een domeinspecifieke taal.De toegangscontroledienst in JAC kan volledig declaratief geconfigureerd worden,maar ondersteunt nog geen declaratie van velden in de view connector.

xxiii

5.3.2 Prototype-implementatie met CaesarJ

CaesarJ is een extensie van de Java programmeertaal. Deze taal beoogt een be-tere ondersteuning voor de modularisatie van aspecten in herbruikbare modules.De basis ideeen achter deze aanpak werden gepresenteerd door M. Mezini en K.Ostermann [MO03, MO02]. De vertaler werd ontwikkeld door de Aspect-OrientedProgramming & Software Technology groep aan de TU Darmstadt [cae].

Centraal aan de aanpak van CaesarJ is de notie van een collaboratie-interface.Deze interface verschilt van een standaard interface doordat een collaboratie-interface niet alleen specificeert wat een component aanbiedt, maar ook wat decomponent vereist (van zijn clienten) om goed te functioneren. Het aangebodendeel in de interface wordt geımplementeerd door de implementatie. Het vereistedeel in de interface wordt geımplementeerd door de binding. Een collaboratie-interface biedt ook expliciet ondersteuning aan voor de specificatie van collabo-raties door de interactie vast te leggen tussen abstracties die specifiek zijn voorhet toepassingsdomein. Deze abstractie worden gebonden aan de toepassing doormiddel van adaptors (wrappers). In deze binding kunnen daarenboven doorsneden(pointcuts) worden gedeclareerd.

De interface van de toegangscontroledienst ziet er dan uit als volgt. Het aan-geboden gedeelte stemt overeen met de beslissingslogica (checkAccess ). Opdatde dienst goed zou functioneren, dient te worden gespecificeerd hoe de attributenin de access interface kunnen worden opgehaald. Dit laatste stemt overeen met devereisten in de interface. De abstracties (access object en access subject) kunnenworden ondersteund door geneste klassen te definieren. Deze abstracties wordengebonden aan de toepassing door middel van adaptors (wrappers). De ondersteu-ning voor het declareren van doorsneden (pointcuts) stelt ons in staat om elkebeveiligingsgevoelige actie te onderscheppen en te controleren. Figuur 11 geefteen overzicht van de implementatie van de toegangscontroledienst in CaesarJ.

Access Control Service - CaesarJ

AuthorizationEngine - Collaboration Interface (provided operation)AccessInterface - Collaboration Interface

objects & subjects - abstract nested classesactions - concrete nested classesattributes - expected operations (declaration)

View Connector - bindingdomain mapping - wrappersinformation retrieval - expected operations (implementation)semantic actions + checkAccess - pointcuts

Figuur 11: Implementatie van de toegangscontroledienst in CaesarJ

xxiv

I. Expressiveness Evolution

II. Policy Management III. System Evolution

- mediation gran.- richness- obligations- access denials

V. AssuranceIV. Scalability


- uniformity- administration scalability- access control policy mgmt- access control information mgmt- administrative policy- access control models- meta-policies- usability



Figuur 12: Toegangscontroletechnologie evaluatiecriteria

5.4 Conclusies

De twee hierboven beschreven prototype-implementaties tonen aan dat het mo-gelijk is om het afdwingen van een contextgebaseerd beleid te modulariseren metbehulp van aspectorientatie. Aspectorientatie stelt ons in staat om de doorsnij-dende interactie tussen de toepassing en de toegangscontrole te vatten. Hierbijis de ondersteuning voor collaboraties (die bijvoorbeeld door CaesarJ aangebodenwordt) bijzonder nuttig gebleken. Verder onderzoek is nodig om deze AOSD-aanpakken zelf veiliger te maken, zodanig dat de toegangscontrolelogica zelf nietkan worden omzeild. Bovendien moet verder onderzoek verricht worden om op eengoede manier met toegangsweigeringen om te gaan.

6 Evaluatie en gerelateerd werk

In deze sectie wordt de voorgestelde aanpak geplaatst in een ruimere context. Ditgebeurt door vooreerst in Sectie 6.1 een uitgebreide set van evaluatiecriteria op telijsten aan de hand van dewelke onze aanpak wordt vergeleken. Ten tweede wordtgerelateerd werk besproken in Sectie 6.2.

6.1 Evaluatiecriteria voor toegangscontroletechnologieen

We hebben een set van criteria opgesteld om toegangscontroletechnologieen teevalueren. Deze criteria zijn onderverdeeld in vijf categorieen, namelijk (1) ex-pressiviteit, (2) beleidsbeheer, (3) systeemevolutie, (4) schaalbaarheid en (5) ga-rantie. We bespreken hier de belangrijkste conclusies en vergelijken met bestaandetechnologieen. Figuur 12 geeft deze lijst van criteria weer.

xxv

6.1.1 Expressiviteit

De expressiviteit van een toegangscontroletechnologie meet de varieteit in toe-gangscontrolebeleidsregels die kunnen worden afgedwongen.

Rijkdom aan informatie. De hoeveelheid informatie die bij de evaluatie vaneen toegangsaanvraag in rekening kan worden gebracht, ligt vast door de specifi-catie van de access interface. Door middel van attributen, kan de toestand vanaccess objecten en subjecten worden opgevraagd. Deze attributen kunnen tevensworden gebruikt om relaties tussen access objecten en subjecten vast te leggen, zo-als werd geıllustreerd met het attribuut “verantwoordelijke arts”. In tegenstellingtot de Resource Access Decision Facility (RAD) [BDB+99] en Tivoli Access Ma-nager (TAM) [Kar03] voorziet deze aanpak ook de binding van het informatiepunt(PIP) met de toepassing. De vooropgestelde aanpak maakt bovendien explicietwelke informatie moet worden geleverd door de toepassing, in tegenstelling totde Object Security Attributes [Bez02] (OSA) waar een generieke interface wordtvoorzien voor het ophalen van attributen.De access interface zou kunnen uitgebreid worden voor de ondersteuning van meercomplexere principalen, of het in rekening brengen van methodeargumenten.

Granulariteit. De granulariteit van de view connector ondersteunt interface-methode granulariteit, en is daarmee minder granulair dan de aanpakken die toe-gangscontrolechecks hard coderen in de toepassing. We merken hierbij op dattechnisch gezien veel AOSD-aanpakken doorsneden (pointcuts) ondersteunen dieeen fijnkorreligere granulariteit ondersteunen.

6.1.2 Beleidsbeheer

De criteria die ressorteren onder beleidsbeheer hebben gemeen dat ze de ondersteu-ning meten voor het specificeren, het opstellen en het aanpassen van het beleid.We bespreken hier achtereenvolgens de criteria uniformiteit en beheer van hettoegangscontrolebeleid.

Uniformiteit. De access interface introduceert een abstractielaag die een uni-form gezichtspunt representeert op een aantal toepassingen. In Sectie 5 hebben wevervolgens aangetoond dat de view connector, die dit gezichtspunt aan een toepas-sing bindt, kan worden gerealiseerd als onderdeel van een toegangscontroledienstdie gebruik maakt van een centrale autorisatiemodule. Deze laatste ondersteunteen gecentraliseerd beheer van het beleid. Ook de Resource Access Decision Fa-cility (RAD) [BDB+99] biedt ondersteuning aan voor het abstraheren van toe-passingsspecifieke toegangsaanvragen. Deze abstracties dienen echter toegepastte worden door de toepassingsontwikkelaar zelf. Hetzelfde geldt voor de TivoliAccess Manager [Kar03] dat gebruik maakt van een beschermde objectruimte. De

xxvi

URL-bindingen die door WebSEAL worden gebruikt om dynamische URLs metdergelijke beschermde objecten te associeren, kunnen worden gezien als (gelimi-teerde) view connectoren.

Beheer van het toegangscontrolebeleid. Het toevoegen van regels wordt ookvergemakkelijkt door de topdown aanpak die de voorgestelde oplossing voorsteltvoor de integratie van een toegangscontrolebeleid. Het toevoegen van een beleids-regel is eenvoudig in het geval alle benodigde informatie wordt gespecificeerd in deaccess interface. Een eventuele uitbreiding van de access interface wordt goed on-dersteund omwille van het feit dat de view connector eerdere beslissingen explicietmaakt.

6.1.3 Systeemevolutie

Systeemevolutiecriteria meten in welke mate de toegangscontroletechnologie kanworden aangepast om nieuwe vereisten te ondersteunen. In tegenstelling tot debeleidsbeheer criteria wordt er hier gefocust op de impact die deze veranderingenhebben op de architectuur of op het mechanisme, eerder dan op de specificatievan het toegangscontrolebeleid. In Sectie 3.2 hebben we beschreven dat een ge-modulariseerde PDP, een uitbreidbare PIP en een transparante PEP dit criteriumgunstig beınvloeden. De voorgestelde toegangscontroledienst omvat een gemodu-lariseerde PDP. Het gebruik van AOSD-technieken houdt de toepassingslogica vrijvan hard gecodeerde toegangscontrolechecks. De PIP kan worden uitgebreid doorbijkomende interfaces en attributen te declareren in de access interface, en in decorresponderende view connector te specificeren.

Een tweede eigenschap van een technologie is het moment wanneer adaptatieskunnen worden doorgevoerd. Een systeem kan bijvoorbeeld run-time adaptatiesondersteunen.

6.1.4 Schaalbaarheid

Het afdwingen van een toegangscontrolebeleid heeft een impact op de run-timeperformantie van het systeem. Bij de ontwikkeling van de prototypes hebben wetotnogtoe geen rekening gehouden met de performantie van het systeem. Dezeoverhead is afhankelijk van de AOSD-techniek die wordt gebruikt, en van de wijzewaarop de view connector gerealiseerd is.

Architecturale schaalbaarheid is een criterium dat meet hoe goed een toegangs-controle-infrastructuur scaleert naar een grote en heterogene omgeving, met bij-voorbeeld een groot aantal machines en toepassingen.

xxvii

6.1.5 Garantie

In [Sno05] definieert Snow het werken aan garanties in termen van een aantalvertrouwensverhogende activiteiten, waarbij wordt nagegaan dat:

1. het beveiligingsbeleid intern consistent is en de vereisten van de organisatiereflecteert.

2. er voldoende beveiligingsfuncties zijn die het beleid ondersteunen.

3. de beveiligingsfuncties de gewenste eigenschappen hebben, en enkel dezeeigenschappen.

4. de beveiligingsfuncties correct geımplementeerd zijn.

5. de garanties geldig blijven gedurende de productie, aflevering en levencyclusvan het systeem.

Onze aanpak verhoogt het vertrouwen door het expliciet vastleggen van hetorganisatieoverkoepelend beleid en het afdwingen van dit beleid op een consistentemanier. Deze garanties dienen echter nog sterk verhoogd te worden. In bijzonder,dienen er garanties te zijn omtrent de correcte implementatie van het principe vancomplete mediatie.

6.2 Gerelateerd werk

Dit werk is gerelateerd aan een aantal onderzoeksdomeinen.

Modelgedreven beveiliging. SecureUML [BDL06] beschrijft een modelgedre-ven aanpak voor de integratie van het beveiligingsaspect in het ontwikkelings-proces, waarbij een platformonafhankelijk metamodel wordt opgesteld dat kanworden aangepast aan een bepaalde ontwerptaal. Een beleid dat is geformuleerdop basis van dit model, kan dan door middel van generatoren worden vertaaldnaar configuratiebeschrijvingen (deployment descriptors) of vertaald worden naartoegangscontrolechecks.

Burt en coauteurs [BBR+03] stellen een geunificeerd toegangscontrolemodelvoor als een platformonafhankelijk model, met als doelstelling platformafhankelijkemodellen te genereren (bijvoorbeeld voor JAAS en RAD) voor de integratie vantoegangscontrole in heterogene systemen.

Beheersbare toegangscontrole. De View Policy Language [Bro02] (VPL) be-oogt een betere scheiding van belangen om te komen tot een beheersbare toegangs-controle. VPL groepeert toegangsrechten in getypeerde gezichtspunten (views) diekunnen worden toegewezen aan rollen. In VPL worden deze views geconstrueerdop basis van use-cases.

xxviii

Toegangscontrole talen en raamwerken. Het ontwerp van de toegangscon-troledienst heeft een gelijkaardige decompositie als werd voorgesteld door hetISO/IEC 10181-3 toegangscontroleraamwerk [ISO] en het XACML [OAS] (eX-tensible Access Control Markup Language) datastroomdiagram. De voorgesteldeaanpak steunt op onderzoek dat werd verricht omtrent beleidstalen en autorisa-tiemodules. Op basis van de access interface kan een beleid worden geformuleerdin XACML [OAS] of Ponder [Dam02].

De voorgestelde aanpak kan worden gezien als een toepassing van de metho-dologie die wordt voorgesteld door Verlaenen en coauteurs [VWJ07]. Zij ontwik-kelden een generiek beleidsraamwerk dat toelaat om toepassingsdomeinconceptente associeren met concepten in de beleidsontologie. Deze associatie resulteert bij-voorbeeld in het specificeren van additionele attributen voor subject, actie, objecten omgeving.

AOSD en beveiliging. Het gebruik van AOSD is reeds succesvol gebleken bijhet modeleren van het toegangscontroleaspect. Song en coauteurs [SRF+05] ge-bruiken aspectgeorienteerd modelleren om de toepassings- en toegangscontrolelo-gica op een verifieerbare manier samen te stellen. Onze aanpak kan worden be-schouwd als een toepassing van het principe van multidimensionale scheiding vanbelangen [TOHS99] (MDSOC - Multidimensional separation of concerns) voorbeveiliging. Hierbij bouwt dit werk voort op het werk door De Win en coau-teurs [DPJ06] die aantonen dat de implementatie van toegangscontrole op toe-passingsniveau succesvol kan worden gemodulariseerd met behulp van aspecto-rientatie.

Technieken voor het afdwingen van een beleid. Gerelateerd aan deze as-pectgeorenteerde aanpak is het werk rond ingelijnde referentiemonitoren [ES00](IRM - Inlined Reference Monitors). Deze monitoren zijn transparant voor detoepassing en worden geımplementeerd door bij het laden checks toe te voegenaan de Java-bytecode.

Naccio [ET99] integreert een beleid door middel van decoratorfuncties diechecks incorporeren en vervolgens de originele systeemfunctie oproepen. Het be-leid wordt gespecificeerd in termen van abstracte operaties en zijn derhalve plat-formonafhankelijk. De toepassing wordt getransformeerd om de oproepen naarsysteemfuncties te vervangen door oproepen naar de decoratorfuncties.

Polymer [BLW05] gebruikt tevens programmamonitoren om een beveiligings-beleid af te dwingen. Deze monitoren kunnen het gedrag van een toepassingveranderen at run-time, door bijvoorbeeld de uitvoering te staken, andere codetoe te voegen of de terugkeerwaarde van een actie te veranderen. Polymer biedtbovendien ondersteuning voor het samenstellen van beleidsregels en het definierenvan abstracte acties.

xxix

Contextgebaseerde toegangscontrole. In de ISO/IEC standaard 10181-3 [ISO]voor toegangscontroleraamwerkenwordt een contextgebaseerd schema gedefinieerdals een schema waarin de beleidsregels betrekking hebben op contextinformatie. Erbestaan een groot aantal aanpakken die een extensie op een gevestigd toegangscon-trolemodel (zoals RBAC) definieren om contextinformatie in rekening te brengen.Een voorbeeld van een dergelijke extensie is het TemporalRBAC model [BBF01],dat RBAC uitbreidt met de mogelijkheid om rollen periodiek te (de)activeren.Strembeck en Neumann [SN04] stellen een aanpak voor om RBAC uit te brei-den met contextbeperkingen. McDaniel [McD03] presenteert het ontwerp van deAntigone Condition Framework (ACF) als een generieke conditiedienst voor deintegratie van complexe en gedistribueerde evaluatie van condities.

7 Conclusie

Deze thesis handelt over uniforme en modulaire contextgebaseerde toegangscon-trole. De bijdragen van dit werk zijn:

1. de introductie van de concepten access interface en view connector. Deaccess interface is een domeinmodel dat ondersteuning biedt voor het spe-cificeren van toepassingsdomeinspecifieke informatie. Deze interface biedtondersteuning voor een uniforme en gecentraliseerde specificatie van een or-ganisatieoverkoepelend en evoluerende toegangscontrolebeleid. Deze accessinterface kan gebonden worden aan elk van de toepassingen door middel vaneen view connector.

2. het ontwerp van een modulaire toegangscontroledienst als een collaboratietussen een autorisatiemodule, access interface en view connector. Bij dit ont-werp werd gesteund op aspectorientatie om het doorsnijdend karakter van deinteractie te beschrijven en de toegangscontrolelogica te encapsuleren in eenduidelijk afgescheiden module. Er werden twee prototypes geımplementeerdmet behulp van Java Aspect Components en CaesarJ.

3. het opstellen van een uitgebreide lijst van criteria voor het evalueren vantoegangscontroletechnologieen, alsook een evaluatie van de ontwikkelde toe-gangscontroledienst op basis van deze criteria.

Op basis van deze resultaten kunnen een aantal interessante pistes voor toe-komstig onderzoek worden geıdentificeerd.

De subject interface kan worden uitgebreid om complexere contextinformatiete vatten. De subject interface is in zijn huidige definitie in de eerste plaatsgeschikt voor een toegangscontroleoplossing in een gesloten omgeving waarbij detoegangscontrole centraal beheerd wordt.

In de specificatie van de view connector werd reeds een eerste aanzet gegevenvoor het updaten van toegangscontrole-informatie. In de toekomst moet worden

xxx

onderzocht hoe dit eenvoudige administratieve toegangscontrolemodel kan wordenuitgebreid om meer gedecentraliseerd beheer te ondersteunen, zoals bijvoorbeeldvereist door het discretionaire toegangscontrolemodel (DAC - Discretionary AccessControl Model).

Een andere interessante uitbreiding van de access interface is de ondersteuningvoor obligaties, filters en gebeurtenissen binnen de toepassing.

De automatische generatie van de view connectoren op basis van hun specifi-catie dient nog uitgebreider te worden gevalideerd. Modelgedreven architectuur(MDA- Model-Driven Architecture) is een veelbelovende aanpak om deze viewconnectoren voor verschillende componentplatformen en AOSD-technieken te ge-nereren.

Er is tevens een uitgebreider validatie nodig van de implementatie van de accessinterface aanpak bovenop een industrieel componentplatform, zoals bijvoorbeeldJBoss [jbo]. Dit zou ons in staat stellen om de aanpak te valideren voor groot-schalige toepassingen.

Een andere interessant onderwerp voor nader onderzoek is het gebruik van eenhogerniveau doorsnedentaal (pointcut language) om het beleid rechtstreeks mee teformuleren.

Tot slot, is het interessant om te onderzoeken in welke mate een evaluatieset(benchmark) kan worden gebouwd op basis van de evaluatiecriteria, besproken inSectie 6.1.

Referenties

[And96] R.J. Anderson. Security in Clinical Information Systems, 1996. BritishMedical Association.

[BBF01] E. Bertino, P.A. Bonatti, and E. Ferrari. TRBAC: A temporal role-basedaccess control model. ACM Transactions on Information and SystemSecurity, 4(3):191–233, 2001.

[BBR+03] C.C. Burt, B.R. Bryant, R.R. Raje, A. Olson, and M. Auguston. Mo-del Driven Security: Unification of Authorization Models for Fine-GrainAccess Control. In EDOC ’03: Proceedings of the 7th International Con-ference on Enterprise Distributed Object Computing, page 159, Washing-ton, DC, USA, 2003. IEEE Computer Society.

[BDB+99] K. Beznosov, Y. Deng, B. Blakley, C. Burt, and J. Barkley. A Resour-ce Access Decision Service for CORBA-based Distributed Systems. InACSAC ’99: 15th Annual Computer Security Applications Conference,pages 310–319, 1999.

xxxi

[BDL06] D. Basin, J. Doser, and T. Lodderstedt. Model Driven Security: fromUML Models to Access Control Infrastructures. ACM Transactions onSoftware Engineering and Methodology, 15(1):39–91, January 2006.

[Bez00] K. Beznosov. Engineering Access Control for Distributed Enterprise Ap-plications. PhD thesis, Florida International University, July 2000.

[Bez02] K. Beznosov. Object Security Attributes: Enabling Application-SpecificAccess Control in Middleware. In DOA’02: 4th International Symposi-um on Distributed Objects & Applications, pages 693–710, London, UK,October 2002. Springer-Verlag.

[BLW05] L. Bauer, J. Ligatti, and D. Walker. Composing Security Policies withPolymer. In PLDI ’05: Proceedings of the 2005 ACM SIGPLAN confe-rence on Programming language design and implementation, pages 305–314, New York, NY, USA, 2005. ACM Press.

[Bro02] G. Brose. Manageable Access Control for CORBA. Journal of ComputerSecurity, 10(4):301–337, 2002.

[cae] CaesarJ Homepage: http://caesarj.org/.

[Cou97] Counsel of Europe. Recommendation R(97)5, On the protection of me-dical data, February 1997.

[Cra01] D. Crawford. Special issue on AOP. Communications of the ACM,44(10), October 2001.

[Dam02] N. Damianou. A Policy Framework for Management of Distributed Sys-tems. PhD thesis, Imperial College London, February 2002.

[Dij82] E.W. Dijkstra. On the role of scientific thought. LNCS, 1982.

[DPJ06] B. De Win, F. Piessens, and W. Joosen. How secure is AOP and whatcan we do about it? In SESS ’06: Proceedings of the 2006 InternationalWorkshop on Software Engineering for Secure Systems, pages 27–34, NewYork, NY, USA, 2006. ACM Press.

[DPJV02] B. De Win, F. Piessens, W. Joosen, and T. Verhanneman. On theimportance of the separation-of-concerns principle in secure software en-gineering. In C. Serban, editor, ACSA Workshop on the Application ofEngineering Principles to System Security Design - Final Report, No-vember 2002.

[EC95] European Parliament and Council of Europe. Directive 95/46/EC, onthe protection of individuals with regard to the processing of personaldata and on the free movement of such data, October 1995.

xxxii

[ES00] U. Erlingsson and F.B. Schneider. IRM enforcement of java stack in-spection. In IEEE Symposium on Security and Privacy, pages 246–255,2000.

[ET99] D. Evans and A. Twyman. Flexible Policy-Directed Code Safety. InIEEE Symposium on Security and Privacy, pages 32–45, 1999.

[FF00] R.E. Filman and D.P. Friedman. Aspect-Oriented Programming is Quan-tification and Obliviousness, October 2000. Workshop on Advanced Se-paration of Concerns, OOPSLA 2000.

[ISO] ISO. Information technology - open systems interconnection - securityframework for open systems: access control framework. ISO/IEC 10181-3(ITU-T X.812).

[jbo] Jboss homepage: http://jboss.com.

[Kar03] G. Karjoth. Access Control with IBM Tivoli Access Manager. ACMTransactions on Information and System Security, 6(2):232–257, 2003.

[McD03] P. McDaniel. On Context in Authorization Policy. In SACMAT ’03:Proceedings of the eighth ACM Symposium on Access Control Modelsand Technologies, pages 80–89, New York, NY, USA, 2003. ACM Press.

[MO02] M. Mezini and K. Ostermann. Integrating Independent Components withOn-Demand Remodularization. In OOPSLA ’02: Proceedings of the 17thACM Conference on Object-Oriented Programming, Systems, Languages,and Applications, 2002.

[MO03] M. Mezini and K. Ostermann. Conquering aspects with Caesar. In AOSD’03: Proceedings of the 2nd International Conference on Aspect-OrientedSoftware Development, pages 90–99, New York, NY, USA, 2003. ACMPress.

[OAS] OASIS. Core Specification: eXtensible Access Control Markup Language(XACML) Version 2.0.

[Par72] D.L. Parnas. On the Criteria To Be Used in Decomposing Systems intoModules. Communications of the ACM, 15(12):1053–1058, 1972.

[Paw02] R. Pawlak. La Programmation Orientee Aspect Interactionnelle pourla Construction d’Applications a preoccupations Multiples. PhD thesis,CNAM Paris, December 2002.

[PSDF01] R. Pawlak, L. Seinturier, L. Duchien, and G. Florin. JAC: A FlexibleFramework for AOP in Java. In Reflection’01, volume 2192 of Lectu-re Notes in Computer Science, pages 1–24. Springer-Verlag, September2001.

xxxiii

[Sec02a] Secretary of the Department of Health and Human Services. Final Pri-vacy Rule, August 2002.

[Sec02b] Secretary of the Department of Health and Human Services. Final Secu-rity Rule, February 2002.

[SN04] M. Strembeck and G. Neumann. An Integrated Approach to Engineerand Enforce Context Constraints in RBAC Environments. ACM Trans-actions on Information and System Security, 7(3):392–427, 2004.

[Sno05] B. Snow. We need assurance! In ACSAC ’05: Proceedings of the 21stAnnual Computer Security Applications Conference, pages 3–10, Was-hington, DC, USA, 2005. IEEE Computer Society.

[SRF+05] E. Song, R. Reddy, R. France, I. Ray, G. Georg, and R. Alexander.Verifiable Composition of Access Control and Application Features. InSACMAT ’05: Proceedings of the tenth ACM Symposium on Access Con-trol Models and Technologies, pages 120–129, New York, NY, USA, 2005.ACM Press.

[TOHS99] P. Tarr, H. Ossher, W. Harrison, and S. M. Sutton, Jr. N Degreesof Separation: Multi-Dimensional Separation of Concerns. In ICSE ’99:Proceedings of the 21st International Conference on Software Enginee-ring, pages 107–119, Los Alamitos, CA, USA, 1999. IEEE ComputerSociety Press.

[UZL] U.Z. Leuven: Leuvense Internet Samenwerking Artsen (LISA).http://www.uzleuven.be/UZroot/content/Zorgverleners/login/lisa/(dutch).

[Van96] B. Van den Bosch. The design and the development of the hospital infor-mation system of the U.Z. Leuven. PhD thesis, Katholieke UniversiteitLeuven, 1996.

[VWJ07] K. Verlaenen, B. De Win, and W. Joosen. Towards simplified specifica-tion of policies in different domains. In 10th IFIP/IEEE Symposium onIntegrated Management (IM2007), Munich, Germany, May 2007.

xxxiv

Uniform and Modular Context-Based Access Control for ...aspect orientation. We found that the...

Documents

Transcript of Uniform and Modular Context-Based Access Control for ...aspect orientation. We found that the...