Model Driven Security

from UML Models to Access Control Architectures

Dissertation zur Erlangung des Doktorgrades der Fakultat fur AngewandteWissenschaften der Albert-Ludwigs-Universitat Freiburg im Breisgau

vorgelegt von Torsten Lodderstedt

2003

• Dekan: Prof. Dr. Thomas Ottmann

• Prufungskommision:

– Prof. Dr. Stefan Leue

– Prof. Dr. Christoph Scholl

– Prof. Dr. David Basin

– Prof. Dr. Gunter Muller

• Termin der Disputation: 15.03.2004

2

Zusammenfassung

Sicherheit ist ein integraler Bestandteil moderner IT-Systeme und die Ent-wicklung solcher Systeme erfordert es, die notwendigen Sicherheitstechnolo-gien zu identifizieren und sie zu integrieren. Beispiele fur solche Technologiensind Zugriffskontrolle zum Schutz von Systemressourcen vor unerlaubtem Zu-griff, Verschlusselung, um die Vertraulichkeit von Daten wahrend ihrer Uber-tragung uber ein Netzwerk zu schutzen, und die Verwendung von digitalenSignaturen zum elektronischen Unterzeichnen von Vertragen. Obwohl einegroße Anzahl von Sicherheitsarchitekturen und -technologien verfugbar ist,gibt es beinahe taglich Berichte von Fehlern in den Sicherheitsmechanismenvon IT-Systemen.

Warum ist es so schwierig, robuste, sichere Systeme zu entwickeln? EineAnalyse der Softwareentwicklungsprozesse wie sie heute typischerweise ange-wendet werden zeigt, daß Sicherheit nicht systematisch sondern zumeist adhoc behandelt wird. In vielen Fallen werden Sicherheitsanforderungen erstkurz vor oder wahrend der Inbetriebnahme eines Systems analysiert und im-plementiert. Hinzu kommt, daß die Systementwicklung und die Realisierungvon Sicherheitmechanismen zumeist getrennt von verschiedene Personengrup-pen durchgefuhrt werden, den Software-Entwicklern auf der einen Seite undden Sicherheitsexperten auf der anderen Seite. Dafur gibt es technologischeund kulturelle Grunde.

Insbesondere muß man ein Defizit an Methoden und Werkzeugen kon-statieren, die eine enge Integration der Sicherheit in den allgemeinen Soft-wareentwicklungsprozeß unterstutzen. Selbst Standardprozesse, wie der Ra-tional Unified Process [26] oder das deutsche V-Modell [15] geben nur ober-flachliche Hinweise, wie Sicherheit berucksichtigt werden sollte. Des weite-ren spielt die Sicherheit im typischen Projektplan keine prominente Rolleund sie wird auch durch die Struktur der meisten Entwicklungsorganisatio-nen nicht unterstutzt. Auch dort kann man eine starke Trennung zwischenSoftware-Entwicklern und Sicherheitsexperten beobachten. Das Resultat die-ser Vorgehensweise sind IT-Systeme in denen die Sicherheit als nachrangigesProblem behandelt wird und wo Sicherheitsmechanismen nur schlecht in dasGesamtsystem integriert sind.

Die Notwendigkeit diese Mangel zu beheben wurden in der Literatur schonfestgestellt (z.B. in [14]) und die zunehmende Nachfrage am Markt nach Sy-stemen mit zertifizierten Sicherheitseigenschaften verstarkt den Druck. DennZertifizierungsstandards wie die “Information Technology Security Evalua-tion Criteria” [35] oder die“Common Criteria” [11] erfordern vor allen Dingeneines: einen ausgereiften Softwareentwicklungsprozeß, in welchem Sicherheitein integraler Bestandteil ist.

3

Wir schlagen Model Driven Security als eine Methode vor, um diese De-fizite zu beheben. Die Kernidee von Model Driven Security ist, daß Softwa-redesigner IT-Systeme in Modellen spezifizieren, welche auch die gewunsch-ten Sicherheitseigenschaften des Systems beschreiben. Basierend auf diesenModellen werden dann mit Hilfe von Werkzeugen Systemarchitekturen mitkompletten und vollstandig konfigurierten Sicherheitsmechanismen generiert.

Auf diese Weise ermoglicht Model Driven Security die enge Integrati-on von Sicherheit in den Entwicklungsprozess. Unsere Methode kann daherverwendet werden, um die Produktivitat bei der Entwicklung von sicherenSoftwaresystemen zu erhohen und die Qualitat der resultierenden Systemezu verbessern.

Anstatt eine einzige Modellierungssprache fur diesen Prozeß vorzugeben,schlagen wir ein Schema fur die Definition solcher Sprachen vor, in welchemSprachen fur die Systemmodellierung mit solchen fur die Modellierung vonSicherheitseigenschaften kombiniert werden.

Wir prasentieren verschiedene Beispiele fur die Anwendung dieses Sche-mas, in welchen UML-basierte Modellierungssprachen mit einer Sprache furdie Spezifikation von Zugriffskontrollmodellen kombiniert werden. Wir zeigenaußerdem, wie auf der Basis von Modellen in diesen Sprachen Zugriffskon-trollarchitekturen fur verteilte Systeme generiert werden konnen. Die Model-lierungssprachen und der Generierungsprozess sind semantisch wohl fundiertund basieren auf einer Erweiterung von rollenbasierter Zugriffskontrolle. Wirhaben unsere Methode in einem Werkzeug implementiert, welches wir imRahmen einer Fallstudie angewendet haben, und wir berichten von unserenErfahrungen.

4

Preface

We present a new approach to building secure systems. In our approach,which we call Model Driven Security, designers specify system models alongwith their security requirements and use tools to automatically generate sys-tem architectures from the models including complete, configured securityinfrastructures. In that way, Model Driven Security helps to tightly integratesecurity into the software development process. As a result, our approach canbe used to improve both the productivity of the developers of secure softwaresystems and the quality of the resulting systems.

Rather than fixing one particular modeling language for this process, wepropose a schema for constructing such languages that combines languagesfor modeling systems with languages for modeling security. Thus the schemaallows language designers to leverage expert know-how that is required todefine a modeling language for a particular area as well as accompanyingmethods and tools.

We present different instances of this schema, which combine differentUML modeling languages with a security modeling language for formalizingaccess control requirements. From models in these languages, we automati-cally generate access control architectures for distributed applications. Themodeling languages and generation process are semantically well-founded andare based on an extension of role-based access control. We have implementedthis approach in a prototypical tool that we used to conduct a case studyand report on experiences.

5

6

Contents

1 Introduction 111.1 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . 151.2 Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2 Background 192.1 A Design Problem . . . . . . . . . . . . . . . . . . . . . . . . 192.2 Model Driven Architecture . . . . . . . . . . . . . . . . . . . . 20

2.2.1 The Unified Modeling Language . . . . . . . . . . . . . 212.2.2 The Meta Object Facility . . . . . . . . . . . . . . . . 252.2.3 Defining Modeling Languages . . . . . . . . . . . . . . 282.2.4 Model Transformations . . . . . . . . . . . . . . . . . . 30

2.3 Role-Based Access Control . . . . . . . . . . . . . . . . . . . . 302.4 Security Architectures . . . . . . . . . . . . . . . . . . . . . . 32

2.4.1 Enterprise JavaBeans . . . . . . . . . . . . . . . . . . . 322.4.2 Enterprise Services for .NET . . . . . . . . . . . . . . . 352.4.3 Java Servlets . . . . . . . . . . . . . . . . . . . . . . . 35

3 Model Driven Security: an Overview 373.1 Language Definition Techniques . . . . . . . . . . . . . . . . . 39

3.1.1 MOF-Mapping to Relational Models . . . . . . . . . . 393.1.2 The Role of Semantics in Model Driven Security . . . . 41

3.2 Combining Modeling Languages . . . . . . . . . . . . . . . . . 413.3 Model Transformation . . . . . . . . . . . . . . . . . . . . . . 443.4 Outlook . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

4 SecureUML 474.1 Abstract Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 474.2 Concrete Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 494.3 Building SecureUML Dialects . . . . . . . . . . . . . . . . . . 53

4.3.1 Integrating the Abstract Syntax . . . . . . . . . . . . . 544.3.2 Integrating the Concrete Syntax . . . . . . . . . . . . . 55

7

4.3.3 The Structure of Security Design Models . . . . . . . . 564.4 Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

4.4.1 Static Part . . . . . . . . . . . . . . . . . . . . . . . . 584.4.2 Dynamic Part . . . . . . . . . . . . . . . . . . . . . . . 594.4.3 Default Behavior . . . . . . . . . . . . . . . . . . . . . 62

5 Example Modeling Language: ComponentUML 635.1 Language Definition . . . . . . . . . . . . . . . . . . . . . . . 635.2 SecureUML Dialect for ComponentUML . . . . . . . . . . . . 65

5.2.1 Extending the Abstract Syntax . . . . . . . . . . . . . 655.2.2 Formal Definition of ComponentUML Models . . . . . 685.2.3 Extending the Concrete Syntax . . . . . . . . . . . . . 70

5.3 Example Authorization Policy . . . . . . . . . . . . . . . . . . 725.3.1 Policy Semantics . . . . . . . . . . . . . . . . . . . . . 73

6 Generating Systems from ComponentUML Models 756.1 Notation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 766.2 Enterprise JavaBeans . . . . . . . . . . . . . . . . . . . . . . . 77

6.2.1 Basic Generation Rules for EJB . . . . . . . . . . . . . 776.2.2 Generating Access Control Infrastructures . . . . . . . 81

6.3 Correctness of Generation . . . . . . . . . . . . . . . . . . . . 916.3.1 Informal Semantics of EJB Access Control . . . . . . . 916.3.2 Proof Strategy and Discussion . . . . . . . . . . . . . . 92

6.4 Verification of the Sub-function for Declarative Access Control 956.4.1 EJB Declarative Access Control . . . . . . . . . . . . . 966.4.2 Model Transformation Function . . . . . . . . . . . . . 976.4.3 Proof . . . . . . . . . . . . . . . . . . . . . . . . . . . . 996.4.4 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 103

6.5 Transformation Function for .NET Systems . . . . . . . . . . 1036.5.1 Basic Generation Rules for .NET . . . . . . . . . . . . 1036.5.2 Generating Access Control Infrastructures . . . . . . . 104

7 ControllerUML 1077.1 Language Definition . . . . . . . . . . . . . . . . . . . . . . . 1077.2 SecureUML Dialect for ControllerUML . . . . . . . . . . . . . 109

7.2.1 Extending the Abstract Syntax . . . . . . . . . . . . . 1107.2.2 Extending the Concrete Syntax . . . . . . . . . . . . . 111

7.3 Example Authorization Policy . . . . . . . . . . . . . . . . . . 1127.4 Transformation to Web Applications . . . . . . . . . . . . . . 113

7.4.1 Basic Transformation Function . . . . . . . . . . . . . 1137.4.2 Generating Access Control Infrastructures . . . . . . . 115

8

8 Tool Support and Development Process 1198.1 Tool Support . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

8.1.1 Tool Foundation . . . . . . . . . . . . . . . . . . . . . 1198.1.2 Prototype Architecture . . . . . . . . . . . . . . . . . . 1208.1.3 OCL Support . . . . . . . . . . . . . . . . . . . . . . . 1218.1.4 Security Designer . . . . . . . . . . . . . . . . . . . . . 122

8.2 Development Guidelines . . . . . . . . . . . . . . . . . . . . . 1248.2.1 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . 1258.2.2 Design . . . . . . . . . . . . . . . . . . . . . . . . . . . 1268.2.3 Implementation . . . . . . . . . . . . . . . . . . . . . . 1288.2.4 Deployment . . . . . . . . . . . . . . . . . . . . . . . . 129

9 Case Study 1319.1 Use Case Model . . . . . . . . . . . . . . . . . . . . . . . . . . 1319.2 Design Model . . . . . . . . . . . . . . . . . . . . . . . . . . . 1339.3 Use Case Model Annotations . . . . . . . . . . . . . . . . . . . 1359.4 Access Control Policy . . . . . . . . . . . . . . . . . . . . . . . 1369.5 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138

10 Conclusions 14110.1 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . 14210.2 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143

A Appendix 147A.1 OCL Translation to First-order Logic . . . . . . . . . . . . . . 147A.2 Translation of ComponentUML Atomic Actions to EJB method-

elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149A.3 OCL Translation to Java . . . . . . . . . . . . . . . . . . . . . 150

Bibliography 153

9

10

Chapter 1

Introduction

Security is an integral part of most modern IT systems and designing suchsystems requires properly identifying, integrating, and configuring differentsecurity technologies. Examples of such technologies include access controlfor preventing unauthorized access to system resources, encryption to ensurethe confidentiality of data during network transmissions, and digital signa-tures for electronic contract signing. Although a broad number of securityarchitectures and technologies are available, we hear daily accounts of secu-rity vulnerabilities and failures.

Why is it so difficult to engineer robust, secure systems? A glance at thesystem development processes typically used suggests one reason: securityis often managed in an ad-hoc fashion where requirements are analyzed andmechanisms are implemented shortly before, or even during, the system in-stallation and deployment phase. Concerns are often separated and handledseparately by software engineers and security specialists. This has technolog-ical reasons as well as cultural ones. In particular, there is a lack of methodsand tools for tightly integrating security into the development process. Evenstandard software development processes like the Rational Unified Process[26] or the German V-Model [15] only give rough guidelines concerning secu-rity. Furthermore, security does neither play a prominent role in the typicalproject plan nor is it supported by the structure of most development orga-nizations with a strong separation between software developers and securityexperts. The result is systems where security is often dealt with as an af-terthought and where security mechanisms are poorly integrated into thesystem.

The need to overcome this deficiency has been noted before, e.g. in [14],and it will become more important due to the growing demand for softwaresystems with certified security properties. Certification standards like the“Information Technology Security Evaluation Criteria” [35] or the “Common

11

Criteria” [11] first of all require a mature software development process inwhich security is an integral part.

We propose Model Driven Security as an approach to overcoming thisdeficiency. Model Driven Security provides methods and tools to tightlyintegrate security into the development process. The key idea is to use high-level, visual models that integrate system design and security design and touse generative techniques to automate the construction of systems from thesedesigns. Furthermore, developers are guided with rules and patterns how touse these tools in the development of secure systems.

Describing systems using models and generating implementations fromthese models is an established practice in software engineering. Most mod-ern CASE-tools support the generation of source code skeletons for differentprogramming languages and database schema definitions from system mod-els. In contrast, models are typically used in security engineering to analyzeand verify the security relevant system properties, but not for automaticallyconstructing security mechanisms for these systems.

By combining models both of the system and the security design we closethe gap between software engineering and security engineering. Using a gen-erative approach to automatically construct system with security architec-tures lowers the barrier to implementing security functionality for generalsoftware engineers, ensures the quality of the implemented security infras-tructure, and increases the productivity of the developers.

We have based Model Driven Security upon Model Driven Architecture(MDA) [34], which is an emerging standard for model-centric and genera-tive software development and is defined by the Object Management Group.MDA is based on standards like the Meta Object Facility [31] for definingmodeling languages and the Unified Modeling Language (UML) [30] as thestandard modeling language in the area of object-oriented software devel-opment. Furthermore, a language for specifying transformation functions iscurrently being standardized [32]. Many development tools implement thesestandards and they can be extended to support Model Driven Security.

As Figure 1.1 suggests, MDA supports a development philosophy where asystem is specified by models at different view points or levels of abstraction.As an example, the figure shows the usage of UML class diagrams and statecharts for formalizing a system design. Models are automatically translatedto other models of the same system by applying model transformation func-tions. For example, a requirement specification can be transformed into aninitial system design model that functions as a starting point for designingthe system in detail. Afterwards, a system implementation for a particularexecution platform can automatically be generated from the system designmodel.

12

A

B

A B

System Model

Target System

Model Transformation

Application Server

Figure 1.1: Model Driven Architecture

All kinds of software development artifacts, including programming lan-guage source code, are considered as models in MDA. Thus generating sys-tem implementations from system design models is an application of modeltransformation. As an example, Figure 1.1 depicts the transformation of thesystem model to a system of distributed components that can be executedin an application server.

In Model Driven Security, security requirements are directly integratedinto design models. Design models are combined with security models, lead-ing to new kinds of models that we call security design models. In thesemodels, security policies refer to the elements of the core system model, e.g.,components, business objects, methods, attributes, etc. In this way, we avoidthe creation of separate and partially redundant security models. This is be-cause most of the information needed to express security properties, e.g. theprotected resources in case of access control or the data to be digitally signed,are already formalized by the design models. Figure 1.2 suggests how thiscan work on the example of access control: here, the design model is givenwith a class diagram enriched with new modeling elements that representsecurity roles and permissions. This combination can be used to define anapplication’s access control policy.

Figure 1.2 also depicts the generative part of Model Driven Security. Weextend existing transformation rules (as part of Model Driven Architecture)in order to automatically generate a policy-conform security infrastructureusing the security mechanisms that are available in the target system plat-form.

13

+ Security ModelSystem Model

A B Customer<<Role>>

<<Permission>>

(e.g. RBAC, assertions)+ Security Infrastructure

Application Server

Target System

Model Transformation+ Extensions

Figure 1.2: Model Driven Security

Rather than fixing one modeling language for Model Driven Security, wepropose a schema for constructing security design languages by combiningexisting security modeling and system design modeling languages. In thisschema, we use models, designated as metamodels, to define and combinedifferent modeling languages in a modular way. Moreover, mathematicaltechniques are used to give security design models a semantics and to pre-cisely define model transformation functions.

In this thesis, we present the application of Model Driven Security tothe development of access control architectures for distributed systems. Wepropose the security modeling language SecureUML, which is based on role-based access control (RBAC) [38], and show its integration into two systemdesign languages based on UML class diagrams and state charts. From mod-els in these languages, we generate systems with access control architecturesfor the technologies Enterprise JavaBeans (EJB) [29], .NET [8], and JavaServlets [20]. Moreover, we propose a development process, which guidesdevelopers during the analysis, design, and implementation of systems withaccess control architectures.

We have implemented a prototype based on the MDA-tool ArcStyler,which we have used to conduct an extensive case study. There we havedesigned and implemented an access control policy for an EJB-based appli-cation. We also used the case study to validate our software developmentprocess and report on experiences.

14

1.1 Contributions

The main contribution of this thesis is to show how Model Driven Archi-tecture can be specialized to Model Driven Security. The aim of this newmethodology for the development of secure systems is to make security an in-tegral part of the overall software development process. We show how the gapbetween software and security engineering can be closed by combining generaldesign and security relevant information in integrated security design models.We also show how to close the gap between security requirements analysisand implementation by automatically generating systems with complete se-curity architectures from security design models. Moreover, we illustrate howthese measures can be integrated into the overall software development pro-cess by adding security-specific development activities to the different stagesof the development process.

The definition of security design languages is at the heart of Model DrivenSecurity. We therefore propose a language schema for building security de-sign languages in a modular way. We show how modeling languages can becombined using metamodels in a way similar to combining software buildingblocks and how this affects the model semantics. In this way, the languageschema allows language designers to exploit existing system as well as securitymodeling languages and their accompanying methods and tools.

The schema strictly separates the abstract and concrete syntax of a mod-eling language, each of them suited for a particular purpose. We show how theabstract syntax of a modeling language can be defined with object-orientedmetamodels and how mathematical techniques can be used to give models aformal semantics. We also show how modeling languages can be equippedwith a graphical concrete syntax on the example of UML notations. Thusour language schema combines the best of both worlds, object-oriented andformal methods.

Although our focus is on security, we believe that our approach has gen-eral applicability and is relevant to research on other software developmentmethodologies. Our work contributes to an understanding of how one cancreate software development methods that combine the advantages of bothobject-oriented and formal methods. With Model Driven Security we showa pragmatic approach for extending modern model-driven development ap-proaches with formal techniques. Both the formal methods community andpractical software engineers can benefit from such an approach. From theformal method perspective this means we show a way how formal methodscan be made available to general software engineers by using them under thehood of development tools or during their development. In that way, prac-tical software engineers can be provided with a new generation of software

15

development tools, which e.g. allow them to automatically analyze, simulate,and optimize software models.

In this thesis, we present the application of Model Driven Security tothe development of access control architectures for distributed systems. Weintroduce SecureUML, which is a security modeling language for definingaccess control policies based on an extended model of role-based access con-trol. As a foundation, we propose a substantial extension to RBAC that iscalled authorization constraints. Such constraints make access control de-cisions dependent on the system state, e.g. date, time or parameter values.Our extension allows one e.g. to realize a concept of object ownership, whichis impossible with standard RBAC (cf. [38]).

We explain in detail how we have developed SecureUML based on thelanguage definition techniques proposed by Model Driven Security. We showhow a modeling language for RBAC can precisely be defined that is bothextensible and semantically well-founded. Furthermore, we illustrate how tointegrate SecureUML into system design languages in order to equip theselanguage with a vocabulary and semantics for access control on the exampleof two different system design languages.

We show that it is possible to automatically generate complete and con-figured access control architectures from SecureUML models for the tech-nologies EJB, .NET and Java Servlets. This also demonstrates the potentialof Model Driven Security for cross-platform development of secure systems.

1.2 Organization

The thesis is organized as follows. In Chapter 2, we will introduce a designproblem that will serve as a running example through the thesis and intro-duce the technologies and standards we base our work upon. Afterwards,in Chapter 3, we will give an overview of Model Driven Security with thefocus on the language schema and model transformation. The security mod-eling language SecureUML will be introduced in Chapter 4 and afterwardsin Chapter 5, we will show how a security design language can be built basedon SecureUML. We will introduce the example system design language Com-ponentUML, which is based on UML class diagrams, and integrate it withSecureUML afterwards.

A key aspect of Model Driven Security is the automatic generation ofsecurity infrastructures. In Chapter 6 we will explain how we extendedthe existing transformation function for creating EJB and .NET systemsfrom ComponentUML models with rules for generating access control infras-tructures. Our extensions are semantically well-founded and we will discuss

16

transformation correctness and demonstrate the usage of formal proofs forverifying the correctness of transformation functions on an example.

In order to demonstrate the general applicability of our approach, we willcreate a second security design language. In Chapter 7, we will introducethe system modeling language ControllerUML, which is based on UML statecharts, and afterwards integrate it with SecureUML. We will also outlinea transformation function that translates ControllerUML models to accesscontrol architectures for Java Servlets.

In Chapter 8, we will describe our prototype tool for Model Driven Secu-rity and introduce our development process for systems with access controlarchitectures. Chapter 9 will discuss the case study we have conducted usingour prototype tool. We will show exemplary parts of the example modeland discuss our experiences afterwards. We will draw our conclusions inChapter 10 along with a discussion of related and future work.

17

18

Chapter 2

Background

We first introduce a design problem along with its security requirements thatwill serve as a running example throughout this thesis. Then we explain theframework we based our development methodology upon: the Model DrivenArchitecture. Afterwards, we introduce the technological foundations of ourwork, which are Role-based Access Control and several security architectures.

2.1 A Design Problem

As a running example, we will consider developing a simplified version ofa system for administrating meetings. The system should maintain a listof users (we will ignore issues such as user administration) and records ofmeetings. A meeting has an owner, a list of participants, a time, and aplace. Users may carry out standard operations on meetings such as creating,reading, editing, and deleting them. A user may also cancel a meeting, whichdeletes the meeting entry and also notifies all participants by email.

As the thesis proceeds, we will see how design models for this system areenriched with the following (here informally given) access control policy:

1. All users of the system can create new meetings and read all meetingentries.

2. Only the owner of a meeting may change meeting data and cancel ordelete the meeting.

3. However, a supervisor can cancel any meeting.

We will later build models for this problem that will be automatically trans-formed into a system architecture for a distributed application along with acomplete access control infrastructure.

19

2.2 Model Driven Architecture

The development of large-scale software systems has always been a challeng-ing task. In addition to its inherent complexity, problems arise due to thedivergence between designs and systems, changing business requirements,and frequent changes in underlying technologies, including execution and de-velopment platforms. The Object Management Group (OMG) has started aninitiative to tackle these problems. The so-called Model Driven Architecture(MDA) is centered around building models and generating software systemsfrom models.

Building models and generating systems has a long history in software de-velopment. In the end, every compiler is a generator that maps a higher-levelrepresentation into a more (mostly platform) specific one. The MDA goes astep further in that it provides an architecture for model driven developmentprocesses and managed system evolution.

MDA enables a development process where a system is defined by modelsat different stages of development (analysis, design, implementation, test-ing, deployment), abstraction levels and views (e.g. structural, behavioral,and security) and where these models are kept consistent with each other.These models are not only used for documentation purposes, but are used togenerate the software system infrastructure for different execution platforms.To achieve this goal there is a demand for modeling languages that are op-timized for particular purposes or domains and strategies for transformingmodels into other models or code and tracking dependencies among models.

Managed system evolution means to actively manage all transitions of asoftware system, including changes in the underlying execution and develop-ment platforms. This imposes two key requirements to a software develop-ment architecture:

1. Execution platform independence: The system models should be asindependent as needed of the execution technology, e.g. Java 2 PlatformEnterprise Edition (J2EE) or Microsoft .NET. This will consequentlyrequire to define system models that comprise all aspects of a system,including business logic, thus enabling the generation of complete andexecutable system infrastructures.

2. Development platform interoperability: It should be possible to createand to manipulate system models using modeling tools of different ven-dors. The same should hold for the generators, which implement thetransformation rules mapping models to (refined) models as well as tocode.

20

Create Meeting Read Meeting Edit Meeting Delete Meeting

User

Cancel Meeting

Figure 2.1: Scheduler Application Use Case Diagram

MDA as being standardized by the OMG (cf. [34]) satisfies these require-ments. MDA uses standards like the Meta Object Facility (MOF) for definingmodeling languages and the Unified Modeling Language (UML) as the stan-dard modeling language in the area of object-oriented software development.UML can be used to specify structural as well as behavioral aspects of asystem. Furthermore, UML is extensible and thus can be the foundation ofdomain specific modeling languages. Transformation rules are currently be-ing standardized within OMG’s Query/View/Transformation (QVT) effort.

In the next sections, we will take a deeper look at UML, MOF, the alter-native approaches for defining custom modeling languages in MDA, and thecurrent status of model transformations within the standardization processof MDA.

2.2.1 The Unified Modeling Language

The Unified Modeling Language (UML) [37] is a widely used graphical lan-guage for modeling object-oriented systems. We based our work on version1.4 of UML.

The language specification differentiates between an abstract syntax anda notation (also called concrete syntax ). The abstract syntax defines thelanguage primitives used to build models and is independent of a notation,whereas the notation defines the graphical presentation of these primitivesas icons, strings, or geometric figures. UML supports the description ofstructural and behavioral aspects of a software system by different modelelement types and corresponding diagram types. In this section, we give anoverview of the UML model elements used through the thesis.

21

Room

floor : int number : int

Person

name : string e-mail : string

Meeting

start : date duration : time

notify() cancel()

1 0..*

+location

1 0..*

1..* 0..*

+participants 1..*

0..*

1 0..*

+owner

1 0..*

Figure 2.2: Scheduler Application Class Diagram

Use Case Diagrams Use case diagrams are used to define the boundariesof a system and to specify its functional requirements. An use case diagramconsist of actors, use cases, and relations between these model elements.An actor represents a class of system users or agents, whereas a use caseformalizes a part of the functionality of the system. Figure 2.1 shows anuse case diagram of our scheduling application. An actor is symbolized by a“stick man” icon and a use case is drawn as an ellipse. In the example, wehave the actor User and use cases describing the activities to create, read,edit, delete, and cancel a meeting. An arrow from an actor to an use casessymbolizes the participation of the actor in the particular use case.

There are further relationships, which are not shown in the figure. Anarrow between two actors depicts a generalization relationship between themand use cases can be in include or extend relations (cf. [30]).

Class Diagrams The structural aspects of systems are defined using classes,each class formalizing a set of objects with common services, properties, re-lationships, and behavior. Services are described by methods, properties byattributes, and relationships are represented by associations. Every class par-ticipating in an association is connected to the association by an associationend, which may also specify the role name of the class and its cardinality inthe association. The behavior of a class can be characterized by other UMLelements such as a state machine that is attached to the class.

Classes are depicted in class diagrams as illustrated by Figure 2.2, whichshows the structure of our scheduling application. The model consist of threeclasses: Meeting, Person, and Room. A Meeting has attributes for storingthe start date and the planned duration. The participants, the owner, andthe location of the meeting are specified using the association ends partic-ipants, owner, and location, respectively. The method notify is used to

22

ListMeetings

EditMeeting

CreateMeeting insert

update

delete / deleteMeeting

cancel / cancelMeeting

edit

create

Figure 2.3: Scheduler Application Statechart

notify the participants of changes to the schedule. The method cancel isused to cancel the meeting, which includes notifying the participants.

State Charts State machines describe the behavior of a system or a classin terms of the states of the system or class and the events that cause atransition between states. A state machine is graphically represented bya statechart diagram. The rectangles and circles represent states and thearrows represent transitions. Transitions may be labeled with the name ofthe triggering event and (separated by a slash) the name of the action thatis executed during state transition.

Figure 2.3 shows the statechart diagram for our scheduling application.In the state ListMeetings, a user can browse the scheduled meetings andcan initiate (e.g., by clicking a button in a graphical user interface) the edit-ing, creation, deletion, and cancellation of meetings. An event of type edit

causes a transition to the state EditMeeting, where the currently selectedmeeting is edited. An event of type create causes a transition to the stateCreateMeeting, where a new meeting is created from data entered by theuser. An event of type delete in state ListMeetings triggers a transitionthat executes the action deleteMeeting, where the currently selected meet-ing is deleted from the database. Similarly, an event of type cancel causesthe execution of cancelMeeting, which calls the method cancel on the se-lected meeting.

Sequence Diagrams Sequence diagrams describe interactions between ob-jects as a sequence of messages. Such diagrams are e.g. used to specify howthe functional requirements given by use cases are realized by a system de-sign. The sequence diagram in Figure 2.4 shows how the cancellation ofa meeting in our scheduling application is handled internally by a meeting

23

user : User : Meeting

cancel( ) notify( )

delete()

Figure 2.4: Example Sequence Diagram

object. Objects are represented by boxes and vertical lines, called lifelines,and messages are displayed as horizontal lines with the name of a method orother message on top of the line.

Object Constraint Language UML also provides a specification lan-guage called the Object Constraint Language (OCL), which is based on first-order logic. OCL expressions are used to formalize invariants for classes,preconditions and postconditions for methods, and guards for enabling tran-sitions in a state machine. As an example, we can add to the class Meetingin Figure 2.2 the following OCL constraint:

context Meeting inv:self . participants−>includes(self.owner)

The constraint defines an invariant of the class Meeting stating that theowner of a meeting must be contained in the set of participants. Each OCLexpression is evaluated in the context of an instance of a specific type andthe reserved symbol self is used to refer to the instance. In our example,self represents an instance of the type Meeting. The attributes, associa-tion ends and methods of an instance can be accessed using “dot-notation”.In our example expression, participants and owner denote the respectiveassociation ends of the meeting.

OCL has some built-in primitive and collection types, e.g. Boolean or Set,whose operations can be accessed using the “arrow” operator. For example,the OCL type Set has the operation includes of type Boolean that tests whetherthe expression passed as parameter holds on at least one element of the set.Thus includes is the OCL form of an existential quantified expression. In our

24

example expression, we check whether the set of persons referenced by theassociation end participants contains the owner of the meeting object.

Extensibility UML can also serve as a foundation for building domainspecific languages. Stereotypes are used to introduce new language primitivesby subtyping core UML types. Model elements are assigned to such typesby labeling them with the corresponding stereotype. Tagged values, whichare pairs of tags and values, represent new properties of model elements.Additional restrictions on the syntax of the domain specific language canbe defined using OCL constraints. Such constraints are designated as well-formedness rules.

A coherent set of stereotypes, tagged value definitions, and well-formednessrules constitutes a UML profile.

2.2.2 The Meta Object Facility

The Meta Object Facility (MOF) [31] is a facility for managing all kinds ofmetadata about software systems. The term metadata refers to data thatdescribe other data. In the context of MDA the MOF is primarily used todefine modeling languages and to built repository infrastructures from suchdefinitions. The most prominent modeling language that has been formalizedusing the MOF is the UML.

We will use the MOF for the same purpose; to define our security modelinglanguage SecureUML and the example system design modeling languages aswell as for integrating SecureUML into these example languages. Our workis based on version 1.4 of the MOF [31].

The MOF uses models for specifying metadata; these models are calledmetamodels. The modeling framework of MOF is essentially a subset of theUML. So metamodels are expressed using familiar object-oriented concepts,like class and inheritance. The elements that constitute a metamodel arecalled metaobjects.

The term metamodel describes a relation between models, i.e. a model m2

can be the metamodel of another model m1. This means that each metaobjectin m2 is a description of a type of objects in m1 and each object in m1 isan instance of a metaobject in m2. In that way, metamodels specify thevocabulary that can be used to define other models. Note that the term metais always relative and refers to a relation between two models or objects, e.g.there could be another model m3 that is the metamodel of m2.

The MOF metadata architecture (cf. [31]) is a reference model for meta-modeling that we will use through this thesis. It introduces the four meta-levels M3 to M0 that can typically be found in a MOF-based environment.

25

Meta level Description Example elements

M3 MOF model MOF Class, MOF AttributeM2 Metamodel, defines a

languageEntity, Attribute

M1 Model, consisting of in-stances of M2 elements

Entities “Meeting” and“Person”

M0 Objects and data Persons “Meier” and“Schmidt”

Table 2.1: The MOF metadata architecture

Attribute

name : string

Entity

name : string

getAttributeByName()

0..* 1

attributes

0..*

entity

1 EntityAttributes

ExampleLanguage <<metamodel>>

Figure 2.5: Modeling Language Definition at the M2 Level

The Table 2.1 gives an overview of the levels; it names the typical purposeof each level and lists example elements.

The objects in the levels M0-M2 are instances of the objects one levelabove. So the model in the higher level is the metamodel of the other modeland thus stipulates the vocabulary used to formalize this model. The MOFmodel in level M3 is self-describing, i.e. it is modeled using its own vocabulary.

The MOF Model The MOF model at level M3 defines the metamodelinglanguage that is used to define the syntax of modeling languages at the M2level. The main concepts of the language are class, association, inheritance,and package. We will explain the language elements that are needed in ourthesis in the following paragraphs.

A MOF Class defines a metaobject at the M2 level, i.e. there are instancesof this class at the M1 level with a state and a behavior. In the context ofmodeling language definition this means that a MOF class specifies a classof model elements that can be instantiated in a system model.

The Figure 2.5 is specified using the UML profile for MOF as definedin [33]. It depicts the definition of the syntax of an example system modelinglanguage at the M2 level. The example illustrates how the two MOF classesEntity and Attribute are specified using UML classes.

26

Meeting

+ start : date + duration : int

<<Entity>> Person

+ name : string + eMail : string

<<Entity>>

Figure 2.6: Example System Model at the M1 Level

The Figure 2.6 shows a system model at the M1 level given in the examplelanguage in a UML-based notation. There we see the two entities Meeting

and Person, denoted by UML classes with the stereotype «Entity». Theseentities are instances of the MOF class Entity. Every attribute owned bysuch a class is automatically considered as a attribute of the entity (MOFclass Attribute), so no further stereotypes are necessary.

A MOF Association formalizes a relation between two MOF classes. Inour example in Figure 2.5, the classes Entity and Attribute are related bythe association EntityAttributes. As a result, the instances of Entity inthe system model at the M1 level may have zero or more attributes as shownin Figure 2.6.

A MOF Attribute defines a named value holder in each instance of itsMOF class. In our example in Figure 2.5, the attribute name of the MOFclass Entity specifies that each entity can have a name. This corresponds tothe names “Meeting” and “Person” of the entities in Figure 2.6.

Each MOF Operation specifies a service of its MOF class. These servicescan be performed on each instance of the MOF class at the model level M1.In our example, there is an operation getAttributeByName that retrieves theattribute of its entity with the given name. MOF operations typically areutility functions used by model transformation functions or modeling tools.Thus such operations are not visible in system models at the M1 level.

A MOF Generalization (not shown in the example figure) can be used tospecify an inheritance relation between MOF classes. If two MOF classes arein a generalization relation then the sub-class derives all attributes, associa-tion ends, and operations applicable to its super-class.

The MOF Package is the MOF Model construct for grouping elementsin a metamodel and it also provides a namespace for naming metamodelelements. The Figure 2.5 shows the package ExampleLanguage, which is thecontainer for the metamodel classes Entity and Attribute1.

MOF packages can be in different relations (cf. [31]). In this thesis, we

1Note that in order to provide a “package” construct at the M1 level one would needto define a MOF class Package in the language description at the M2 level.

27

will use the import relation (not shown in the example figure) that has thefollowing meaning. If a package p1 imports a package p2, then the metaobjectsin p1 may refer to the metaobjects in p2, e.g. as a super-class or an attributetype.

MOF Mappings The MOF also defines mappings from MOF-based meta-models to technologies for metadata management, namely XML and CORBAIDL.

The mapping to XML is designated as XML Metadata Interchange (XMI)and stipulates how models of a particular modeling language are stored inXML documents. Transformation rules specify how MOF-based metamodelsare mapped to document type definitions (DTD’s) or XML Schemata defini-tions. The most well-known application of XMI is the XML schema for UML,which is part of the UML specification. It is the foundation for interchangingUML models among different UML-based CASE-tools.

The mapping from MOF-metamodels to CORBA-IDL-Interfaces definesthe interfaces of a MOF-repository for storing models of the particular lan-guage. An alternative mapping that is promoted by the Java CommunityProcess is the Java Metadata Interface (JMI) [23]. It defines a mappingfrom MOF-based metamodels to Java-Interfaces for MOF-repositories. Be-cause it leverages the capabilities of Java, like reflection, and is seamlesslyintegrated into the programming environment, it is far more convenient thenthe CORBA IDL mapping and thus is enjoying increasing popularity in theindustry.

Benefits of MOF We see the following benefits of using MOF-based meta-models for defining the abstract syntax of modeling languages. To start with,object-oriented metamodels are better suited and more expressive then con-ventional definition techniques, like the Backus-Naur Form (BNF), for defin-ing modeling languages with various relations between the model primitives.Moreover, there is tool support for automatically creating repositories andmaintaining metadata based on MOF, e.g. [5].

2.2.3 Defining Modeling Languages

The definition of modeling languages is at the heart of MDA. The goal isto have modeling languages, which perfectly suit the needs of a particularproblem class or domain. There are several approaches for defining modelinglanguages.

28

Lightweight UML extensions First, it is possible to extend UML throughprofiles. This is supported by most UML-based CASE-tools and by far theeasiest way for defining custom modeling languages. But it also has its limi-tations: Usually, UML profiles are defined using a combination of tables, ex-ample model pictures, textual explanations, and OCL expressions (cf. [30]).This works for simple language, but tends to be difficult to understand andambiguous for more comprehensive languages. Additionally, the type systemfor tags is weak because tagged values are always of type string.

Heavyweight UML extensions As an alternative, MOF can be usedto directly extend the UML metamodel. Metamodels are better suited toprecisely define the syntax of a modeling language. A problem may arise dueto the fact that heavyweight extensions would at best require one to extendthe CASE-tool itself, the repository and the visualization components.

Since this is not an option in most cases, an alternative is to encodethe new language primitives as a UML profile and to build a layer on topof the CASE-tool, which offers the interfaces defined by the metamodel ofthe heavyweight extension. A general drawback of heavyweight UML exten-sions is that the custom language metamodel is based on the whole UMLmetamodel, which is quite complex.

New Modeling Language As a consequence of the disadvantages of theapproaches explained above, a common practice is to define a modeling lan-guage using MOF that focuses on a particular problem or domain withoutany dependency on UML. The resulting language definitions usually have anintuitive domain-specific vocabulary that is much more concise than the vo-cabulary of UML-based languages. Moreover, the interfaces for querying andmanipulating the metadata are simpler than a heavyweight UML interface.

There are different options to define an adequate notation for the newmodeling language. First, it is possible to introduce the language in a UML-based CASE-tool using a UML profile. As the advantage of this approach,such models are interchangeable among CASE-tools. However this kind ofnotation might be suboptimal because it can only use standard UML primi-tives. Second, dedicated modeling tools can be created for the new language.In comparison to the encoding via UML-profile, such a tool may provide abetter notation but it also requires a higher implementation effort.

Combinations of both approaches are possible: In our prototype tool,we use UML for encoding models and, on top of the UML model, we ad-ditionally provide a custom notation for defining access control permissions(cf. Section 8.1.2).

29

2.2.4 Model Transformations

Model transformations are a core concept of MDA and a specification lan-guage for this purpose is currently under development in the context of the“MOF 2.0 Query/Views/Transformations” (QVT) [32] effort. After the stan-dardization of UML, MOF, and XMI, QVT is the last major step in achiev-ing the MDA’s goal of development tool interoperability. Here we give anoverview on the current status of the standardization.

The primary goal of QVT is that specifications of model transformationsshall be interchangeable among MDA-tools. Furthermore, different imple-mentations shall be possible for the same transformation specification, e.g.to allow tool providers to leverage unique features of their MDA environment.

In QVT, transformations are relations between models given in MOF-based languages. The mapping between the models is specified at the levelof the metamodels involved, which is the M2 level. Note that this will requireto extend the MOF Model at the M3 level as introduced in Section 2.2.2.

The specification of transformation functions shall be given as a model ina OMG standard language, e.g. UML or MOF. Based on this specification,it shall be possible to automatically create a model of the target languagefrom a source model.

As mentioned before, the philosophy of MDA is that all artifacts requiredto build a software system are models (in the sense of specifications). Thuseven programming language source code is considered as a special kind ofmodel, where the textual form is just one possible kind of model represen-tation. For example, a metamodel can be given for the Java programminglanguage and there might be a transformation function mapping a UML-based design model to a model in this language. This “abstract Java model”can then automatically be rendered to an equivalent textual representation.

Currently, there are several proposed transformation languages of differ-ent nature. There are declarative as well as imperative languages and hybridlanguages. Because there is currently no approved standard language, we useour own notation in this thesis that is introduced in Section 6.1.

2.3 Role-Based Access Control

Mathematically, access control expresses a relation between a set of Usersand a set of Permissions:

AC ⊆ Users × Permissions .

A user u is granted the permission p if and only if (u, p) ∈ AC . Aside fromthe technical question of how to integrate this relation into systems so that

30

the granting of permissions respects this relation, a major challenge concernshow to effectively represent this information since just enumerating all the(u, p) pairs scales poorly. Moreover, this view is rather “flat” and does notsupport natural abstractions like sets of permissions.

Role-based access control (see [38]), or RBAC, addresses both of theabove limitations. The core idea of RBAC is to introduce a set of rolesand to decompose the relation AC into two relations: user-assignment UAand permission-assignment PA, i.e.,

UA ⊆ Users × Roles , PA ⊆ Roles × Permissions .

The access control relation is then simply the composition of these relations:

AC := PA ◦ UA ,

i.e.,

(u, p) ∈ AC :⇐⇒ ∃ role ∈ Roles :(u, role) ∈ UA ∧ (role, p) ∈ PA .

To further reduce the size of these relations and support additional ab-straction, RBAC also has a notion of hierarchy on roles. Mathematically,this is a partial order ≥ on the set of roles, with the meaning that largerroles inherit permissions from all smaller roles. Formally, this means thatthe access control relation is now given by the equation

AC := PA ◦ ≥ ◦ UA ,

To express the same access control relation without a role hierarchy, one must,for example, put each user in additional roles, i.e., a user is then not just inhis original roles, but also in all smaller roles. Alternatively, one can giveroles additional permissions, i.e., a role not only has its assigned permissions,but also all permissions of smaller roles. The introduction of a hierarchy, likethe decomposition of relations, leads to a more expressive formalism in thesense that one can express access control relations more concisely.

Apart from addressing the problem of scalability mentioned above, RBACalso improves the usability of the access control configuration and its admin-istration in that roles provide a convenient and intuitive abstraction thatcorresponds closely to the actual organizational structure of companies.

We have chosen RBAC as the foundation of our security modeling lan-guage because it is well-established and supported by many existing technol-ogy platforms, which is a prerequisite for the model-driven and generativeconstruction of secure systems. However, RBAC also has limitations. For

31

example, it is difficult to formalize access control policies that depend on dy-namic aspects of the system, like the date or the values of system or methodparameters. Furthermore, although many technologies support RBAC, theydiffer in details, like the degree of support for role-hierarchies and the types ofprotected resources. As we will see in later sections, our approach of generat-ing architectures from models provides a means to overcome such limitationsand differences in technologies.

2.4 Security Architectures

We use three different security architectures as examples of target platformsin this thesis. We survey them here, focusing on their access control aspects.

2.4.1 Enterprise JavaBeans

Enterprise JavaBeans (EJBs) is a component architecture standard [29] forthe development of server-side components in Java. These components usu-ally form the“business logic”of multi-tier applications and run on applicationservers. Our work is based on version 2.0 of the EJB specification [40].

The standard specifies an infrastructure for system-level aspects such astransactions, persistence, and security and defines an execution environmentfor three types of EJB components, which are entity, session, and messagedriven beans. In this work, we will focus on entity beans. These are persistentand transactional components that are typically used to represent entities ofthe application domain.

The core of an EJB entity component is the bean class, which contains thebusiness logic of the component. An entity component may have up to fourinterfaces; these interfaces can be categorized along two dimensions. First,there are home and component interfaces. Home interfaces are e.g. used forcreating and finding bean instances whereas component interfaces define themethods applicable to the component instances. Second, such an interfacecan either be a remote or a local interface. Remote interfaces can be accessedfrom outside the application server process, whereas local interfaces are onlyaccessible within the Java virtual machine where the component resides.

EJB employs a declarative programming model. This means that severalaspects of an EJB application are declared by properties, which are managedby the application server. This configuration information is stored in deploy-ment descriptors, which are XML documents that are installed together withthe components. There are different types of deployment descriptors. First,the EJB standard specifies the schema (cf. [42]) of a standard descriptor file

32

“ejb-jar.xml” that is mandatory for every EJB application. Additionally, ap-plication server vendors may allow developers to configure product specificfeatures in vendor-specific deployment descriptors. The transformation rulesgiven in this thesis only produce standard descriptor code. Thus we will focusthe explanation on this kind of descriptors. The following shows fragmentsof an example descriptor.

<ejb-jar><enterprise-beans><entity><ejb-name>Meeting</ejb-name><local-home>scheduler.MeetingHome</local-home><local>scheduler.MeetingLocal</local><ejb-class>scheduler.MeetingBean</ejb-class><persistence-type>Container</persistence-type>...

</entity></enterprise-beans><assembly-descriptor>...</assembly-descriptor>

</ejb-jar>

The descriptor is split into two section by the top-level elements enterprise-

beans and assembly-descriptor. The sub-elements of enterprise-beans define thecomponents of the EJB application and the sub-elements of assembly-descriptor

specify, among other things, the security properties of the application.

The example descriptor shows the (partial) definition of an entity com-ponent by an element of type entity. The name of the bean type is specifiedby the element ejb-name and the component interfaces (remote home, remotecomponent, local home, and local component) and the bean class are gen-erally identified using elements of type home, remote, local-home, local, andejb-class, respectively. Note that an entity component must have at least onepair of either remote or local home and component interfaces. In our example,the entity bean Meeting is composed of the bean class MeetingBean and thelocal interfaces MeetingHome and MeetingLocal. The element persistence-type

is set to Container meaning that the EJB container is responsible for storingthe state of the entity bean instances in a database.

Access Control The access control model of EJB is based on RBAC,where the protected resources are the methods accessible using the inter-faces of an EJB. There are two complementary access control mechanisms,designated as declarative and programmatic access control.

Declarative access control means that the access control policy is con-

33

figured in the deployment descriptors of an EJB application. The securitysubsystem of the EJB application server is then responsible for enforcing thispolicy on behalf of the components.

The security roles of an EJB application are specified using security-role

elements in the assembly-descriptor section of an deployment descriptor. Thefollowing example shows the definition of the two roles Supervisor and User.

<security-role><role-name>Supervisor</role-name>

</security-role><security-role><role-name>User</role-name>

</security-role>

These roles can then be used to specify access control permissions. Thefollowing example shows the definition of a permission that authorizes therole Supervisor to execute the method cancel of the component Meeting.

<method-permission><role-name>Supervisor</role-name><method><ejb-name>Meeting</ejb-name><method-intf>Local</method-intf><method-name>cancel</method-name><method-params/>

</method></method-permission>

As this example illustrates, permissions are defined at the level of individualmethods. A method-permission element lists one or more roles using elementsof type role-name and one or more EJB methods using elements of type method.The listed roles are granted the right to execute the listed methods.

In general, for realistic applications the information needed to specifya comprehensive access control policy is quite voluminous and there is thedanger that developers introduce errors due to oversights or shortcuts taken.For example, suppose a high-level security policy states that a role is grantedthe permission to read the state of a particular component. At the im-plementation level, this requires granting the role access to all read meth-ods of the attributes and associations of the component, i.e., defining onemethod-permission element containing one method element for each of theseread methods. To save time, a developer might just define one method per-mission granting the role full access to all methods of the EJB2, which wouldbe too liberal. As we indicate later, modeling security policies at a high ab-straction level and automatically generating the corresponding deploymentdescriptors provides a promising solution to this problem.

2This can be achieved using the wild-card ”*”as the method-name.

34

In addition to the declarative mechanisms, programmatic access controloffers the possibility of implementing access control decisions within the busi-ness logic of components. This mechanism is based on inserting appropriateJava assertions in the methods of the bean class. To support this, EJB pro-vides interfaces for retrieving the security relevant data of a caller, like hisname or roles. The following shows an assertion that authorizes the role Userto execute the method cancel of the component Meeting only if the calleris the owner of particular the meeting instance.

public void cancel(){if (ctx.isCallerInRole("User") &&

!ctx.getCallerPrincipal().getName().equals(getOwner().getName())throw AuthorizationException("not the owner");...

}

2.4.2 Enterprise Services for .NET

The Microsoft Enterprise Services for .NET support the execution of server-side components based on the .NET platform by providing services such asdistributed transactions, life-cycle management, and security.

The Enterprise Services support declarative and programmatic accesscontrol [8]. Here, programmatic access control allows one to obtain theidentity of the caller of a method and to check its role assignments. Thedeclarative mechanism supports the configuration of access control restric-tions at the level of applications, components, interfaces, and methods. Toachieve this, .NET attributes are added to the source code of a component,an interface, or to the assembly descriptor of an application. The follow-ing C# code fragment grants the role Supervisor the right to execute themethod cancel().

[SecurityRole("Supervisor")]public void cancel(){...}

2.4.3 Java Servlets

The Java Servlets Standard [20] defines an execution environment for webcomponents implemented in Java. These components are called servlets andtheir execution environment is designated as servlet container. A servlet isessentially a Java class that processes HTTP requests and creates HTTPresponses. Servlets can be used to dynamically create HTML pages or to

35

control the processing of requests in web applications. Our work is based onversion 2.3 of the Java Servlet specification [41].

One or more servlets form a web application whose properties, similar tothe approach in EJB (cf. Section 2.4.1), are declared in a XML deploymentdescriptor (cf. [43]). The following shows an example of such a deploymentdescriptor.

<web-app><servlet><servlet-name>scheduler</servlet-name><servlet-class>SchedulingControllerImpl</servlet-class>

</servlet><servlet-mapping><servlet-name>scheduler</servlet-name><url-pattern>/scheduler</url-pattern>

</servlet-mapping></web-app>

The servlet element defines a servlet component. The definition namesthe servlet and identifies its Java class. The element of type servlet-mapping

defines a uniform resource locator (URL) that is used to address the servletin HTTP requests.

Access Control A servlet environment supports declarative and program-matic access control. The security roles of a web application are specified us-ing security-role elements in the deployment descriptor. The following exampleshows the definition of the role User.

<security-role><role-name>user</role-name>

</security-role>

Declarative access control permissions are defined at the level of URLsusing security-constraint elements. The following security constraint authorizesthe role User to send HTTP requests to the URL “/scheduler”.

<security-constraint><web-resource-collection><web-resource-name>application</web-resource-name><url-pattern>/scheduler</url-pattern>...

</web-resource-collection><auth-constraint><role-name>User</role-name>

</auth-constraint></security-constraint>

Programmatic access control can be used to determine the identity andthe roles of a caller and to implement decisions within a servlet.

36

Chapter 3

Model Driven Security: anOverview

Model Driven Security aims to close two gaps: the gap between software andsecurity engineering and the gap between design and implementation of se-cure applications. We use a model-centric and generative approach foundedon the concepts of MDA to achieve this goal. The key idea is to model secu-rity requirements as an integral part of system models and to automaticallygenerate systems with complete security architectures from the models.

This approach yields a new kind of models, which we call security designmodels and requires corresponding security design modeling languages. Sucha modeling language is capable of defining the system’s functionality as wellas security requirements for one or more security aspects, like access controlor digital signatures.

The development of security design modeling languages is a critical suc-cess factor of Model Driven Security but it poses the following problem:There are several different security aspects that might be of interest for aparticular class of applications. And, as we illustrated in Section 2.2, thecommon approach in MDA is to use custom modeling languages, developedto suit the needs of a particular problem class.

Thus it is not feasible in our opinion to develop a single “universal” se-curity design language comprising all of these languages. Furthermore, thedevelopment of a security design language is a time-consuming task, whichalso requires an extensive knowledge of the problem domain as well as theparticular security mechanism.

We therefore propose a schema for constructing security design modelinglanguages in a modular way. The schema, as shown in Figure 3.1, has threeparts:

37

text

Security Design Language

RBAC

Digital Signatures

Privacy

Class diagrams

Statecharts

Sequence diagrams

Security Modeling Language

System Design Modeling Language

Extension Points

Dialect Modeling Language based on RBAC + class diagrams

Figure 3.1: Security Design Language Schema

1. a system design modeling language for constructing system models (e.g.,components with their business methods, attributes, and associationsto other components),

2. a security modeling language for expressing security policies (e.g., accesscontrol policies), and

3. an integration model which “glues” both languages together. We callsuch an integration model a dialect of the security modeling language.

Our schema requires a security modeling language to be extensible, i.e.such a language must have extension points and a method for integrating itwith system modeling languages. Thus the nature of a dialect depends onthe integration concept of the particular security modeling language.

For example, in the case of SecureUML, elements of the system designmodeling language are formalized as being protected resources of SecureUMLby deriving them from a SecureUML base class. Subclassing is just an exam-ple of an integration technique, other techniques like composition, templates,or language design patterns are possible, too.

The language construction schema defines a family of security design lan-guages. By different instantiations of the three parameters, we can builddifferent languages, tailored for expressing different kinds of designs and se-curity policies.

To automate our approach to Model Driven Security, for each schemainstance we must define, as depicted in Figure 1.2, transformation functionsmapping models (in the security design language) to security infrastructures.

38

As we will show in this thesis, we do this by extending the transformationfunctions accompanying the system design modeling language of the partic-ular language schema instance.

The remainder of this chapter is organized as follows. First, we describethe techniques we use for defining modeling languages. Second, we discussthe general concept of security modeling language dialects and give examples.Afterwards, we discuss model transformation in the context of Model DrivenSecurity in more detail. We conclude the chapter by giving an outlook of theparticular modeling languages and transformation functions we will presentin this thesis.

3.1 Language Definition Techniques

We based our language definition techniques upon the third approach givenin Section 2.2.3, where MOF is used to define new modeling languages.

We use MOF-based metamodels to define the abstract syntax of the lan-guages and a UML-based concrete syntax, i.e. the concrete syntax is given asa UML profile. Security design models are generally stored in their UML rep-resentation and are transformed into abstract syntax prior further processing(e.g., analysis or model transformation).

It is possible to complement the UML-based concrete syntax by a customnotation. For example, we have defined a matrix-based notation for definingaccess control permissions. Note that a custom notation is just an alterna-tive view of a security design model. Thus the information specified in thisnotation is also stored in the UML representation of the model.

3.1.1 MOF-Mapping to Relational Models

We complement the MOF framework (cf. Section 2.2.2) with a mapping frommodels in abstract syntax (M1 level) to corresponding relational models (sortsand relations). The rules are specified in terms of the MOF model (M3 level)and the MOF metadata architecture as follows.

• A model m (M1 level) given in the language l is translated to a n-tuple

ml := (c1, . . . , cn) ,

where each component of ml is a sort or relation created from the MOFclasses, associations or attributes in the metamodel of l (M2 level).

• A MOF Class in the language definition (M2 level) is mapped to a sortwith one entry for each instance of this class in the model m (M1 level).

39

As an example, we consider the example language and model given inSection 2.2.2. The metamodel in Figure 2.5 defines the MOF classesEntity and Attribute. The corresponding model in Figure 2.6 given inthis language is translated to

Entity := {Meeting ,Person} ,

Attribute := {start , duration, name, eMail} .

• Each MOF association is translated to a relation with one entry foreach link in the association. As a convention, the name of the relationis built from the capital letters of the association’s name.

To give an example, the metamodel in Figure 2.5 defines the associa-tion EntityAttributes and the model in Figure 2.6 contains four links inthis association, which results in the following definition of the corre-sponding relation EA ⊆ Entity × Attribute

EA := {(Meeting , start), (Meeting , duration),

(Person, name), (Person, eMail)} .

Optionally, a function may be defined for each association end. Thename of the function is built from association end’s name prefixed bythe class name. In our example, the function

entityAttributes : Entity 7→ 2Attribute

would correspond to the association end attributes of Entity.

• As explained in Section 2.2.2, a MOF Attribute defines a named valueholder in each instance of its MOF class. Thus each MOF attribute ismapped to a relation with one entry for each class instance. The nameof the relation is built from the first letters of both the name of theclass and the name of the attribute, transformed to upper cases.

As an example, the relation EN ⊆ Entity × String corresponds to theattribute name of the MOF class Entity and is

EN := {(Meeting , ‘Meeting’), (Person, ‘Person’)} .

Optionally, a function may by defined for each attribute in a way similarto the mapping rule for association ends. In our example, we wouldcreate the function

entityName : Entity 7→ String .

40

• The inheritance relation between two MOF Classes is mapped to asubset relation between the sorts corresponding to this classes.

• It is possible to introduce further predicates, functions and relations(e.g. order relations determined by the composition of other relations).

The relational models created by this mapping rules serve the followingpurposes: They can be the foundation for giving modeling languages a formalsemantics and they provide a precise language to specify transformation rules.

3.1.2 The Role of Semantics in Model Driven Security

In this thesis, the semantics of security design models serves two purposes.First, it explains what specifications mean, e.g., when access is granted toprotected resources. Second, it guides our translations and provides a basiswith which we can prove their correctness.

The techniques used to give a modeling language a formal semanticsstrongly depend on the nature of the modeling language itself as well ason the purpose of the semantics. Basically, the relational model as intro-duced above can be used for giving models a semantics but our schema isopen to other techniques as well.

We will outline the approach on the example of the modeling languageSecureUML that we will introduce in Section 4. SecureUML extends RBACin a way that access control decisions depend on the system state. Therefore,giving a semantics for access control requires us to consider particular systemstates (MOF M0 level).

The semantics is therefore given in two steps. Without authorization con-straints, the semantics of access control is given as a predicate over the setsand relations of the relational model. With authorization constraints, thesystem state (M0 level) is represented in a first-order structure and accesscontrol is formalized as a satisfiability problem for formulae over this struc-ture. These access control formulae are built from the information in therelational model.

3.2 Combining Modeling Languages

To make a system design modeling language “security aware”, we combineit with a security modeling language by merging the vocabularies of thetwo languages at the levels of concrete and abstract syntax. But usuallymore is required: it must be possible to build expressions in the combinedlanguage that combine subexpressions from the different languages. That is,

41

security policies expressed in the security modeling language must be able tomake statements about system resources or attributes specified in the designmodeling language. And such expressions shall have a formal semantics. Itis the role of the dialect to make the connection between the languages andto give combined expressions a formal semantics.

In our opinion, there is no universal approach for integrating a securityand a system design modeling language. The particular approach taken de-pends on the nature of the security mechanism and how it relates to theinformation in system design models. An important criteria is the strengthof the coupling between security and system design information. For exam-ple, in the case of access control, there is a strong coupling between primitivesof both languages. The integration approach taken must reflect this and tech-niques like subclassing, templates, or language design patterns might thenbe appropriated. Otherwise, if the coupling is weaker, simply composing asecurity design languages from the original languages might suffice.

These ideas are best understood on examples. We therefore outline in-tegration strategies for two security mechanisms: access control and digitalsignatures.

Access Control The security modeling language SecureUML provides alanguage for specifying access control policies for actions on protected re-sources. However, it leaves open what the protected resources are and whichactions they offer to clients. This depends on the primitives for constructingmodels in the system design modeling language.

For example, in a component-oriented modeling language, the resourcesmight be methods that can be executed. Alternatively, in a process-orientedlanguage, the resources might be processes with actions reflecting the abilityto activate, deactivate, terminate, or resume the processes. Or, if we aremodeling file systems, the protected resources might correspond to files thatcan be read, written, or executed.

The dialect specifies how the modeling primitives of SecureUML are in-tegrated with the primitives of the design modeling language in a way thatallows the direct annotation of model elements representing protected re-sources with access control information.

A SecureUML dialect is primarily formalized in a metamodel. In thefirst step, the MOF classes of the system modeling language that representprotected resources are derived from a SecureUML base class. Then foreach class of protected resources, the set of actions they offer to clients aredefined along with a definition of the hierarchies on actions. The integrationof the concrete syntax of both languages is straightforward and is defined in

42

a subsequent step. A detailed definition of SecureUML and its integrationapproach is given in Chapter 4.

Digital Signatures In the second example, we want to demonstrate thegenerality of our approach by outlining another security modeling language,which supports the model-driven development of applications that use dig-ital signatures. We start with a short survey of why and how this securitymechanism is usually used in applications. Afterwards, we outline the designand integration method of the security design language.

Digital signatures are typically used to ensure the integrity of impor-tant data or to implement a digital contract management (non-repudiation).Characteristic activities that can be found in applications with digital sig-natures are (1) the preparation of data to be signed, (2) the signing of thisdata, and (3) the validation of signature documents.

While the meaning of the second and third type of activities is obvious,the first activity type might demand further explanations. Such an activitycollects data from the system and transforms this data into a format that isappropriate as input to the signing activity. The concrete format dependson the type of actor that shall sign the data. For example if an human shallsign a contract then a human readable representation like PDF is required.

The ways in which digital signatures on one hand and access control on theother hand are used in applications differ very much. In case of access control,we speak about protecting system resources from unauthorized access. Soaccess control is a horizontal service affecting all externally accessible systemresources. In contrast, the creation and management of digital signatures isexplicitly integrated into an application. Thus from the software engineeringstandpoint the usage of digital signatures is just another functional buildingblock with well-defined dependencies to other parts of the system. So we needa completely different kind of security modeling language and integrationconcept than in the case of access control.

Let us assume a security modeling language that distinguishes the threeactivity types prepareDocument, signDocument, and validateSignature. Togetherthese activity types are the building blocks of an abstract signing processthat may be integrated into system modeling languages.

The abstract syntax of the modeling languages is specified in a MOF-based metamodel and the concrete syntax is based upon UML state ma-chines. The activities are specified as UML elements of type Action (cf. [30]).Such actions represent executable statements and are performed in states orduring state transitions. For each type of activity, we define a correspondingstereotype.

43

The integration of the new security modeling language into a system de-sign language works as follows. The possibility to separate activities formanaging and creating digital signatures and other activities in an appli-cation makes the integration of our new security modeling language into asystem design language much easier than the integration method for accesscontrol. The only prerequisite is that the particular system design languagemust support UML state machines for formalizing the behavior of an appli-cation. It then suffices to include the vocabulary of our security modelinglanguage into the system design language. So in this example, compositionis used as technique for building a dialect.

3.3 Model Transformation

Given a language that is an instance of the schema in Figure 3.1, we mustdefine a transformation function operating on models constructed in the lan-guage. As our focus in this thesis is on security, we shall assume that theparticular system design modeling language is already equipped with a trans-formation function that can generate code fragments and system infrastruc-ture from models (see the discussion on this issue in Section 2.2).

Our task then is to define how the additional modeling constructs fromthe security modeling language are translated into system constructs. Ouraim here is not to generate or develop new kinds of security architectures, butrather to capitalize on the existing security mechanisms of a given componentarchitecture and to automatically generate appropriate instances of thesemechanisms. Of course, for this to be successful, the modeling constructs inthe security modeling language should be designed with an eye open to theclass of architectures and security mechanisms that will later be part of thetarget platforms.

We require that a transformation function is correct with respect to thesemantics of the security modeling language, i.e., the transformation functionmust be semantic preserving. To judge the correctness thus also requiresa formal semantics for the targeted security architectures. Unfortunately,most such architectures are not formally specified, so a rigorous correctnessproof will also involve formalizing their behavior. This would require notonly to give a formal semantics of access control of the technologies EJB,Java Servlet, and .NET, but also an execution semantics of the underlyingprogramming languages Java and C#.

This falls outside the scope of this thesis. Instead, we will discuss thecorrectness of the transformation function for EJB based on a simplifiedmodel of the EJB platform in Section 6.3. Additionally, we will give a proof

44

for the declarative part of the transformation function for EJB in Section 6.4.As a foundation of this proof, we propose a formal model of EJB declarativeaccess control.

3.4 Outlook

As this thesis proceeds, we will focus on the security mechanism of accesscontrol. We will introduce the security modeling language SecureUML, itsapplication in the context of different system modeling languages, and thegeneration of access control infrastructures for different platforms from thesecurity design models.

We will present SecureUML and its integration approach in detail inChapter 4. In Chapter 5, we will introduce the system design modeling lan-guage ComponentUML and we will show how we combine the language withSecureUML to evolve ComponentUML to a security design language. Wewill give examples of transformation functions that translate models definedwith ComponentUML into secure, executable systems for the componentplatforms EJB (Section 6.2) and .NET (Section 6.5).

In order to demonstrate the generality of our approach, we will introducea second system design language, namely ControllerUML, and show how weintegrate SecureUML into this language. Afterwards, we outline a trans-formation function that translates models given using ControllerUML intosecure web applications based on the Java Servlet standard (Section 7.4).

45

46

Chapter 4

SecureUML

We now define the security modeling language SecureUML in detail. First,we give the abstract syntax of the language with a MOF-based metamodel.Afterwards, we define the concrete syntax as a UML profile and stipulatethe subset of OCL that serves as expression language for specifying autho-rization constraints. In Section 4.3, we define the steps required to integrateSecureUML into a system modeling language and discuss the structure andthe different views of a security design model. We conclude this chapter bypresenting the semantics of SecureUML.

4.1 Abstract Syntax

Figure 4.1 presents the metamodel that defines the abstract syntax of Se-cureUML. The language is based on RBAC, which we extend in several di-rections: Observe that the left-hand side of the diagram essentially formalizesRBAC (cf. Section 2.3), where we extend the concept of users by groups andformalize the assignment of users or groups to roles by using their commonsupertype Subject. The right-hand side of the diagram factors permissionsinto the ability to carry out actions on resources. These permissions maybe constrained to hold only in certain system states by authorization con-straints. Additionally, we introduce hierarchies not only on roles (which isstandard for RBAC), but also on resources and actions.

Let us now examine these types and associations in more detail. Subject isthe base type of all users and groups in a system. A User represents a systementity, like a person or a process, whereas a Group names a set of users andgroups. Subjects are assigned to groups by the aggregation SubjectGroup,which represents an ordering relation over subjects. Subjects are assigned toroles by the association SubjectAssignment.

47

AtomicAction

User Group

Subject

*

*

*

*

SubjectGroup

AuthorizationConstraint

Role

* *

*

RoleHierarchy

*

*

*

*

* SubjectAssignment

CompositeAction

Resource

0..1 * 0..1

ResourceDerivation

*

Permission

0..1

*

0..1

*

ConstraintAssignment

1..* * 1..* *

PermissionAssignment Action

*

*

*

*

ActionHierarchy

* 1 * 1 ResourceAction

* 1..* * 1..*

ActionAssignment

* 0..1 *

ActionDerivation

0..1

+subs

resource actions

Figure 4.1: SecureUML Metamodel

A Role represents a job and bundles all privileges needed to carry outthe job. A Permission grants roles access to one or more actions, where theactions are assigned by the association ActionAssignment and the entitled rolesare denoted by the association PermissionAssignment. Due to the cardinalityconstraints on these associations, a permission must be assigned to at leastone role and action. Roles can be ordered hierarchically, which is denoted bythe aggregation RoleHierarchy, with the intuition that the role at the part endof the association inherits all privileges of the aggregate.

An AuthorizationConstraint is a logical predicate that is attached to a per-mission by the association ConstraintAssignment and makes the permission’svalidity a function of the system state, e.g., dependent on the current timeor attribute values. Consider a policy stating that an employee is allowed towithdraw money from a company account as long as the amount is less than5.000 d. Such a policy could be formalized by giving a permission to a roleEmployee for the method withdraw, restricted by an authorization constrainton the parameter amount of this method. Such constraints are given by OCLexpressions, where the system model determines the vocabulary (classes andmethods) that can be used, extended by the additional symbol caller, whichrepresents the name of the user on whose behalf an action is performed.

Resource is the base class of all model elements in the system modelinglanguage that represent protected resources. The possible operations on theseresources are represented by the class Action. Each resource offers one or moreactions and each action belongs to exactly one resource, which is denoted bythe composite aggregation ResourceAction.

We differentiate between two categories of actions formalized by the actionsubtypes AtomicAction and CompositeAction. Atomic actions are low-level ac-tions that can be directly mapped to actions of the target platform, e.g. the

48

action execute of a method. In contrast, composite actions are high-levelactions that may not have direct counterparts on the target platform. Com-posite actions, ordered in an ActionHierarchy, are used to group actions.

As we will see, the semantics of a permission defined on a composite actionis that the right to perform the action implies the right to perform all ofthe (transitively) contained subactions. This semantics yields a simple basisfor defining high-level actions. Suppose a security policy grants a role thepermission to “read” an entity. Using an action hierarchy, we can formalizethis by stating that such a permission includes the permission to read thevalue of every entity attribute and to execute every side-effect free methodof the entity. Another reason for introducing action hierarchies is that theysimplify the development of generation rules since it is sufficient to definethese rules only for the atomic actions.

Inheritance plays a central role in object-oriented modeling languages. Iftwo types are in an inheritance relationship then a subset of the features ofthe supertype, e.g. its methods, are derived along this relationship and areaccessible within the context of the subtype. Types and features are resourcesin SecureUML and we must clarify how permissions on actions are derivedalong inheritance hierarchies.

The aggregations ResourceDerivation and ActionDerivation provide the foun-dation to support the derivation of permissions along inheritance hierarchies.The aggregation ResourceDerivation represents the derivation relation betweenresources. Since inheritance is handled differently by the various systemmodeling languages, it is the responsibility of a SecureUML dialect to de-fine which subresources are derived when two resources are in an inheritancerelationship. The aggregation ActionDerivation is determined based on the as-sociation ResourceDerivation. An action is derived from another action if theirowning resources are in a derivation relation and both actions have the samename. As we will see in Section 4.4, the semantics of SecureUML states thata permission for an action also implies the permission for all derived actions.

Together the types Resource and Action formalize a generic resource modelthat serves as a foundation for integrating SecureUML into different systemmodeling languages. The concrete resource types, their actions, the actionhierarchy and the rules for deriving resources along an inheritance hierarchyare defined as part of a SecureUML dialect (cf. Section 4.3).

4.2 Concrete Syntax

SecureUML expressions are given in a UML-based concrete syntax. For thispurpose, we define a UML profile that formalizes the modeling notation of

49

UML metamodel type and stereotype SecureUML metamodeltype

Class «User» User

Class «Group» Group

Dependency «SubjectGroup» SubjectGroup

Dependency «SubjectAssignment» SubjectAssignment

Class «Role» Role

Generalization — RoleHierarchy

AssociationClass «Permission» Permission, PermissionAs-

signment, ActionAssignment,AuthorizationConstraint,and ConstraintAssignment

Table 4.1: Mapping between SecureUML concrete and abstract syntax

SecureUML using stereotypes and tagged values. In this section, we willintroduce the modeling notation and explain how models in concrete syntaxare transformed into abstract syntax.

Table 4.1 gives an overview of the mapping between elements of the Se-cureUML metamodel and UML types. Note that a permission, its associ-ations to other elements, and its optional authorization constraint are rep-resented by a single UML association class. Also note that the profile doesnot define an encoding for all SecureUML elements: The notation for defin-ing resources is stipulated by the particular system modeling language. Itis therefore left open and must be defined as part of the integration of Se-cureUML with the particular system modeling language. Some informationis automatically determined based on rules of the integration model (Action

and its subtypes, ResourceAction, ActionHierarchy, ResourceDerivation, and Ac-

tionDerivation); and no representation for subjects is given because Subject isan abstract type.

We now illustrate the concrete syntax and the mapping to abstract syn-tax with an example model of roles and users, given in Figure 4.2, whichformalizes the first part of the security policy introduced in Section 2.1. Thisexample will allow us to explain some of the fine points of our concrete syntaxin detail. It will also serve as the basis for defining access control policies forour running example.

In the SecureUML profile, a role is represented by a UML class withthe stereotype «Role» and an inheritance relationship between two roles isdefined by a UML generalization relationship. The role referenced by thearrowhead of the generalization relation is considered the super-roles of the

50

Supervisor <<Role>>

UserMeeting

<<EntityAction>> Meeting : read

Bob <<User>>

Alice <<User>>

self.participants->exists(p|caller=p.name)

<<SubjectAssignment>>

User <<Role>> <<SubjectAssignment>>

Meeting

start : date duration : time

notify() cancel()

<<Entity>>

<<Permission>>

Person

+ name : string + eMail : string

<<Entity>>

0..*

1..*

0..*

participants 1..*

0..*

1

0..*

owner 1

Figure 4.2: Example of the concrete syntax of SecureUML

role referenced by the tail of the arrow, and the subrole inherits all accessrights of the super-roles. In our example, we define the two roles User andSupervisor. Moreover, we define Supervisor as a subrole of User.

Users are defined as UML classes with the stereotype «User» and groupsare UML classes with the stereotype «Group». The assignment of a subject toa role is defined as a dependency with the stereotype «SubjectAssignment»,where the role is associated with the arrowhead of the dependency. Themembership of a subject in a group is defined as a dependency with thestereotype «SubjectGroup». The group is referenced by the arrowhead ofthe dependency. In our example, we define the users Alice and Bob, andformalize that Alice is assigned to the role Supervisor, whereas Bob hasthe role User.

Note that the modelling of users, groups, and their role assignments isused for analysis or test purposes only. We generally recommend using ad-ministration tools provided by the target platform for managing this kind ofdata. We discuss this topic in detail in Section 8.2.

The right-hand side of Figure 4.2 specifies a permission on a protectedresource. Specifying this is only possible after we have combined SecureUMLwith an appropriate system modeling language. The concrete syntax of Se-cureUML is generic in that every UML model element type can represent aprotected resource. Examples are classes, attributes, and methods, as well asstate machines and states. A SecureUML dialect specializes the base syntaxby stipulating which elements of the system design language represent pro-

51

tected resource and defines the mapping between the UML representation ofthese elements and the resource types in the abstract syntax of the securitydesign language. We base our example on the system modeling languageintroduced in Section 2.2.2 and fix that UML classes with the stereotype«Entity» are protected resources possessing the action read, i.e., the classesMeeting and Person are protected resources.

A permission, along with its relations to roles (PermissionAssignment) andactions (ActionAssignment), is defined in a single UML model element, namelyan association class with the stereotype «Permission». We have chosen thisrepresentation as it is concise and it always satisfies the cardinality con-straints on permissions, since an association class will be deleted when oneof the referenced classes is removed from the model.

Such an association class connects a role with a UML class representinga protected resource, which is designated as the model anchor of the permis-sion. The actions such a permission refers to may be actions on the modelanchor or on subresources of the model anchor. In our example, the classMeeting is the model anchor of the permission UserMeeting granted to therole User. Each attribute of the association class represents the assignmentof an action to the permission (ActionAssignment), where the action is iden-tified by the name of its resource and the action name. The action nameis given as the attribute’s type, e.g. “read”. The resource name is stored inthe tagged value identifier and references the root resource or one of its sub-resources. The format of the identifier depends on the type of the referencedresource and is determined by the stereotype of the attribute. In our ex-ample, the attribute of type “read” with the stereotype «EntityAction» andthe identifier “Meeting” denotes the action read on the class Meeting. Thestereotypes for action references and the naming conventions for identifiersare defined as part of the dialect.

We use a subset of the OCL syntax for formalizing authorization con-straints. The following grammar1 has been derived from the OCL grammarproposed in [17].

expression = relational expression expression tail*

expression tail = logical operator relational expression

logical operator = ‘and’ | ‘or’relational expression = postfix expression relational expression tail?

relational expression tail = relational operator postfix expression

relational operator = ‘<>’ | ‘=’ | ‘<’ | ‘>’ | ‘<=’ | ‘>=’1Note that the grammar definition uses the two reserved symbols “?” or “*” to mark

optional production rules and rules that can be applied arbitrarily often, respectively.

52

postfix expression = ‘not’? primary expression postfix expression tail*

primary expression = literal | name | ‘(’ expression ‘)’

postfix expression tail = ‘.’ | ‘->’ feature call

feature call = name feature call parameters?

feature call parameters = ‘(’ declarator? actual parameter list? ‘)’

actual parameter list = expression actual parameter list tail*

actual parameter list tail = ‘,’ expression

declarator = name ‘|’

The definitions of “name” and “literal” are straightforward and can be foundin [17].

The authorization constraint expression language supports the OCL typesBoolean, Integer, Real, String, and Set. Expressions are built using logical (and,or, not) and relational operators (e.g. < and >), navigational expression onattributes, association ends and side-effect free methods, and existentiallyquantified expressions on sets. Beside the standard symbol self we introducethe new symbol caller of type String. Note that, in the sense of our grammar,self and caller are the names of parameters in the context of a constraintexpressions.

Each authorization constraint is an expression of type Boolean and isstored in the tagged value constraint of the permission that it is constraining.Because of this structural assignment, we do not need an explicit OCL contextdeclaration as part of an authorization constraint. Such a declaration canautomatically be obtained if needed. Note that in order to improve thereadability of a model, we typically also attach a text note with the constraintexpression to the permission’s association class.

In our example policy, the permission UserMeeting is constrained by theauthorization constraint

self.participants->exists(p|caller=p.name) ,

which restricts the permission to users who are participants of a particularmeeting.

4.3 Building SecureUML Dialects

In this section, we will describe our approach for integrating SecureUML intoa system design modeling language, i.e. how a security design modeling lan-guage is built with the help of a SecureUML dialect. We will explain all steps

53

ExampleLanguage <<metamodel>>

SecureUML <<metamodel>>

Resource

EntityFullAccess

CompositeAction

Attribute Entity EntityRead

context EntityFullAccess inv:

subs = resource.actions->select(name="read")

read

Dialect Definition

Figure 4.3: ExampleLanguage

required to define a dialect and outline a typical integration using the exam-ple language introduced in Section 2.2.2. A complete dialect definition alongwith guidelines for developing dialects in general will be given in Chapter 5.

4.3.1 Integrating the Abstract Syntax

The dialect definition mainly takes place in a metamodel, which integrates theabstract syntax of both languages. As the example metamodel in Figure 4.3suggests, a dialect definition results in an extension of the system designmodeling language’s metamodel. Note that the figure only gives a partialexample of a dialect metamodel. Thus only selected metamodel elementsboth of the original modeling languages as well as the dialect definition areshown. In the upper area there is the MOF package containing the definitionof SecureUML and in the lower area there is the package of the examplesystem design language.

To start with, the metamodel of SecureUML is imported into the ex-ample language, which is denoted by the dependency arrow between bothpackages. This makes the SecureUML vocabulary available to the securitydesign language under development.

Then we identify the MOF classes of the system design language that shallbe protected resources of SecureUML and formalize this decision by derivingthem from the SecureUML base type Resource (cf. Section 4.1). This is shown

54

at the left-hand side of Figure 4.3 on the example of the classes Attribute andEntity.

Most of the remaining steps focus on the actions offered by the resourcesof the security design language. We define action types, assign actions toresources, and stipulate the structure of the composition hierarchy on actions.

First, one sub-class of CompositeAction is created for each type of actionthat may be a super-action in the hierarchy ActionHierarchy. This is shownin the example figure for the action types EntityRead and EntityFullAccess. Weuse this additional metamodel classes to define the hierarchy ActionHierarchy

using OCL invariants (see below).Second, the domain of the association ResourceAction between actions and

resources is defined for each resource type. This is realized by drawing anamed dependency arrow from the resource type to an action type. Thename of the dependency determines the name of the action in the contextof its resource. The example shows this for the classes Entity and EntityRead.Note that the assignment of atomic actions to a resource is modeled usingthe SecureUML base class AtomicAction.

Third, for each sub-class of CompositeAction the domain of the hierarchyActionHierarchy is defined by an OCL invariant as shown on the example ofEntityFullAccess. The invariant defines that EntityFullAccess is a super-actionof read on the same entity. In order to avoid cycles in the action hierarchy,we suggest the following design principle: Such relations are only establishedamong actions of different type belonging to the same resource or its sub-resources (e.g. the attributes of an entity).

As the last step in defining a SecureUML dialect, the rules for resourcederivation can be defined. This is an optional step that is only required ifthe system design modeling language supports inheritance. The definitionis formalized as an OCL invariant of the respective metamodel class thatspecifies the domain of the association ResourceDerivation.

4.3.2 Integrating the Concrete Syntax

The concrete syntax of a system design modeling language and SecureUMLmust also be integrated. This involves the definition of new stereotypes aswell as the refinement of constraints on existing notation elements.

To begin with, every security design language has its own set of action ref-erence types (cf. Section 4.2), each of them representing a class of referencesto the actions of a particular resource type. For each type of action refer-ences, a new stereotype along with a definition of the naming conventions forthis type are defined. For example, we define the stereotype «EntityAction»that denotes references to actions of an entity.

55

In SecureUML, a permission is drawn as an association class with stereo-type «Permission» between a class with the stereotype «Role» and any otherUML class. The dialect limits this generic definition to those classes of thesystem modeling language that are protected resources. In our example, werestrict the definition to classes with the stereotype «Entity».

4.3.3 The Structure of Security Design Models

A security design model (MOF M1 level) consists of instances of the classes(MOF M2 level) in the metamodel of a security design language. This meta-model is the result of combining SecureUML with a particular system designlanguage in the way explained above.

According to the MOF mapping rules introduced in Section 3.1.1, eachmodel in abstract syntax can also be represented as a relational model. Weuse this representation to define the semantics of access control in securitydesign languages built with SecureUML and to specify transformation func-tions.

Each model m given in a particular security design language is translatedto a n-tuple as shown by the following for our example language

mExampleLanguage := (User ,Group, Subject ,Role,Permission,

Resource,Action,AtomicAction,

CompositeAction,AuthorizationConstraint ,

SG , SA,RH ,PA,CA,AA,AD ,AH ,RA,RD ,

Entity ,Attribute,EA,

EntityName,AttributeName, getAttributeByName,

EntityFullAccess ,EntityRead , . . .) .

The components of the tuple correspond to the different parts of the lan-guage definition. In the first four lines there are the sorts and relationscorresponding to the types and associations in the SecureUML metamodel(cf. Figure 4.1 on page 48); we will explain these elements in detail in Sec-tion 4.4. While these components are fixed for all security design languagesbuilt upon SecureUML, the remaining components depend on the particularsystem design modeling language. In the lines 5 and 6 there are the sortsand relations derived from the metamodel of the example system modelinglanguage (cf. Figure 2.5 on page 26), and the sorts in the last line correspondto the elements of the dialect definition (cf. Figure 4.3).

As this thesis proceeds, we will work with different views on such a se-curity design model. Each view focuses on model information relevant for a

56

particular purpose. The system design view consists of the sorts and relationsderived from the metamodel elements of the original system design language.In our example, these are the sorts Entity and Attribute and the relationsEA, EntityName, AttributeName, and getAttributeByName. In contrast, thesorts and relations corresponding to the SecureUML metamodel basicallyconstitute the access control view. A detailed definition of this view is givenin Section 4.4.

The access control view has the following interesting property: The sortsAction and Resource as well as the relations AH , AD , RD and RA havebeen declared in the SecureUML metamodel. However their definition for aparticular security design model is determined by the underlying SecureUMLdialect. For example, due to the mapping rules for inheritance, the contentsof the set Resource are determined by the union of all sets corresponding tothe resource types of a security design language. These are the sorts Entityand Attribute in the example above.

We will utilize this property of SecureUML to define a semantics of accesscontrol that will hold for any security design language that is built upon Se-cureUML. The definition of an access control semantics only refers to the corevocabulary of SecureUML as defined by the access control view. The defini-tion of a SecureUML dialect suffices to automatically give models specifiedin the resulting security design language a semantics of access control.

4.4 Semantics

SecureUML formalizes access control decisions that depend both on the as-signments of users and permissions to roles (static part) and on the satisfac-tion of authorization constraints in the current system state (dynamic part).The tricky bit in defining the semantics is formalizing the satisfaction of aconstraint relative to the current system state, which varies over time. To ac-complish this, we represent the system state at a time point t by a first-orderstructure S(t). An authorization constraint can be expressed as a formulaφAC (u, a) in first-order logic over a signature Σ, which is determined by thesystem model. The question of whether a user u is allowed to perform anaction a can then be cast as the logical decision problem S(t) |= φAC (u, a),formalizing that access should be granted if and only if φAC (u, a) is satisfiedin S(t). The formula φAC (u, a) is built from the constraints that are assignedto permissions and depends on the access control view of a security designmodel, e.g. the assignments of users and permissions to roles.

We introduce the semantics of SecureUML in three steps. As a founda-tion, we first give the semantics of the static part of SecureUML. Afterwards,

57

we extend it to cover authorization constraints in the way outlined above.To conclude this section, we discuss the behavior of different security archi-tectures in the case where no permission is explicitly given for an action andhow this influences the semantics of SecureUML.

4.4.1 Static Part

As mentioned in the previous section, the base elements of the access con-trol view are derived from the SecureUML part of a security design model.We consider the sets Subject , User , Group, Role, Permission, Action, andCompositeAction, each containing entries for every model element of thecorresponding metamodel types Subject, User, Group, Role, Permission, Action,and CompositeAction. Note that User and Group are subsets of Subject andCompositeAction is a subset of Action. We also have the relations

• SA ⊆ Subject × Role (SubjectAssignment),

• SG ⊆ Subject ×Group (SubjectGroup),

• RH ⊆ Role × Role (RoleHierarchy),

• PA ⊆ Role × Permission (PermissionAssignment),

• AA ⊆ Permission × Action (ActionAssignment),

• AD ⊆ Action × Action (ActionDerivation),

• AH ⊆ CompositeAction × Action (ActionHierarchy),

which contain tuples for each instance of the corresponding association in theabstract syntax of SecureUML.

Additionally, we define the partial orders ≥Subject , ≥Role , and ≥Action onthe sets of subjects, roles, and actions respectively. ≥Subject is given by thereflexive, transitive closure of the relation SG and a subject s1 is larger in≥Subject than a subject s2 if s1 is assigned to s2 in the transitive closure of therelation SG . ≥Role is defined analogously based on the relation RH and wewrite subroles (roles with additional privileges) on the left (larger) side of the≥-symbol. ≥Action is defined by the reflexive, transitive closure of the unionof the composition hierarchies on actions, defined by the relation AH , andthe derivation hierarchy on action, defined by the relation AD . An action a1

is larger in ≥Action than an action a2 if either a1 is an super-action of a2 inthe relation AH or if a2 is derived from a1 in the relation AD .

Cycles in ≥Action may only arise from the reflexive closure of the originalrelations AH and AD . This is ensured by the following conventions: Thecomposition hierarchy on actions AH only relates actions of different types

58

that belong to the same resource or group of resources (typically a class andits sub-elements, e.g. attributes). In contrast, the derivation hierarchy onactions AD may only relate actions of the same type on different resources,e.g. classes in an inheritance hierarchy. Moreover, cycles are not allowed inthe inheritance hierarchy between resources.

In this setting, access is granted to user u on action a if and only if thepredicate AC (u, a) holds, which is

AC (u, a) ⇐⇒ (u, a) ∈≥Action ◦AA ◦ PA ◦ ≥Role ◦ SA ◦ ≥Subject . (4.1)

Expanding the relational composition leads to

AC (u, a) ⇐⇒ ∃ s ∈ Subject : u ≥Subject s ∧∃ r, r′ ∈ Role : (s, r) ∈ SA ∧ r ≥Role r′∧∃ p ∈ Permission : (r′, p) ∈ PA ∧∃ a′ ∈ Action : (p, a′) ∈ AA ∧ a′ ≥Action a ,

(4.2)

which means that access is granted to user u on action a if and only if theuser u is, directly or via a group membership, assigned to a role that is largeror equal to a role that has a permission to an action that is superior or equalto the action a.

4.4.2 Dynamic Part

We now extend the semantics of SecureUML to cover authorization con-straints. As explained above, the key idea is to represent the system state attime point t (M0 level) as a first-order structure S(t) (M0 level) over a sig-nature Σ (M1 level) and to formalize access control as a satisfaction problemof a first-order formula φAC (u, a) over the same signature.

The signature Σ is determined by the system design view (cf. Section 4.3.3)of a security design model (M1 level), i.e. model elements that are instancesof the metamodel elements of the system design language. Given a securitydesign model, we define a many-sorted signature Σ = (S, F, P ), where S is aset of sorts, F is a set of typed function symbols (including constants), andP is a set of typed predicate symbols. The mapping from system models toΣ is as follows:

• Each class in the system model is mapped to one sort symbol c in Sand a constant symbol self c of type c in F denoting the object of thisclass in whose context a constraint expression is evaluated. The set ofall constant symbols of this form is used to represent the OCL symbolself (cf. Section 2.2.1) in the first-order language over Σ.

59

• The representation of attributes depends on their type. Each attributeof type Boolean is mapped to a predicate symbol in P , attributes ofother types are mapped to a function symbol each in F .

• The representation of association ends depends on their multiplicity.Each association end of multiplicity one is mapped to a function sym-bol in F , association ends of other multiplicity, e.g. n or 0..1, are rep-resented by a predicate symbol each in P .

• Each side-effect free method2 that returns Boolean is mapped to a pred-icate symbol in P , otherwise it is mapped to a function symbol in F .

Additionally, the signature always includes the following symbols:

• sort symbols for the base types Real, Integer, Boolean, and Stringand corresponding (overloaded) predicate symbols (e.g. = or <)

• a constant symbol caller of type String denoting the name of the useron whose behalf an action is currently performed

The following shows the signature Σ obtained from the example model inFigure 4.2.

S := {Meeting ,Person} ∪ {String ,Real , Integer}F := {self Meeting , self Person ,meetingStart ,meetingDuration,meetingOwner ,

personName, personEMail} ∪ {caller}P := {meetingParticipants} ∪ {=, . . . }

As explained above, we formalize the question whether a user u is allowedto access an action a as a satisfaction problem of a formula φAC (u, a) over asignature. As a foundation for determining φAC (u, a), we extend the accesscontrol view by the set AuthorizationConstraints and the relation

CA ⊆ Permission × AuthorizationConstraint

corresponding to the class AuthorizationConstraint and the association Con-

straintAssignment in the metamodel of SecureUML.Additionally, we define the auxiliary function

UAP : (User × Action) → 2Permission

2OCL expressions may only refer to side-effect free methods.

60

by

UAP(u, a) :={p ∈ Permission | ∃ s ∈ Subject : u ≥Subject s ∧∃ r, r′ ∈ Role : (s, r) ∈ UA ∧ r ≥Role r′ ∧ (r′, p) ∈ PA ∧∃ a′ ∈ Action : (p, a′) ∈ AA ∧ a′ ≥Action a} ,

(4.3)

which determines the set of permissions a user has for an action.Finally, we introduce the function

Constraint : Permission → LΣ ,

which maps permissions to their associated constraints translated into thefirst-order language over Σ and associates the formulae true with uncon-strained permissions. The definition of the translation is given in the ap-pendix A.1.

In this setting, we define that at time t the user u is allowed to performthe action a if and only if S(t) |= φAC (u, a), where

φAC (u, a) :=∨

p∈UAP(u,a)

Constraint(p) . (4.4)

This means that access is granted if and only if the user u has a permissionp for which the corresponding formula Constraint(p) is valid at time t. Notethat the disjunction over an empty set UAP results in the formula false. Inthat way, access is denied to users without any permission on a.

As an example, the following is φAC for the user Bob on the action readof the entity Meeting in Figure 4.2

∃ p : meetingParticipants(self Meeting , p) ∧ (personName(p)=caller) .

Given a system state at time t, the definition of a first-order structureS(t) over the signature Σ is straightforward and includes:

• the sorts Di, 0 ≤ i < #classes , given by the classes of the system,where each sort contains all instantiated objects of the correspondingclass;

• the sorts Real, Integer and String;

• functions for each attribute, association end of multiplicity one, andthe side-effect free methods that do not return a Boolean;

• the relations Pi, given by all attributes of type Boolean, all associationends of multiplicities other than one, and all side-effect free methodsthat return a Boolean.

61

The interpretation of the symbols in Σ over this structure is also straight-forward when one considers the close correspondence between the symbolsand their counterparts in the structure S(t). The only non-trivial interpreta-tions are those of the constant symbols caller and self i. The interpretation ofcaller is given by the name of the subject that represents the current caller,i.e., the subject that is currently trying to access some protected resource.Let Dj be the sort representing the type of the object that is currently ac-cessed. self i is interpreted by the element of the set Dj that represents theobject that is currently accessed, and self i is interpreted arbitrarily for allremaining i 6= j.

Note that we give a sensible interpretation only for the single constantsymbol selfj that is of the same sort as the object that is currently accessed.However, this does not lead to problems because the translation from OCLconstraints into this language (described below) ensures that no formulaearise containing symbols whose interpretation is arbitrary.

4.4.3 Default Behavior

A final point concerns default behavior. Existing technologies (cf. Section 2.4)differ in how they treat the case where no permission is explicitly given for anaction. For example, in the Java Servlet architecture, access is granted by de-fault, whereas access is denied in the Java platform security architecture [19].We call this property of a platform its default behavior. To support differ-ent possibilities, while keeping the semantics simple, we add a distinguishedelement DefaultPermission to the set Permission and a distinguished ele-ment DefaultRole to the set Role. All users are automatically members ofDefaultRole, and DefaultPermission is automatically assigned to all ac-tions that do not have other permissions that are directly, or indirectly (viaan ActionComposition or ActionDerivation relation), assigned. The defaultbehavior, i.e., whether DefaultRole has DefaultPermission, is specified aspart of a SecureUML dialect and, as we will see, affects the model transfor-mation process.

62

Chapter 5

Example Modeling Language:ComponentUML

In this section we give an example of a system design language, which wecall ComponentUML, and present its integration with SecureUML. We alsoshow how to model security policies using the resulting security design mod-eling language and explain its semantics using the example introduced inSection 2.1.

ComponentUML is a simple modeling language that can be used to de-fine distributed object-oriented systems. We derived ComponentUML fromthe system design language that we used in our case study for developingcomponent-based systems with access control architectures. We reduced thescope of the language because the purpose of introducing ComponentUMLin this thesis is to demonstrate our approach for building and using securitydesign languages. Therefore (and to support the readability of this thesis),we limited the language’s vocabulary to the primitives necessary to achievethis goal.

5.1 Language Definition

The metamodel for ComponentUML is shown in Figure 5.1. Elements of typeEntity represent business object types of a particular domain. An entity mayhave multiple methods and attributes, represented by elements of the typesMethod and Attribute respectively. A Method can be marked as side-effect freeusing the attribute isQuery. The type of an attribute is denoted by the MOFattribute type.

Associations are used to specify relations between entities. An associationis built from an Association model element and every entity participating in

63

Attribute

type : String

Method

isQuery : Boolean

Entity

1

0..*

1

attributes 0..*

EntityAttributes

1

0..*

1

methods 0..*

EntityMethods

Association AssociationEnd

isToMany : Boolean

0..*

1

roles 0..*

1

EntityRoles

1 2 1 2

Connections

ComponentUML <<metamodel>>

Figure 5.1: ComponentUML Metamodel

Room

floor : int number : int

<<Entity>>

Person

name : string eMail : string

<<Entity>> Meeting

start : date duration : time

notify() cancel()

<<Entity>>

0..1

0..* +location

0..1

0..*

1..* 0..*

+participants

1..* 0..*

1 0..*

+owner

1 0..*

Figure 5.2: Scheduling application

an association is connected to the association by an AssociationEnd. Theattribute isToMany specifies whether more than one target entity instancemay be associated with a single entity instance across the association.

Note that although not shown in the Figure 5.1, all MOF classes in theComponentUML metamodel are sub-classes of the base class Element, whichprovides base functionality like the attribute name.

ComponentUML uses a UML-based notation where entities are repre-sented by UML classes with the stereotype «Entity». Every method, at-tribute, or association end owned by such a class is automatically consideredas a respective method, attribute, or association end of the entity, so nofurther stereotypes are necessary.

Figure 5.2 shows the structural model of our scheduling application in theComponentUML notation. Instead of classes, we now have the three entitiesMeeting, Person, and Room, represented by UML classes with the stereotype«Entity».

64

5.2 SecureUML Dialect for ComponentUML

We now demonstrate how we extend ComponentUML to a security designlanguage that supports the specification of access control policies. We startby defining the SecureUML dialect at the level of abstract syntax. Based onthis definition, we will afterwards derive the relational representation of Com-ponentUML models in abstract syntax. In the last subsection, we describehow we combine the concrete syntax of SecureUML and ComponentUML.

5.2.1 Extending the Abstract Syntax

Merging the Syntax As the first step, we extend the abstract syntaxof ComponentUML with the vocabulary of SecureUML by integrating bothmetamodels, i.e., we merge the abstract syntax of both modeling languages.This is technically achieved by importing the SecureUML metamodel intothe metamodel of ComponentUML. This extends ComponentUML with theSecureUML modeling constructs, e.g., Role and Permission. The use of pack-ages and corresponding namespaces for defining these metamodels ensuresthat no conflicts arise while merging them.

Defining the Default Behavior The default behavior of a dialect (cf.subsection 4.4.3) is defined by a tagged value DefaultBehavior on the MOFpackage of the target security design language. The allowed values are “true”and “false”. We specify the value “true”, which means that access is grantedby default.

Identifying Protected Resources Second, we identify the model ele-ments of ComponentUML representing protected resources and formalizethem as part of the dialect metamodel. To do this, we must determine whichmodel elements we wish to control access to in the resulting systems. More-over, when doing this, we must account for what can ultimately be protectedby the target platform. Suppose, for example, we decide to interpret entityattributes as protected resources and the target platform supports access con-trol on methods only. This is possible, but would necessitate a transformationfunction that transforms each modeled attribute into a private attribute andgenerates (and enforces access to) access methods for reading and changingthe value of the attribute in the generated system.

In our example, we identify Entity, Method, Attribute, and AssociationEnd

as the types of protected resources of ComponentUML. This identification istechnically realized by deriving these metatypes from the SecureUML type

65

AtomicAction (from SecureUML)

AssociationEndFullAccess AttributeFullAccess EntityRead EntityUpdate EntityFullAccess AtomicAction (from SecureUML)

CompositeAction (from SecureUML)

Resource (from SecureUML)

Entity

name : string Method Attribute AssociationEnd

execute fullAccess update

read delete read update fullAccess create fullAccess update read

Figure 5.3: Dialect Metamodel for ComponentUML

Resource as shown in Figure 5.3. In this way, the metatypes derive all prop-erties needed to define authorization policies. Additionally, this figure showsseveral action classes that are defined as subtypes of the SecureUML classCompositeAction. This way, the action composition hierarchy, which we in-troduce below, can be defined as part of each action’s type information byspecifying an OCL invariant.

Defining Resource Actions In the next step, we define the set of actionsthat is offered by every model element type representing a protected resource,i.e. we fix the domain of the metamodel association ResourceAction for eachresource type of ComponentUML. Actions can be freely defined at every levelof abstraction. One may choose just to leverage the actions that are presentin the target security architecture, e.g. the action “execute” on methods. Al-ternatively one may define actions at a higher level of abstraction, e.g. “read”access to a component. This would result in an intuitive vocabulary sincegranting read or write access to an entity is more intuitive than giving some-one the privilege to execute the methods getBalance, getOwner, and getId.The use of high-level actions also leads to concise models. However, we mustensure that these high-level actions can be mapped to actions in the targetsecurity platform. We usually define actions of both sorts and connect themusing hierarchies.

In the metamodel, the set of actions a particular resource type offers isdefined by named dependencies from the resource type to action classes, as

66

composite action type subordinated actions

EntityFullAccess create, read, update and delete of the entity.EntityRead read for all attributes and association ends of the

entity,execute for all side-effect free methods of the entity.

EntityUpdate update for all attributes and association ends ofthe entity,execute for all none-side-effect free methods of theentity.

AttributeFullAccess read and update of the attribute.AssociationEndFullAccess read and update of the association end.

Table 5.1: ComponentUML Action Hierarchy

shown in Figure 5.3. Each dependency represents one action of the referencedaction type in the context of the resource type, where the dependency namedetermines the name of the action. For example, the metamodel in Figure 5.3formalizes that an Attribute always possesses the action fullAccess of typeAttributeFullAccess and the actions read and update of type AtomicAction.

Defining the Action Hierarchy In the final step, we fix the hierarchy onactions. We do this by restricting the domain of the SecureUML associationActionHierarchy for each composite action class with an OCL invariant. Anoverview on the action hierarchy of ComponentUML is given in Table 5.1.

The approach we take is shown for the action class EntityFullAccess in thefollowing OCL expression.

context EntityFullAccess inv:self .subs = self .resource. actions−>select(name=”create” or name=”read” or

name=”update” or name=”delete”)

This expression is an invariant on the association end subs of the associationActionHierarchy (cf. Figure 4.1 on page 48), which states that the compos-ite action EntityFullAccess is larger (a “super-action”) in the action hierarchythan the actions create, read, update, and delete of the entity the actionbelongs to. This entity is accessed using the association end resource of theSecureUML association ResourceAction. Note that this example illustrates thestrong coupling between composite actions and a particular resource type asthis expression depends on the structure of the resource type Entity.

We now want to specify the composition hierarchy of the action classEntityRead. As shown in Table 5.1, actions of this class are larger than theread actions of the attributes and association ends contained in the entity and

67

the execute actions of all side-effect free methods of the entity. We formalizethis in the following OCL invariant.

context EntityRead inv:self .subs = self .resource. attributes . actions−>select(name=”read”)−>union(self .resource. roles . actions−>select(name=”read”)−>union(self .resource.operations−>select(isQuery).actions−>select(name=”execute”)))

The expression is somewhat complex as we must use the syntax of the Com-ponentUML metamodel (including SecureUML and the dialect definition) toselect actions of the resources that are contained in the entity instance thatthe action belongs to.

Each line of the expression selects actions of a single type of sub-resourcesof the entity and these intermediate results are combined using the OCLstandard operation union on sets.

For example in the first line, the set of attributes of the entity is deter-mined by the path expression “self.resource.attributes”. The actionsof these attributes are then obtained by the SecureUML association end ac-

tions. Because of the definition of the OCL dot-operator on sets (cf. [30]),this expression results in the union of all actions on all attributes.

We now give the definitions for the remaining composite action classes.To start with, the following specifies that EntityUpdate is a super-action of allactions update on all attributes and association ends of its entity instance.

context EntityUpdate inv:self .subs = self .resource. attributes . actions−>select(name=”update”)−>union(self .resource. roles . actions−>select(name=”update”))−>union(self .resource.operations−>select(not isQuery).actions−>select(name=”execute”))

AttributeFullAccess and AssociationEndFullAccess are larger than the actionsread and update on the same attribute or association end, respectively. Thisis specified by the following invariants.

context AttributeFullAccess inv:self .subs = self .resource. actions−>select(name=”read”)−>union(

self .resource. actions−>select(name=”update”))

context AssociationEndFullAccess inv:self .subs = self .resource. actions−>select(name=”read”)−>union(

self .resource. actions−>select(name=”update”))

5.2.2 Formal Definition of ComponentUML Models

As a foundation for giving ComponentUML models a formal semantics of ac-cess control and to define transformation rules, we need a mathematical rep-resentation of such models. We derive this representation from the language’s

68

metamodel by applying the MOF mapping as specified in Section 3.1.1 andformalize that a model given in ComponentUML is translated to a n-tuple

ModelComponentUML := (AtomicAction,CompositeAction,AH ,RD ,AD , . . .

Element ,Entity ,Method ,Attribute,AssociationEnd ,

EN ,EM ,EA,ER, name, entityAttributes , entityMethods ,

entityRoles ,methodIsQuery , associationEndIsToMany ,

EntityFullAccess ,EntityUpdate,EntityRead ,

AttributeFullAccess ,AssociationEndFullAccess) .

The components of the definition correspond to language primitives of Se-cureUML1 (line 1, cf. Section 4.1), the original definition of ComponentUML(lines 2-4, cf. Section 5.1), and the SecureUML dialect for ComponentUML.

To determine the contents of most of the sets and relations is straightfor-ward. For example, for each instance of type Entity there is a correspondingentry in the set Entity and the relation EA contains tuples for each instanceof the corresponding association EntityAttributes.

A subtle issue might be the definition of the sets AtomicAction andCompositeActions , and the hierarchies on actions AH and AD . Recall thatalthough these elements are declared by SecureUML, their contents are de-fined by the SecureUML dialect for ComponentUML. Since these sets andrelations are of fundamental importance for giving ComponentUML modelsa semantics of access control, we will discuss their definitions now.

The sets of atomic and composite actions are given as

AtomicAction :={create, delete} × Entity ∪ {execute} ×Method ∪{read , update} × (Attribute ∪ AssociationEnd)

(5.1)

and

CompositeAction :={fullAccess , update, read} × Entity ∪{fullAccess} × (Attribute ∪ AsssociationEnd) ,

(5.2)

where the assignment of actions to resources is implicitly given by the waythe actions are defined as tuples of action types and resources.

The composition hierarchy on actions AH is

AH :=EntityFullAccess ∪ EntityRead ∪ EntityUpdate ∪AttributeFullAccess ∪ AssociationEndFullAccess ,

1For simplicity, we only list the SecureUML sorts and relations whose definitions arerelevant for this section.

69

where the definition of each individual set is derived from the OCL invariantspecified for the corresponding class of composite actions as follows

EntityFullAccess := {((fullAccess , e), (t , e)) ∈ Action × Action|e ∈ Entity ∧ t ∈ {create, read , update, delete}}

EntityRead := {((read , e), (read , a) ∈ Action × Action |e ∈ Entity ∧ a ∈ entityAttributes(e)}∪{((read , e), (read , a) ∈ Action × Action |e ∈ Entity ∧ a ∈ entityRoles(e)}∪{((read , e), (execute, m)) ∈ Action × Action |e ∈ Entity ∧m ∈ entityMethods(e)∧entityIsQuery(m)}

EntityUpdate := {((update, e), (update, a) ∈ Action × Action |e ∈ Entity ∧ a ∈ entityAttributes(e)}∪{((update, e), (update, a) ∈ Action × Action |e ∈ Entity ∧ a ∈ entityRoles(e)}∪{((update, e), (execute, m) ∈ Action × Action |e ∈ Entity ∧m ∈ entityMethods(e)∧¬entityIsQuery(m)}

AttributeFullAccess := {((fullAccess , a), (t, a)) ∈ Action × Action |a ∈ Attribute ∧ t ∈ {read ,write}}

AssociationEndFullAccess := {((fullAccess , a), (t, a)) ∈ Action × Action |a ∈ AssociationEnd ∧ t ∈ {read , update}} .

Since ComponentUML does not support inheritance, the derivation hier-archies on resources RD and actions AD (cf. subsection 4.4) are empty. Thusthe partial order on actions ≥Action is just determined by the composition hi-erarchy on actions AH .

5.2.3 Extending the Concrete Syntax

In this section, we integrate the concrete syntax of SecureUML into Compo-nentUML in order to give our new security design language a homogeneousUML encoding. More precisely, we import the SecureUML notation intoComponentUML. Technically speaking, we merge the UML profiles of bothlanguages. Afterwards, we identify the resource types that are representedby UML classes and that may be referenced by a permission as its modelanchor (cf. Section 4.2).

70

stereotype resource type naming convention

«EntityAction» Entity empty string«EntityMethodAction» Method method signature«EntityAttributeAction» Attribute attribute name«EntityAssociationEndAction» AssociationEnd association end name

Table 5.2: Action Reference Types for ComponentUML

Entities are the only resources for which both requirements hold and wefix this decision by specifying the following OCL well-formedness rule on thetype Association of the UML metamodel (cf. [30], Chapter 2).

context Association inv:( self .stereotype.name−>includes(”Permission”)) implies

(( self .connection−>size == 2) and(( self .connection−>at(0).participant.stereotype.name−>includes(”Role”) and

self .connection−>at(1).participant.stereotype.name−>includes(”Entity”)) or( self .connection−>at(0).participant.stereotype.name−>includes(”Entity”) andself .connection−>at(1).participant.stereotype.name−>includes(”Role”))))

In the first line, the rule is restricted to associations with the stereotype«Permission». The remainder of the expression prescribes that a permissionis always connected to exactly two UML classes and specifies that one ofthese classes must have the stereotype «Role» and the other must have thestereotype «Entity».

Finally, we define the action reference types of ComponentUML. As ex-plained in Section 4.2, the assignment of an action to a permission (meta-model association ActionAssignment) is denoted by an attribute of the per-mission’s association class. A SecureUML dialect typically contains severalresource types, each of them requiring a different naming scheme used toidentify resources of this type. We use stereotypes to distinguish action ref-erence types and fix a naming convention for each type of action references.

The Table 5.2 shows the action reference stereotypes of ComponentUML,along with the corresponding resource types and naming conventions. Notethat all resources are identified in the context of the entity that is the modelanchor of the particular permission. As the last step, we formalize thatonly the stereotypes listed in Table 5.2 may be assigned to attributes of thepermission’s association class by the following well-formedness rule.

context Association inv:( self .stereotype.name−>includes(”Permission”)) implies

( self . feature−>forAll(stereotype.name−>includes(”EntityAction”) orstereotype.name−>includes(”EntityMethodAction”) orstereotype.name−>includes(”EntityAttributeAction”) orstereotype.name−>includes(”EntityAssociationEndAction”)))

71

UserMeeting

<<EntityAction>> Meeting : read <<EntityAction>> Meeting1 : create

OwnerMeeting

<<EntityAction>> Meeting : update <<EntityAction>> Meeting1 : delete

SupervisorCancel

<<EntityMethodAction>> Meeting.cancel : execute <<EntityMethodAction>> Meeting.notify : execute

caller = self.owner.name

User <<Role>>

Supervisor <<Role>>

Person

name : string eMail : string

<<Entity>> Meeting

+ start : date + duration : time

+ notify() + cancel()

<<Entity>>

<<Permission>> <<Permission>>

<<Permission>>

0..* 1..* 0..* +participants

1..*

0..* 1 0..*

+owner

1

Room

floor : int number : int

<<Entity>> 0..*

0..1

0..*

+location

0..1

Figure 5.4: Scheduler Example with Authorization Policy

5.3 Example Authorization Policy

We now use the combined language to formalize the security policy stated inSection 2.1. We do this by defining permissions in the scheduler entity model,which correspond to the three policy requirements. As these permissionsassociate roles with actions, we employ the extension with the roles User

and Supervisor, introduced in Section 4.2.

The first requirement states that any user may create and read meet-ing data. We formalize this by the permission UserMeeting in Figure 5.4,which grants the role User the right to perform create and read on the entityMeeting.

We formalize the second requirement with the permission OwnerMeeting,which states that a meeting may only be altered or deleted by its owner. Thispermission grants the role User the privilege to perform update and deleteon Meeting. Additionally, we restrict this permission with the authorizationconstraint “caller = self.owner.name”, which states that the name of a callermust be equal to the name of the owner of the particular meeting instance.Due to the definition of the action update (cf. Table 5.1), this permission musthold for all attempts to change the value of the attributes or association endsof the meeting entity as well as for invocations on the methods notify orcancel.

To complete the formalization of our security policy, we formalize thethird requirement with the permission SupervisorCancel. This gives a su-pervisor the permission to cancel any meeting, i.e., the right to execute themethods cancel and notify.

72

5.3.1 Policy Semantics

We now illustrate the semantics of access control in ComponentUML modelsby analyzing several access control decisions for the users Alice and Bob, eachtrying to execute the method cancel on Meeting. As noted in Section 4.3.3,we can directly apply the semantics of SecureUML (cf. Section 4.4) to theexample policy given in the previous section. The (partial) example accesscontrol view is

User := {Bob,Alice, Jack}Role := {User , Supervisor}

Permission := {OwnerMeeting , SupervisorCancel , . . . }Action := {(update,Meeting), (execute,Meeting .cancel), . . . }

AuthorizationConstraint := {‘caller = self.owner.name’}SA := {(Bob,User), (Alice, Supervisor)}PA := {(User ,OwnerMeeting),

(Supervisor , SupervisorCancel), . . . }CA := {(OwnerMeeting , ‘caller = self.owner.name’)

AA := {(OwnerMeeting , (update,Meeting)),

(SupervisorCancel , (execute,Meeting .cancel)), . . . }≥Role:= {(Supervisor ,User), (Supervisor , Supervisor), (User ,User)}≥Action:= {((update,Meeting), (execute,Meeting .cancel)), . . . } ,

and the signature Σ, derived from the system model, is

S := {Meeting ,Person, . . . } ∪ {String , . . . }F := {self Meeting , . . . ,meetingOwner , personName} ∪ {caller}P := {meetingParticipants , . . . } .

The constant symbol self Meeting of sort Meeting denotes the currently accessedmeeting. The function symbols meetingOwner : Meeting → Person andpersonName : Person → String represent the association end owner of theentity type Meeting and the attribute name of a person.

Now suppose that Alice wants to cancel a meeting entry owned by Jackat time t1. The corresponding structure S(t1) over the signature Σ is given

73

by the interpretation where

callerS(t1) := ‘Alice’

MeetingS(t1) := {meetingJack}PersonS(t1) := {alice, bob, jack}self

S(t1)Meeting := meetingJack

meetingOwnerS(t1) := {(meetingJack , jack)}personNameS(t1) := {(jack , ‘Jack’), (bob, ‘Bob’), (alice, ‘Alice’)} .

The formula that has to be satisfied by the structure S(t1) in order to grantAlice access is built according to the definition 4.4, given in Section 4.4. Theset of permissions Alice has on the action Meeting .cancel .execute is

UAP(Alice,Meeting .cancel .execute) = {OwnerMeeting , SupervisorCancel} .

The constraint expression self.owner.name = caller on the permissionOwnerMeeting is translated into the formula

caller = personName(meetingOwner(self Meeting()))

in the language defined by the signature Σ and the formula for the permissionSupervisorCancel is true. The access decision is formalized as

S(t1) |= true ∨ caller = personName(meetingOwner(self Meeting())) ,

which is satisfied.Alternatively, suppose that Bob tries to perform this action at time t2.

The corresponding structure S(t2) differs from S(t1) by the interpretationof the constant symbol caller , which now refers to ‘Bob’. Bob only has thepermission OwnerMeeting for this action, i.e.

UAP(Bob,Meeting .cancel .execute) = {OwnerMeeting} .

Hence

S(t1) |= caller = personName(meetingOwner(self Meeting()))

is required for access. Since Jack is the owner of this meeting, this constraintis not satisfied and access is denied.

74

Chapter 6

Generating Systems fromComponentUML Models

We now show how ComponentUML models can be transformed into exe-cutable systems with configured access control infrastructures for two differ-ent technologies, EJB and .NET. This not only shows that it is possible toautomatically generate systems with access control architectures but also thepotential for platform independent development with Model Driven Security.

The automatic generation of access control architectures is a powerfulmechanism for ensuring the quality of secure systems. But it also forcesdevelopers to rely on the generator for the correct implementation of accesscontrol infrastructures in the target platform. To ensure the correctness ofthe transformation, we propose the usage of formal methods in conjunctionwith rigorous testing.

The transformation functions explained in this work are based on theformal semantics of SecureUML. As an example, we will discuss the correct-ness of the transformation function for EJB access control. How the formalsemantics can be used as foundation for proving the correctness of a transfor-mation function is shown on the example of the sub-function for generatingthe infrastructure for declarative access control.

The chapter is structured as follows. We first introduce the notation usedto specify generation rules. Afterwards, we explain the transformation func-tion for EJB. In Section 6.3, we discuss the correctness of this transformationfunction and give a correctness proof for the sub-function for EJB declarativeaccess control in Section 6.4. In the last section, we outline a transformationfunction from ComponentUML to the .NET platform.

75

6.1 Notation

A transformation function is specified as a set of transformation rules. Eachrule operates on the relational representation of a ComponentUML model inabstract syntax as defined in subsection 5.2.2 and produces text output. Thestructure of a transformation rule is

<parameter declaration> 7→<rule name> <output> .

The name of the rule is specified on the arrow in the middle part. Eachrule takes one model or model element as input parameter. The parameterdeclaration at the left-hand side of the arrow declares the expected type andname of the parameter using a predicate, e.g. Entity(e) defines a parameter oftype entity with the name e. This predicate also functions as a preconditionthat must be satisfied in order to apply the rule.

The output created by the rule is specified on the right-hand side of thearrow (for simple rules) or on the next line (for more comprehensive rules).The output content is specified as a template that consists of static text withembedded instructions. An instruction is enclosed by [[]] and may executea function or apply a further transformation rule. The result of executingthe instruction must be text in both cases. This text is embedded in thesurrounding static text when the template is executed.

An example of an embedded function call is [[name(e)]], which writes thename of the entity e to the output text. Note that any variables an instructionrefers to are either parameters or variables of the enclosing transformationrule.

An embedded rule application specifies a set of calls to transformationrules and may optionally define a set of elements to which these transforma-tion rules shall be applied. The structure is as follows

[∀<variable> ∈ <set>] apply<list of rules> .

In its simplest form (without the optional part enclosed by []) the ruleapplication starts with the key word apply followed by a comma-separatedlist of calls to transformation rules that shall be applied to a variable alreadydefined in the template. An example is shown by the instruction

[[apply 7→assertion (a)]] ,

which applies the transformation rule 7→assertion to the variable a.A rule application can also be used to execute all listed transformation

rules on each element of a set of model elements. In this case, the first part

76

of the instruction determines the set of model element and the listed trans-formation rules are then applied to each element in this set. The followingshows an example of such a rule application

[[∀m ∈ entityMethods(e) apply 7→methodIntf (m)]] .

The instruction maps an entity to its methods using the function entityMethodsand applies the rule 7→methodIntf to each of these methods.

6.2 Enterprise JavaBeans

First, we outline the basic generation rules for EJB systems and illustrate theapproach using the example introduced in the previous section. Afterwards,we present the rules for transforming SecureUML elements into EJB accesscontrol information.

6.2.1 Basic Generation Rules for EJB

Basically, each entity in the model is transformed to an EJB of type entitybean and the methods, attributes and association ends of the entity aretranslated to methods and fields of this entity bean. An EJB applicationalso requires at least one XML deployment descriptor. In our transformationfunction, one such descriptor is generated for each model1.

The specification of the transformation function is grouped according tothe types of generated artifacts, which are the XML deployment descriptorand java source code files for the bean class, the component interface, andthe home interface of each EJB component.

For each artifact type, there is one top-level rule formalizing the creationof this artifact from a model element or a model, designated as the rootelement. Moreover, embedded instructions in the templates of these top-level rules control the translation of subordinated model elements of the rootelement, e.g. methods, attributes or association ends, in the context of thegiven artifact type.

Deployment Descriptor To begin with, a standard EJB deployment de-scriptor is created from a ComponentUML model as specified by the rule

1Note that in order to improve the readability we give a simplified version of thebasic generation rules for EJB. For example, we omit details concerning the generation ofdatabase and transaction support. We instead focus on the rules fundamental to generatingaccess control architectures.

77

ModelComponentUML(m) 7→ejbDesc

<ejb-jar><enterprise-beans>[[∀e ∈ Entity2 apply 7→entityDef (e)]]</enterprise-beans>. . .</ejb-jar>

(6.1)

The deployment descriptor defines all EJB components of an EJB appli-cation and we want to create one entity bean for each entity in the model.This is formalized by the embedded instruction that applies the rule

Entity(e) 7→entityDef

<entity><ejb-name>[[name(e)]]</ejb-name<local-home>[[name(e)]]Home</local-home><local>[[name(e)]]Local</local><ejb-class>[[name(e)]]Bean</ejb-class><persistence-type>Container</persistence-type>. . .

</entity>

(6.2)

to each entity model element in a ComponentUML model.7→entityDef specifies that the generated entity bean consists of a local com-

ponent interface, a local home interface and an EJB class, which providesthe implementation for the methods declared in the interfaces.

Note that the element <persistence-type> is set to“Container”meaningthat the EJB container is responsible for storing the state of the entity beaninstances in a database. This type of persistence management requires acertain style of generation for attributes and association ends as we will seebelow.

Home Interface The EJB home interface is generated by the rule

Entity(e) 7→homeIntf

public interface [[name(e)]]LocalHome extends EJBLocalHome {[[name(e)]]Local create() throws CreateException;. . .

} .

(6.3)

The name of the home interface is built from the entity’s name and thesuffix “LocalHome” and the interface is derived from the EJB base interfaceEJBLocalHome. A home interface created by this rule always offers a factorymethod (create) for creating new instances of the entity type.

2Note that all transformation rules specified in this chapter are performed in the contextof the same ComponentUML model. Thus we abandon on functions mapping a model toits contained elements and rather directly refer to the names of the sets and functions.

78

Component Interface The EJB component interface declares the meth-ods that can be accessed on instances of the entity bean type. It is createdfrom information in the entity and its methods, attributes and associationends by the rule

Entity(e) 7→componentIntf

public interface [[name(e)]]Local extends EJBLocalObject {[[∀m ∈ entityMethods(e) apply 7→methodIntf (m)]][[∀a ∈ entityAttributes(e) apply 7→attrIntf (a)]][[∀a ∈ entityAssociationEnds(e) apply 7→toOneIntf (a), 7→toManyIntf (a)]]} .

(6.4)

The name of the local interface is built from the entity’s name and the suffix“Local” and the interface is derived from the EJB base interface EJBLocalOb-

ject. The method declarations of the interface are contributed by the gener-ation rules for methods, attributes and association ends that are applied bythe rule application instructions in the template. Note that the third ruleapplication calls the two rules 7→toOneIntf and 7→toManyIntf . Each of them de-fines how the accessor methods for the different kinds of associations ends aregenerated. We differentiate association ends of multiplicity one (7→toOneIntf )and of multiplicity more than one (7→toManyIntf ). Due to the preconditions ofboth rules only one of them is applied for each association end.

A Method is transformed to a method declaration as follows

Method(m) 7→methodIntf

public [[returnType(m)]] [[name(m)]]([[parameters(m)]]);(6.5)

and for each Attribute, access methods for reading and writing the attributevalue are generated by the rule

Attribute(a) 7→attrIntf

public [[attrType(m)]] get[[firstUp3(name(m))]]();public void set[[firstUp(name(m))]]([[attrType(m)]] value); .

(6.6)

As mentioned above, there are two different transformation rules for asso-ciation ends. For“to one”association ends, two access methods are generatedfor reading and writing the association end are created as follows.

toOne(a) 7→toOneIntf

public [[assocEndType(a)]] get[[firstUp(name(a))]]();public void set[[firstUp(name(a))]]([[assocEndType(a)]] value);

(6.7)

3firstUp transforms the given string to start with an upper case.

79

In contrast, three access methods are generated for a “to many” associa-tion end: for reading the value, adding new references to the association end,and removing existing references.

toMany(a) 7→toManyIntf

Collection get[[firstUp(name(a))]]();void addTo[[firstUp(name(a))]]([[assocEndType(a)]] ref);void removeFrom[[firstUp(name(a))]]([[assocEndType(a)]] ref);

(6.8)

EJB Class The EJB class of an entity bean contains a method stub foreach entity method. For each attribute and association end of the entity,corresponding abstract and completely implemented methods are generated.Additionally, there is a method stub corresponding to the factory declaredin the EJB home interface and standard methods whose implementation isrequired by the EJB framework, e.g. a remove method. The overall structureof the bean implementation class is generated by the following rule.

Entity(e) 7→ejbClass

public abstract class [[name(e)]]Bean implements EntityBean {public [[dftKeyType()]] ejbCreate() throws CreateException {. . .}public void ejbRemove() {}. . .[[∀m ∈ entityMethods(e) apply 7→methodStub (m)]][[∀a ∈ entityAttributes(e) apply 7→attrImpl(a)]][[∀a ∈ entityAssociationEnds(e) apply 7→toOneImpl (a), 7→toManyImpl (a)]]}

(6.9)

Each Method of the entity is translated to a method stub as follows

Method(m) 7→methodStub

public [[returnType(m)]] [[name(m)]]([[parameters(m)]]){}(6.10)

and for each Attribute two abstract methods for reading and writing the at-tribute value are generated by the rule

Attribute(a) 7→attrImpl

public abstract [[attrType(a)]] get[[firstUp(name(a))]]();public abstract void set[[firstUp(name(a))]]([[attrType(a)]] value); .

(6.11)

This style of method definition is dictated by the EJB standard for entitybeans with container managed persistence. It allows the container to providedifferent implementations for the accessor methods optimized for differentdatabase type, e.g. relational or object-oriented databases.

80

The code generated for association ends of multiplicity one looks similar

toOne(a) 7→toOneImpl

public abstract [[assocEndType(a)]] get[[firstUp(name(a))]]();public abstract void set[[firstUp(name(a))]]([[assocEndType(a)]] value); .

(6.12)

The implementation of “to many” association ends is created by the fol-lowing rule.

toMany(a) 7→toManyImpl

public abstract Collection get[[firstUp(name(a))]]();public abstract void set[[firstUp(name(a))]](Collection param);void addTo[[firstUp(name(a))]]([[assocEndType(a)]] ref) {

get[[firstUp(name(a))]]().add(ref);}public void removeFrom[[firstUp(name(a))]]([[assocEndType(a)]] ref) {get[[firstUp(name(a))]]().remove(ref);

}

(6.13)

First, it generates two abstract methods for reading and writing the con-tents of the association ends as a collection. Furthermore, two methods aregenerated for adding and removing single object references, which are imple-mented on top of this abstract methods.

6.2.2 Generating Access Control Infrastructures

The design of a transformation function that translates security design mod-els based on SecureUML to access control infrastructures is affected by severalrequirements.

To begin with, the behavior of the generated infrastructure must be se-mantically equivalent to the semantics of access control of the correspondingsecurity design model. Thus we have to consider the base transformationfunction that translates the protected resources of the model, e.g. attributes,to elements of the target environment, e.g. access methods, and we need tofind a complementary mapping from actions in the model to protectable ele-ments in the target system. For example, we can map the action read of anattribute to its get-method in the EJB system.

Based on this mapping from action to elements in the target system, wethen stipulate how an access control policy is enforced in the target system.This aspect of the transformation function depends on the access controlmechanisms that are provided by the target platform. For example as ex-plained in subsection 2.4.1, EJB provides the two mechanisms declarativeand programmatic access control.

81

Furthermore, access control is a performance critical aspect because itis performed on each invocation of a protected resource. Thus we want togenerate access control infrastructures that are as fast as possible.

In the following we explain how we account for these requirements.

Overview

Given a security design model, our transformation function generates an EJBsecurity infrastructure based on declarative and programmatic access control.

For each role, a corresponding XML element of type security-role is gen-erated. Each permission is translated into an equivalent XML element oftype method-permission, used in the deployment descriptor for the declarativeaccess control of EJB. The resulting access control configuration enforces thestatic part of an access control policy (cf. Section 4.4), without consideringthe authorization constraints. Note that since the default behavior of bothComponentUML and the EJB access control monitor is “access allowed”, wedo not need to consider actions without permissions in the generation process.

Programmatic access control is used to enforce the authorization con-straints. For each method that is restricted by at least one permission withan assigned authorization constraint, a proxy method is generated that per-forms an access control check and subsequently forwards authorized calls tothe original method.

The question might arise why we use both declarative and programmaticaccess control to protect EJB methods. This question is justified because pro-grammatic access control offers a functional super-set of declarative accesscontrol. As we have learned during our case study, the typical access con-trol policy only restricts a few methods with constraints. All other methodscan completely be protected with the declarative mechanism. Furthermore,declarative access control is performed by the EJB container prior the ac-tivation of an EJB component instance. Thus declarative access control ismore efficient than programmatic access control in terms of both executiontime and memory footprint.

In order to realize the transformation function for access control, we needto extend the existing basic generation function for EJB (cf. subsection 6.2.1).To begin with, we extend the basic function 7→ejbDesc (cf. Rule 6.1 on page78) that creates the EJB deployment descriptor to call the new functionsfor generating security-role and method-permission elements. Furthermore, therules for generating the EJB class (cf. Rules 6.9 to 6.13 on the pages 80f)are adapted to use a new naming scheme and to include our rules for proxymethod generation.

Note that we do not specify generation rules for users and user-role as-

82

signments because there is no standardized syntax in EJB for specifying thisinformation. Conceptually, the mapping is straightforward: for each user oruser-role assignment an equivalent element is created in the security policydomain.

Roles

Each role in a model is mapped to a XML element of type security-role inthe deployment descriptor. We therefore add a new rule application to thetransformation rule 7→ejbDesc (cf. Rule 6.1) as shown by the following.

ModelComponentUML(m) 7→ejbDesc

<ejb-jar><enterprise-beans>[[∀e ∈ Entity apply 7→entityDef (e)]]</enterprise-beans><assembly-descriptor>[[∀r ∈ Role apply 7→roleDef (r)]]

. . .</assembly-descriptor></ejb-jar>

(6.14)

The instruction in line 6 applies the rule 7→roleDef to each role in the model,which is specified as

Role(r) 7→roleDef

<security-role><role-name>[[name(r)]]</role-name>

</security-role> .(6.15)

Applying this transformation rule to our example model yields the followingrole definitions.

<security-role><role-name>User</role-name>

</security-role><security-role><role-name>Supervisor</role-name>

</security-role>

Permissions

Each permission in a ComponentUML model is translated to an elementof type method-permission in the deployment descriptor. To integrate thegeneration of permission elements in the overall generation process, we addan instruction to 7→ejbDesc (line 7) that causes the application of the rule7→methodPermission to each permission in the model.

83

ModelComponentUML(m) 7→ejbDesc

<ejb-jar><enterprise-beans>[[∀e ∈ Entity apply 7→entityDef (e)]]</enterprise-beans><assembly-descriptor>[[∀r ∈ Role apply 7→roleDef (r)]][[∀p ∈ Permission apply 7→methodPermission (p)]]</assembly-descriptor></ejb-jar> .

(6.16)

The transformation rule 7→methodPermission is specified as

Permission(p) 7→methodPermission

<method-permission>[[∀r ∈ Role : (p, r) ∈ PAExpanded apply 7→roleName (r)]][[∀a ∈ AtomicAction : (p, a) ∈ AAAtomic apply 7→entityCreate (a),7→entityDelete (a), 7→methodExecute (a), 7→attrRead (a), 7→attrUpdate (a),7→assocEndRead (a), 7→toOneUpdate (a), 7→toManyUpdate (a)]]</method-permission> .

(6.17)

As explained in Section 2.4.1, a method permission element names a setof roles and a set of EJB methods that these roles are allowed to access.Generating a method permission is therefore split into two parts: generatinga set of roles (first rule application) and assigning methods to them (secondrule application). In the following, we explain both rule applications and givethe definitions of the relations PAExpanded and AAAtomic.

Role References Since EJB does not support role hierarchies, we needto resolve these hierarchies in the generated infrastructure. We do this byexpanding the assignment of roles to permissions PA, i.e. a permission isassigned to each role in PA and all of their subroles under ≥Role . Formallyspeaking, we define an auxiliary relation PAExpanded ⊆ Permission × Role as

PAExpanded :=≥Role ◦PA . (6.18)

and specify in the first rule application of 7→methodPermission that the rule

Role(r) 7→roleName <role-name>[[name(r)]]</role-name> (6.19)

is applied to a role r ∈ Role if and only if (p, r) ∈ PAExpanded .Performing this generation procedure on the permission OwnerMeeting in

our example results in the following two role references.

<role-name>User</role-name><role-name>Supervisor</role-name>

84

rule # resource type action EJB methods

1 Entity create factory method2 Entity delete remove methods in component

and home interface3 Method execute corresponding method4 Attribute read get-method of the attribute5 Attribute update set-method of the attribute6 AssociationEnd read get-method of the association end7 AssociationEnd update to one: set-method of the

association endto many: add- and remove-methodsof the association end

Table 6.1: Atomic action to method mapping for EJB

EJB Methods The resource and action model of EJB is simple, there isonly one resource type EJB method with a single action execute. The securitydesign language ComponentUML is more complex and we define the followingmapping: Each atomic action in ComponentUML corresponds to one or moreEJB methods. An overview of this correspondence is given in Table 6.1. Foreach atomic action there is a transformation rule that translates the actioninto an equivalent set of method elements. The following is the rule for theaction create on an entity4

EntityCreate(a) 7→entityCreate

<method><ejb-name>[[actionBeanName(a)]]</ejb-name><method-intf>LocalHome</method-intf><method-name>create</method-name><method-params/>

</method>

(6.20)

In contrast, composite actions do not have direct counterparts in thegenerated infrastructure. We instead expand the action assignment relationAA, i.e. a method element is created for all methods corresponding to anatomic action if a permission is assigned to the action or one of its super-actions in ≥Action .

We introduce the relation AAExpanded ⊆ Permission × Action as

AAExpanded :=≥Action ◦AA , (6.21)

and define AAAtomic ⊆ Permission×AtomicAction as sub relation of AAExpanded

AAAtomic := {(p, a) ∈ AAExpanded | a ∈ AtomicAction} . (6.22)

4The rules for all atomic actions are given in Appendix A.2.

85

Furthermore, we stipulate in the second rule application of 7→methodPermission

that the generation rules for atomic actions is applied for each atomic actiona if and only if (p, a) ∈ AAAtomic. Due to the preconditions defined for eachof the transformation rules, exactly one of them is applied on each action a.Applying this generation rule to the permission UserMeeting results in thefollowing XML code fragment.<method>

<ejb-name>Meeting</ejb-name>

<method-intf>Local</method-intf>

<method-name>create</method-name>

<method-params/>

</method>

<method>

<ejb-name>Meeting</ejb-name>

<method-intf>Local</method-intf>

<method-name>getStart</method-name>

<method-params/>

</method>

<method>

<ejb-name>Meeting</ejb-name>

<method-intf>Local</method-intf>

<method-name>getDuration</method-name>

<method-params/>

</method>

<method>

<ejb-name>Meeting</ejb-name>

<method-intf>Local</method-intf>

<method-name>getOwner</method-name>

<method-params/>

</method>

<method>

<ejb-name>Meeting</ejb-name>

<method-intf>Local</method-intf>

<method-name>getLocation</method-name>

<method-params/>

</method>

<method>

<ejb-name>Meeting</ejb-name>

<method-intf>Local</method-intf>

<method-name>getParticipants</method-name>

<method-params/>

</method>

Generating Assertions

The generated infrastructure checks authorization constraints using asser-tions based on the EJB API for programmatic access control. Since we wantto separate the assertion code from the other implementation code of a beanmethod, we use a delegation pattern. We rename the original EJB meth-ods and generate additional proxy methods with the original method names.Such a proxy method checks authorization constraints using access controlassertions and subsequently delegates authorized calls to its correspondingoriginal method. Denial of access is signaled to the caller by throwing an ex-ception. To achieve this goal we adapt the basic transformation functions forgenerating the entity bean class (7→ejbClass (6.9), 7→methodStub (6.10), 7→attrImpl

(6.11), 7→toOneImpl (6.12), and 7→toManyImpl (6.13)) and we introduce new rules.

Determining the Permissions In order to generate the assertions, wefirst need to determine the permissions that are assigned to an EJB methodby the security design model. We therefore map each EJB method to oneaction in the ComponentUML model and use this action to determine thepermissions.

Recall that according to the Table 6.1 given in Section 6.2.2, each atomicaction in the model is related to one or more EJB methods. The inverserelation of this relation is a function that maps each EJB method to one

86

atomic action, its so-called peer action. The set of permissions assigned tothis action is used when generating assertions on the corresponding EJBmethods.

As a subtle technical problem we cannot simply use an EJB method objectand lookup a table to retrieve the action corresponding to the method becausewe do not have an EJB method object at generation time. What we know are(1) the model element for which source code is generated by a transformationrule, e.g. an attribute, and (2) the type of EJB method that is generated,e.g. the get-method of this attribute.

We use this information and the rules given in Table 6.1 to determinethe peer atomic action a. For example, the corresponding action of the get-method of the attribute duration of the entity Meeting is the action readon duration.

In the generation rules, this mapping is formalized by one auxiliary func-tion per type of EJB method, e.g. the function

actionForAttributeGetter : Attribute → AtomicAction ,

maps an attribute to the action corresponding to the attribute’s get-method.

Then, using this action a, the set of permissions AP(a) that affect theexecution of an action is

AP(a) := {p ∈ Permission | (p, a) ∈ AAAtomic} . (6.23)

Changing the Naming Scheme We change the basic transformationrules for generating methods in the EJB class to prefix all method nameswith a leading “ ”. The following example illustrates this on the transforma-tion rule for creating attribute methods (cf. Rule 6.11).

Attribute(a) 7→attrImpl

public abstract [[attrType(a)]] _get[[firstUp(name(a))]]();public abstract void _set[[firstUp(name(a))]]([[attrType(a)]] value);

(6.24)

Proxy Generation For each of these adapted rules (e.g. Rule 6.24), weintroduce a new transformation rule that creates proxy methods with theoriginal names of its corresponding methods. The rule for generating proxymethods for attributes is as follows.

87

Attribute(a) 7→attrProxy

public [[attrType(a)]] get[[firstUp(name(a))]]() {[[apply 7→assertion (actionForAttributeGetter(a))]]return _get[[firstUp(name(a))]]();

}public void set[[firstUp(name(a))]]([[attrType(a)]] value) {

[[apply 7→assertion (actionForAttributeSetter(a))]]_set[[firstUp(name(a))]](value);

}

(6.25)

The implementations of these proxy methods are similar for all typesof model elements (methods, attribute, association end) and EJB methods(e.g. set- and get-methods). It therefore suffices to give an explanation forone type of proxy method and we take the example of get-method proxiesfor attributes.

The rule application in the second line of the template applies the trans-formation rule 7→assertion to the peer action of the attribute’s get-method,which is obtained using the function actionForAttributeGetter . And the in-struction in the following line creates the code to delegate authorized callsto the original method.

The generation rule 7→assertion creates the assertion code for an atomicaction and is specified as

AtomicAction(a) 7→assertion

boolean accessAllowed = false;[[∀p ∈ AP(a) apply 7→unconstrPerm (p), 7→constrPerm (p)]]if (!accessAllowed) throw new AccessControlException("access denied");

(6.26)

The first line defines the variable accessAllowed, which represents the accesscontrol decision of the method, and initializes this variable to false.

The rule application in the next line of the template causes the generationof Java code for each permission in the set AP . The kind of code generateddepends on whether the permission is restricted by an authorization con-straint. Each of the generated code blocks may set the value of the variableaccessAllowed to true (The value may never revert to false).

The last line of the generated source code throws an exception of typeAccessControlException if accessAllowed is still false, i.e. access is denied for thecurrent caller on the EJB method.

Each unconstrained permission is translated by the transformation rule7→unconstrPerm that is specified as follows.

UnconstrainedPermission(p) 7→unconstrPerm

accessAllowed = accessAllowed || [[roleCheck(p)]];(6.27)

88

The first part of the generated expression prevents resetting accessAllowed.The second part of the Java expression, which is denoted by the function

call roleCheck(p), consists of disjunctively conjoined checks of whether thecurrent caller is in one of the roles assigned to the permission in the rela-tion PAExpanded . The role checks are implemented using the EJB API forprogrammatic access control as shown by the following Java code fragment.

accessAllowed = accessAllowed || ctx.isCallerInRole(”Supervisor”);

For each constrained permission p in AP(a), we generate Java code withthe following structure.

ConstrainedPermission(p) 7→constrPerm

if (!accessAllowed && ([[roleCheck(p)]])){try{accessAllowed = [[constraintExpression(p)]];

}catch(Throwable ex){. . .}

}

(6.28)

First, this code checks whether access has already been granted by a previ-ously executed statement in the proxy method.

Second, there is a check if the current caller is in one of the roles assignedto the permission in the relation PAExpanded . If so, the constraint assignedto p is evaluated as a Java expression that is generated by the functionconstraintExpression. The result of the evaluation is assigned to accessAl-

lowed.Note that the constraint check is surrounded by a try/catch clause that

catches any exception thrown during evaluation. This ensures the robustnessof the generated code even in illegal system states. accessAllowed stays falsein case of an exception.

An authorization constraint, defined in OCL, is translated into an equiv-alent Java expression. The symbol caller is translated into the expressionctx.getCallerPrincipal.getName(). Access to methods, attributes, andassociation ends respects the rules that are applied to generate the respectivecounterparts of these elements, given in Section 6.2.1. For example, accessto the value of an attribute name is translated to a call of the correspond-ing read method getName. The OCL equality operator is translated into theJava method equals for objects or into Java’s equality operator for primitivetypes. The complete transformation function from OCL to Java is given inthe appendix A.3.

Applying the generation rules explained in the previous paragraphs to themethod cancel of the entity Meeting results in the following Java code.

89

public void cancel(){boolean accessAllowed = false;accessAllowed = accessAllowed || ctx.isCallerInRole("Supervisor");if (!accessAllowed && (ctx.isCallerInRole("User") ||

ctx.isCallerInRole("Supervisor"))){try{accessAllowed =

ctx.getCallerPrincipal().getName().equals(getOwner());}catch(Throwable ex){. . .}}if (!accessAllowed) throw new AccessControlException("Access denied");_cancel();}

Integration In order to integrate the new transformation rules, we changethe basic transformation rule Entity(e) 7→beanClass so that it also applies thenew rules.

Entity(e) 7→beanClass

public abstract class [[name(e)]]Bean implements EntityBean {. . .[[∀m ∈ methods(e) apply 7→methodStub (m), 7→methodProxy (m)]][[∀a ∈ attributes(e) apply 7→attrImpl (a), 7→attrProxy (a)]][[∀a ∈ associationEnds(e) apply 7→toOneImpl (a), 7→toOneProxy (a),7→toManyImpl (a), 7→toManyProxy (a)]]}

(6.29)

Comparing the transformation function for EJB to Equation (4.4) onpage 61, which defines φAC (u, a) in Section 4.4, reveals the following differ-ences and similarities: Both are essentially conjunctions over all permissionsdirectly or indirectly assigned to an action. Equation (4.4) considers the per-missions for a particular user, whereas the EJB assertion generates checksfor all permissions on the action. The former is clearly a sub set of the latter.The difference is caused by the different goals for φAC (u, a) and the EJBassertion. φAC (u, a) gives the semantics for a particular user on a particularaction in a convenient and readable way. Using the same approach for theruntime enforcement of access control in the EJB system is impossible be-cause this would require one to know all users of a system at developmenttime.

Instead, we consider all the permissions for all roles of a system in thegenerated code and filter their applicability to a user by using the role as-signments at runtime. If a particular user u calls a method at runtime, onlythe permissions applicable to u are evaluated, the remaining permissions are

90

automatically omitted by the role checks. So the set of permissions evaluatedis equivalent to the set of permissions evaluated by φAC (u, a).

6.3 Correctness of Generation

A transformation is correct, if both the source model and the generatedtarget system have an equivalent behavior. In our case this means, that thebehavior of the generated access control infrastructure must be equivalent tothe semantics of access control of the corresponding security design model.This means that if a user u is granted access to an action a in the securitydesign model than u must have access to the EJB methods corresponding toa and if the user u has access to a method m in the EJB system then theremust be at least one corresponding action a′ in the security design model towhich u has access.

As stated in Section 3.3, judging the correctness of the transformationprocess requires a formal semantics for the targeted security architecture. Inthe following we first give an informal semantics of the security architectureof EJB, which we further formalize in Section 6.4. Afterwards, we explainwhy systems that are generated according to the rules given in the previoussection actually implement the access control policy that is defined by theformal semantics of SecureUML.

As an example of a formal verification, we give a proof of the correctnessof the sub-function for transforming ComponentUML models to an infras-tructure for declarative access control in EJB in Section 6.4.

6.3.1 Informal Semantics of EJB Access Control

For EJB, the protected resources are given by the set of the methods ofthe entity beans. Each method provides the single action to “execute thismethod”, the union of which form the set of actions. Permission to performthese actions can be denied in two cases. First, if the execution of a methodis restricted by at least one method permission element in the deploymentdescriptor, a user may only execute this method if he has one of the roles listedin one of the method permission elements protecting the method. Note thatEJB does not support role hierarchies here. Second, in the body of methodsthere can be additional code whose evaluation decides if execution of thismethod is allowed, i.e., there can be an assertion of the form

if ( !<predicate> ) throw new AccessControlException("Access denied."); ,

where <predicate> is defined by the application developer. In all remainingcases, method execution is allowed.

91

6.3.2 Proof Strategy and Discussion

To argue the correctness of the generation rules with regard to an arbitraryatomic action a, we distinguish three cases:

1. There are no permissions assigned directly to a, or to an action a′ witha′ ≥Action a, in the security design model.

2. There is at least one permission assigned to a, or to an action a′ witha′ ≥Action a, in the security design model, but none of these permissionsis assigned an authorization constraint.

3. There is at least one permission assigned to a, or to an action a′ witha′ ≥Action a, in the security design model, and at least one of thesepermissions has an authorization constraint assigned.

In the first case, the generation rules generate neither a method permis-sion nor an assertion. The default behavior of ComponentUML is “accessallowed” and the EJB container allows execution of the relevant methodscorresponding to this atomic action, which is correct. The remaining casesare discussed in the following paragraphs.

Without Authorization Constraints Since there is no constraint as-signed to the permissions in the second case, we can use the static part ofthe SecureUML semantics. It specifies that access is granted to user u onaction a if and only if AC (u, a) holds, which is (cf. Section 4.4)

AC (u, a) ⇐⇒ (u, a) ∈≥Action ◦AA ◦ PA ◦ ≥Role ◦ SA ◦ ≥Subject .

This means that access is granted to user u on action a if and only if the useru is, directly or via a group membership, assigned to a role that is larger orequal to a role that has a permission to an action that is superior or equalto the action a.

We have to show that if AC (u, a) holds then user u must have accessto all EJB methods corresponding to a and that if user u is granted accessto a method m in the EJB system then there must be at least one actiona′ corresponding to m for which AC (u, a ′) holds. The key aspects in thiscontext are the hierarchies on roles and actions as well as the mapping fromactions to methods.

If AC (u, a) holds then there must be at least one permission p ∈ UAP(u, a).The generated method-permission element for p must grant a role of user uaccess to all methods resulting from the action a under the order relation

92

≥Action . However, in the generation of these method-permission elements, boththe hierarchy on roles as well as the hierarchy on actions are expanded whencalculating the set of roles and the set of methods that appear in the method-permission element and each action is mapped to its corresponding methods.This means that the method-permission that is generated for a permission pcontains the methods corresponding to the action a and contains a role thatthe user u has if and only if p ∈ UAP(u, a). We will give a formal proof forthe static part of RBAC in Section 6.4.

With Authorization Constraints In the third case, we must show thatthe generated proxy method containing the assertion delegates a call to itscorresponding original method (cf. subsection 6.2.2) if and only if φAC (u, a)evaluates to true.

As already explained in subsection 6.2.2 both φAC (u, a) and the EJB as-sertion are essentially conjunctions over all permissions directly or indirectlyassigned to an action. Equation (4.4) considers the permissions for a partic-ular user and the EJB assertion generates checks for all permissions on theaction, where the former is a sub set of the latter. However, these additionalconstraints are nullified by the role checks, which are false for permissionsthe user does not have.

Additionally, we must ensure that the terms created by the functionLOCL → LFOL and the Java expressions created by LOCL → LJava are equiv-alent. We have chosen a direct transformation from OCL to Java expressionsand assume that the Java Virtual Machine interprets them as propositionallogic. Given this assumption, the generated Java expressions are semanticallyequivalent to the terms created by LOCL → LFOL.

A subtle problem are exceptions that may be thrown during the eval-uation of the Java expressions. In such cases, the result of the affectedstatement, e.g. a method call or an boolean expression, is undefined. Thegenerated code handles exceptions by falsifying the whole constraint term,i.e. access is denied by such a term. Thus the code is robust and preventsunauthorized system access using exceptional system states, e.g. caused byprogramming errors. But what does this mean with regard to the correctnessof the transformation function?

The semantics of SecureUML cannot represent undefined system statesand we therefore cannot make formal statements about correctness of thetransformation function for undefined system states. The question is whetherit would be possible to extend the SecureUML semantics to cope with unde-fined system states and what would be the benefit of doing so?

One way could be to explicitly represent undefined in the logic as pro-

93

posed in [9]. This would allow us to give security design models a semanticsin undefined system states. As a major drawback this would make the seman-tics of SecureUML substantially more complicated and thus would contradictour aim to give software engineers, which are not necessarily formal methodsspecialists, a useful tool for developing access control architectures. There-fore, we should discuss whether we really need a semantics for access controlin undefined system states.

First of all, we need to discuss under which circumstances exceptions mayoccur during the execution of an expression generated by LOCL → LJava . Wedistinguish two cases:

1. An exception is thrown by the implementation of a method that iscalled by the generated Java expression.

2. An attempt to perform a method call on a null pointer causes a nullpointer exception.

In the first case, we have to consider side-effect free methods whose im-plementation is hand-crafted and get-methods of attributes or associationends. An exception may occur in a side-effect free method if (1) the methodimplementation is incorrect, (2) the authorization constraint violates a pre-condition of the called method, or (3) there occurred a partial system failureduring the execution of the method. Exceptions may be thrown by attributeor association end get-methods if (1) the underlying database setup is incor-rect or (2) there occurred a partial system failure during the execution of theget-method.

An examination of the second case requires us to discuss what the sourceof an object reference can be in our constraint expressions and under whichcircumstances this source could provide a null reference.

Object references in a constraint expression are obtained using the sym-bols self or caller and from method parameters, function calls, attributes, orassociation ends. self is transformed to this, which can never be null if the Javavirtual machine works correctly. caller is transformed to the Java expressionctx.getCallerPrincipal().getName() that must not return null according to theEJB specification [40]. Thus a null value may only occur in an incorrectlyimplemented EJB container.

A null reference as method parameter that causes a null pointer exceptionmay occur in two cases. (1) The value must not be null according to the sys-tem specification but is null nevertheless. This is considered a programmingerror that violates the precondition of the method for which the access con-trol condition is checked. (2) Or the parameter may be null according to thesystem specification. In this case, the authorization constraints is required

94

to explicitly check for a null value. Thus if such an error occurs then theauthorization constraint itself is considered incorrect. Both cases may alsooccur for the return value of a method call, where the first case is caused bya violation of the postconditions of the called method.

The get-method of an association end of multiplicity “0..1” may legallyreturn a null reference. This cannot cause a null pointer exception in thegenerated expressions because the return value is always transformed into acollection for further processing.

The get-method of an attribute or association end of multiplicity “1..1”may only return a null value if its invariant is violated. This can be due toa missing initialization of the corresponding fields or an incorrect implemen-tation of the underlying persistence manager.

The get-method of a “to many” association end may only return a nullpointer due to an error (state or implementation) in the underlying persis-tence manager.

To conclude our discussion: We use a restricted OCL subset for expressingauthorization constraints. And the way the Java expressions are constructedby the transformation function ensures that exceptions can only occur inillegal system states, e.g. caused by programming errors or partial systemfailures. All these states prevent the system from normal functioning andthus must be repaired. Therefore we argue that the assessment of the cor-rectness of the generated system during normal operation suffices to judgethe correctness of our generation function. Thus we exclude undefined systemstates from our consideration.

We do not give a formal proof because this would require us to formalize acomplete model of the evaluation of Java expressions and of the EJB API forprogrammatic access control and to show the equivalence of the SecureUMLand Java behavior. This is out of the scope of this thesis.

6.4 Verification of the Sub-function for Declar-

ative Access Control

In this section, we give an example of how the correctness of a transformationfunction can be proven. We have chosen the sub-function for generating andeclarative access control infrastructure for EJB from ComponentUML forthis purpose.

We have specified the transformation function in Section 6.2 as a trans-lation from models in the abstract syntax of ComponentUML to Java andXML code. In order to conduct the proof, we need to further formalize this

95

definition to be based on formal models of both the source and the target ofthe transformation. We require a formal semantics of access control for bothparts.

The formal semantics of access control of SecureUML has been given inSection 4.4 and this semantics also holds for ComponentUML. We thereforestart by introducing a mathematical model of the EJB platform and define aformal semantics of EJB declarative access control. Afterwards, in 6.4.2, werecall the transformation function and formalizes those parts that are neededfor the proof. We give the proof in Section 6.4.3 and discuss the proof as wellas the approach in general afterwards.

6.4.1 EJB Declarative Access Control

We intend to give a model of the EJB access control that is both sufficient forformalizing the transformation function and as simple as possible. Our modelmust capture the semantics of declarative access control and this kind ofaccess control is enforced outside of the EJB components. We therefore modelEJB components as opaque building blocks with one or more methods, whichare under the control of an access control monitor. We neither distinguishthe different interfaces of an EJB nor do we consider the bean class.

The core of our model of EJB consist of the sets EJB and MethodEJB,representing EJB components and their methods. Each EJB can have oneor more methods, which is formalized by the function

EJBMethod : EJB → 2MethodEJB ,

which maps every EJB to its methods.The role-based access control mechanism of EJB is used to determine

the authorization of users to execute methods on EJB’s. The access con-trol model consist of the sets SubjectEJB , UserEJB , GroupEJB , RoleEJB , andPermissionEJB , representing the users, groups, roles and method permissionsin an EJB system. Note that SubjectEJB := GroupEJB ∪ UserEJB . We alsohave the following relations

• SGEJB ⊆ SubjectEJB ×GroupEJB ,

• SAEJB ⊆ SubjectEJB × RoleEJB ,

• PAEJB ⊆ RoleEJB × PermissionEJB ,

• MA ⊆ PermissionEJB ×MethodEJB ,

and the partial order ≥SubjectEJBthat is given by the reflexive, transitive

closure of the relation SGEJB and formalizes that a group is larger than allits contained subjects.

96

In this setup, access is allowed for a user u on method m if and only ifthe predicate AC EJB(u,m) holds, which is

AC EJB(u,m) ⇐⇒ (u, m) ∈ MA ◦ PAEJB ◦ SAEJB ◦ ≥SubjectEJB. (6.30)

This means that access is granted to u if and only if u is directly or via groupmembership in a role that has a permission on the method m.

6.4.2 Model Transformation Function

The transformation function for declarative access control extends the basictransformation function from ComponentUML models to EJB systems. Westart by formalizing the basic function as far as it is required for the for-malization of the transformation function from ComponentUML models todeclarative access control infrastructures, which is given afterwards.

Basic function This formalization is based on the specification given inSection 6.2.1. To begin with, the set EJB is identified with the set Entity .Additionally, for each entity there is a factory and a remove method, whichis specified by the functions

• entityFactory : Entity → MethodEJB and

• entityRemoveMethod : Entity → MethodEJB .

The generation rules for the attributes, association ends, and methods areformalized as follows. We partition the set AssociationEnd into the subsetsToOne and ToMany

ToOne := {a ∈ AssociationEnd | ¬isToMany(a)} ,

ToMany := {a ∈ AssociationEnd | isToMany(a)} ,

and declare the following functions, which map the model elements to theircorresponding EJB methods:

• attributeGetMethod : Attribute → MethodEJB

• attributeSetMethod : Attribute → MethodEJB

• assocGetMethod : AssociationEnd → MethodEJB

• toOneSetMethod : ToOne → MethodEJB

• toManyAddMethod : ToMany → MethodEJB

• toManyRemoveMethod : ToMany → MethodEJB

• method : Method → MethodEJB .

97

Declarative Access Control Based on the basic transformation function,we now formalize rules for generating infrastructures for declarative accesscontrol. To begin with, we identify the following sets and relations:

GroupEJB := Group,

UserEJB := User ,

RoleEJB := Role,

SGEJB := SG ,

SAEJB := SA,

PermissionEJB := Permission ,

(6.31)

which also implies

≥SubjectEJB=≥Subject . (6.32)

As explained in Section 6.2.2, the assignment of roles to permissionsPAEJB is determined from PA under consideration of ≥Role . The role hi-erarchy in the model is resolved by assigning every role in the EJB systemthe permissions of this role in the model and additionally all permissions ofits super-roles. This is formalized as

PAEJB := PAExpanded := PA ◦ ≥Role . (6.33)

The assignment of methods to permissions MA is generated based onthe expanded and filtered action assignment AAAtomic and the mapping fromatomic actions to EJB methods. We have given a partial formalization forthis transformation in Section 6.2.2. Now that we have a formal model ofEJB security, we can give the transformation function more precisely.

First, we introduce the relation AA2M ⊆ AtomicAction × MethodEJB ,which formalizes the mapping from atomic actions to EJB methods as de-scribed in Section 6.2 by the Table 6.1 and is given by

AA2M :=EntityCreate ∪ EntityDelete ∪ AttributeRead ∪AttributeUpdate ∪ AssociationEndRead ∪ ToManyUpdate ∪ToOneUpdate ∪MethodExecute .

(6.34)

98

The definitions of the sets are as follows

EntityCreate := {((create, e), m) ∈ AtomicAction ×MethodEJB |e ∈ Entity ∧m = entityFactory(e)}

EntityDelete := {((delete, e), m) ∈ AtomicAction ×MethodEJB |e ∈ Entity ∧m = entityRemoveMethod(e)}

AttributeRead := {((read , a), m) ∈ AtomicAction ×MethodEJB |a ∈ Attribute ∧m = attributeGetMethod(a)}

AttributeUpdate := {((update, a), m) ∈ AtomicAction ×MethodEJB |a ∈ Attribute ∧m = attributeSetMethod(a)}

AssociationEndRead := {((read , a), m) ∈ AtomicAction ×MethodEJB |a ∈ AssociationEnd ∧m = assocGetMethod(a)}

ToManyUpdate := {((update, a), m) ∈ AtomicAction ×MethodEJB |a ∈ ToMany ∧m ∈ {toManyAddMethod(a),

toManyRemoveMethod(a)}}ToOneUpdate := {((update, a), m) ∈ AtomicAction ×MethodEJB |

a ∈ ToOne ∧m = toOneSetMethod(a)}MethodExecute := {((execute, e), m) ∈ AtomicAction ×MethodEJB |

a ∈ Method ∧m = EJBMethod(m)}(6.35)

In the next step, we define MA as

MA := AA2M ◦ AAAtomic . (6.36)

Finally, we introduce the auxiliary relation A2M ⊆ Action ×MethodEJB

that maps every actions to its corresponding EJB methods as

A2M := {(a, m) ⊆ Action ×MethodEJB |∃ a′ ∈ AtomicAction : (a′, m) ∈ AA2M ∧ a ≥Action a′} .

(6.37)

6.4.3 Proof

A semantically preserving transformation must result in an equivalent be-havior of both the source and the target model. Thus a straightforwardapproach to specifying the transformation correctness would be to formalizethe theorem statement as the equivalence

∀u, a, m : (AC (u, a) ∧ (a, m) ∈ A2M ⇐⇒ AC EJB(u, m)) . (6.38)

99

This states that a user u is granted access to an action a in the security designmodel and the method m corresponds to a in A2M if and only if the user uis also granted access to m in the EJB system. This sounds sensible, but themeaning of the only if direction is that if a user u is granted access to m inthe EJB system then, in the model, access must be granted to every actioncorresponding to m in A2M . This does not always hold, since a permissioncan be defined for a role on an atomic action, which by no meaning grantsthe role access to the super-actions of a.

Therefore, we conduct the correctness proof in two steps. First, we willshow the correctness of the transformation for atomic actions by proving anrestricted form of (6.38), namely

∀u, m : (∃a ∈ AtomicAction :

AC (u, a) ∧ (a, m) ∈ AA2M ⇐⇒ AC EJB(u, m)) .(6.39)

The major difference to (6.38) is in the meaning of the only if direction. Itstates that if user u is granted access to the EJB method m then there existsan atomic action a in the security design model that corresponds to m inAA2M and for which user u is granted access.

In the second step, it remains to show that the action hierarchy is resolvedcorrectly by the transformation function. We derive the following implicationfrom the Formula 6.38

∀u, a, m : (AC (u, a) ∧ (a, m) ∈ A2M ⇒ AC EJB(u, m)) , (6.40)

meaning if user u is granted access to an action a in the model and m cor-responds to a in A2M than u must be granted access to m. Inspecting theFormula 6.39 reveals that it suffices to show the following corollary of (6.39)

∀u, a, m : (AC (u, a) ∧ (a, m) ∈ A2M ⇒∃a′ ∈ AtomicAction : AC (u, a′) ∧ (a′, m) ∈ AA2M ) .

(6.41)

Model to EJB We start by proving the if direction of the Formula 6.39.So given arbitrary u and m we assume

∃a ∈ AtomicAction : AC (u, a) ∧ (a, m) ∈ AA2M , (6.42)

and it remains to proveAC EJB(u, m) . (6.43)

We first expand AC (u, a) (cf. Formula 4.1 on page 59)

∃a ∈ AtomicAction :

((u, a) ∈≥Action ◦AA ◦ PA ◦ ≥Role ◦ SA ◦ ≥Subject) ∧ (a, m) ∈ AA2M(6.44)

100

and replace ≥Action ◦AA by AAExpanded (cf. Formula 6.21 on page 85)

∃a ∈ AtomicAction :

((u, a) ∈ AAExpanded ◦ PA ◦ ≥Role ◦ SA ◦ ≥Subject) ∧ (a, m) ∈ AA2M .(6.45)

Now, we replace AAExpanded by AAAtomic and start by expanding the firstrelational composition

∃a ∈ AtomicAction, p ∈ Permission :

(u, p) ∈ (PA ◦ ≥Role ◦ SA ◦ ≥Subject)∧(p, a) ∈ AAExpanded ∧ (a, m) ∈ AA2M .

(6.46)

From the definition of AAAtomic we know for every permission p and action a

(p, a) ∈ AAExpanded ∧ a ∈ AtomicActions ⇐⇒ (p, a) ∈ AAAtomic , (6.47)

thus we can directly substitute AAExpanded by AAAtomic

∃a ∈ AtomicAction, p ∈ Permission :

(u, p) ∈ (PA ◦ ≥Role ◦ SA ◦ ≥Subject)∧(p, a) ∈ AAAtomic ∧ (a, m) ∈ AA2M .

(6.48)

However, using the definition of relational composition this is equivalent to

(u, m) ∈ AA2M ◦ AAAtomic ◦ PA ◦ ≥Role ◦ SA ◦ ≥Subject . (6.49)

Now we introduce the definitions of MA, PAEJB , SAEJB , and ≥SubjectEJB

(cf. Formulae 6.36, 6.33, 6.31, 6.32)

(u, m) ∈ MA ◦ PAEJB ◦ SAEJB ◦ ≥SubjectEJB. (6.50)

According to the definition in Formula 6.30 this is AC EJB(u, a). q.e.d.

EJB to Model In the next step, we prove the only if direction of theFormula 6.39. So given arbitrary u and m we assume

AC EJB(u, m) , (6.51)

and it remains to prove

∃a ∈ AtomicAction : AC (u, a) ∧ (a, m) ∈ AA2M . (6.52)

We first expand AC EJB (cf. Formula 6.30)

(u, m) ∈ MA ◦ PAEJB ◦ SAEJB ◦ ≥SubjectEJB, (6.53)

101

and apply the definitions of MA, PAEJB , SAEJB , and ≥SubjectEJB

(u, m) ∈ AA2M ◦ AAAtomic ◦ PA◦ ≥Role ◦ SA ◦ ≥Subject . (6.54)

Then, we expand the last relational composition

∃a ∈ AtomicAction :

(u, a) ∈ AAAtomic ◦ PA◦ ≥Role ◦ SA ◦ ≥Subject ∧(a, m) ∈ AA2M ,(6.55)

replace AAAtomic by AAExpanded (cf. Formula 6.47)

∃a ∈ AtomicAction :

(u, a) ∈ AAExpanded ◦ PA◦ ≥Role ◦ SA ◦ ≥Subject ∧(a, m) ∈ AA2M ,(6.56)

and introduce the definition of AAExpanded

∃a ∈ AtomicAction :

(u, a) ∈≥Action ◦AA ◦ PA◦ ≥Role ◦ SA ◦ ≥Subject ∧(a, m) ∈ AA2M ,(6.57)

Applying the definition of AC (u, a) yields

∃a ∈ AtomicAction : AC (u, a) ∧ (a, m) ∈ AA2M . (6.58)

q.e.d.

Action Hierarchy Finally, we now prove the Formula 6.41. So givenarbitrary u, a, and m we assume

AC (u, a) ∧ (a, m) ∈ A2M . (6.59)

By definition of A2M (cf. Formula 6.37), this implies

AC (u, a) ∧ ∃a′ ∈ AtomicActions : (a′, m) ∈ AA2M ∧ a ≥Action a′ , (6.60)

and pulling the existential quantification outwards and reordering yields

∃a′ ∈ AtomicActions : AC (u, a) ∧ a ≥Action a′ ∧ (a′, m) ∈ AA2M . (6.61)

From the definition of AC (cf. Formula 4.1) and because of the transitivityof the order relation ≥Action we know

AC (u, a) ∧ a ≥Action a′ ⇒ AC (u, a′) . (6.62)

Together (6.61) and (6.62) entail

∃a′ ∈ AtomicActions : (a′, m) ∈ AA2M ∧ AC (u, a′) . (6.63)

q.e.d.

102

6.4.4 Discussion

In this section, we discuss what we have proven and what it really means.

To begin with, we have proven that the specification of our transforma-tion function is correct. We did not prove that the implementation of thetransformation function in a generator works correct. This can be achievedby another verification. As an alternative to further correctness proofs, testscan show the correct function of the generator for a set of test cases. Weused tests during the implementation of our prototype.

Next, a correctness proof shows the correctness of the transformationregarding the chosen proof objectives. This objectives represent the mentalmodel of a correct transformation of the specifier of the proof objectives, nomore or less. The definition of proof objectives is a creative task formalizingan intuition of correctness. If all involved parties agree on such an objectiveit becomes a powerful foundation for their cooperation. In the same way asthe formal semantic of a modeling language gives models a precise meaning,a proof objective is the formalization of the semantics of a transformationfunction.

An analysis of the proof shows that the definition of the mapping fromatomic actions to EJB methods AA2M does not affect the correctness ofthe transformation function at all. At this level, this mapping is arbitrary.But the definition of AA2M is a specification of the expected behavior ofthe generator for its implementer. Thus tests of the generator should includecorresponding test cases.

6.5 Transformation Function for .NET Sys-

tems

One of the advantages of Model Driven Security is that by implementingdifferent transformation functions one can generate security architectures fordifferent platforms. Here we consider generating secure applications basedon the programming language C# and the Enterprise Services for .NET,described in Section 2.4.2. Rather than presenting this translation in detail,we focus on the main conceptual differences to the EJB translation.

6.5.1 Basic Generation Rules for .NET

An Entity of ComponentUML is transformed into a serviced component ofthe enterprise services. The generated component consists of an interface

103

and an implementation class; a default constructor is generated as well. Thegeneration rules are

Entity(e) 7→dotnetIntf

public interface I[[name(e)]]Interface {. . .}(6.64)

Entity(e) 7→dotnetImpl

public class [[name(e)]] : ServicedComponent, I[[name(e)]]Interface {public [[name(e)]](){. . .}. . .}

(6.65)

Methods and association ends are transformed to access methods andmembers as described in Section 6.2. Attributes are handled differently; foreach attribute a C# property is added to the interface and the implementa-tion class. The property declaration is created by the rule

Attribute(a) 7→dotnetAttrImpl

[[attrType(a)]] [[name(a)]] {get;set;} .

(6.66)

6.5.2 Generating Access Control Infrastructures

In contrast to the EJB generation, the transformation of permissions is“method-centric” because access restrictions are defined in .NET using Se-

curityRole attributes in the component source code (cf. Section 2.4.2). Suchan attribute is created by the following rule

Role(r) 7→dotnetSecurityRole [SecurityRole("[[name(r)]]")] (6.67)

A SecurityRole attribute must be generated for each role that is allowed toexecute a .NET method. First, the peer action a corresponding to a .NETmethod is determined in the same way as explained in Section 6.2.2.

Afterwards, the set of roles AR(a) that are allowed to access an action isdetermined by

AR(a) := {r ∈ Role | (a, r) ∈ PAExpanded ◦ AAAtomic} , (6.68)

i.e. a role r is in the set if there is a permission on a in the expanded ac-tion assignment AAAtomic to which r is assigned in the expanded permissionassignment PAExpanded .

For each role in AR(a), a corresponding .NET attribute of type Security-

Role is generated by the rule application

[[∀r ∈ AR(a) apply 7→dotnetSecurityRole(r)]] ,

104

which is added to each rule that generates a method stub from a method,attribute or association end. This is shown by the following on the exampleof the generation rule for method stubs

Method(m) 7→dotnetMethodStub

[[∀r ∈ AR(methodAction(m)) apply 7→dotnetSecurityRole(r)]]public [[returnType(m)]] [[name(m)]]([[parameters(m)]]){} .

(6.69)

Note that there is no transformation rule for SecureUML roles because.NET does not require global role definitions. Instead, the .NET environ-ment determines this information by analyzing the declared role checks of allcomponents of a particular application.

The transformation of authorization constraints is analogous to the EJBtransformation. There are only syntactical differences in the mapping rulesbetween OCL and the C# programming language and the programmaticaccess control functions of .NET. The following shows the counterpart of theexample given in Section 6.2.2.

public void cancel(){Boolean accessAllowed = false;accessAllowed = accessAllowed || ctx.IsCallerInRole("Supervisor");if (!accessAllowed && (ctx.IsCallerInRole("User") ||

ctx.IsCallerInRole("Supervisor"))){try{accessAllowed = (ctx.OriginalCaller.AccountName == owner);}catch(Exception ex){. . .}}if (!accessAllowed) throw new UnauthorizedAccessException("Access denied");_cancel();}

105

106

Chapter 7

ControllerUML

To demonstrate the general applicability of our approach, we now present asecond design modeling language and its transformation to a security designlanguage. This language, which we call ControllerUML, is based on state ma-chines [30]. To keep the account self-contained, we simplify state machinesby omitting parallelism, actions on state entry and exit, and details on visu-alization elements. We will show how ControllerUML can be integrated withSecureUML and used to model secure controllers for multi-tier applicationsand how access control infrastructures can be generated from such controllermodels.

7.1 Language Definition

A well-established pattern for developing multi-tier applications is the Model-View-Controller pattern [18]. In this pattern, a controller is responsible formanaging the control flow of the application and the data flow between thepersistence tier (model) and the visualization tier (view). The behavior ofthe controller can be formalized by using event-driven state machines andthe modeling language ControllerUML utilizes UML state machines for thatpurpose.

The abstract syntax of ControllerUML is defined by the metamodel shownin Figure 7.1. Each Controller possesses a Statemachine that describes its be-havior in terms of States, StateTransitions, Events, and StatemachineActions. AState may contain other states, formalized by the association StateHierarchy,and a transition between two states is defined by a StateTransition, which istriggered by the event referenced by the association end trigger. A state ma-chine action is a specification of an executable statement that is performedon entities of the application model. ViewState and SubControllerState are sub-

107

ViewState SubControllerState StatemachineAction

Event Controller

1 +controller 1

StateTransition

0..1 effect 0..1

1

trigger

1

Statemachine 1

behavior

1 State 0..n 1

incoming

0..n target 1

0..n 1

outgoing

0..n source 1 n

states

n

0..* 0..1 +substates 0..*

StateHierarchy

container 0..1

Figure 7.1: Metamodel of ControllerUML

MainController <<Controller>>

CreationController <<Controller>>

Start

End

CreateMeeting <<SubControllerState>>

EditMeeting <<ViewState>>

ListMeetings <<ViewState>> back

select

exit

create

edit

cancel / cancelMeeting

delete / deleteMeeting

apply / update

MainController's Statechart

Figure 7.2: Controllers for Scheduling Application

classes of State. A ViewState represents a state where the application interactswith a human by way of view elements like dialogs or forms. The view el-ements generate events in response to user actions, e.g. clicking a mousebutton, that are processed by the controller’s state machine. A SubController-

State references another controller using the association end controller. Thereferenced controller takes over the control flow of the application when thereferencing SubControllerState is activated. This supports the modular speci-fication of controllers.

The notation of ControllerUML uses primitives from UML class diagramsand statecharts. An example model is shown in Figure 7.2. A Controller is rep-resented by a UML class with the stereotype «Controller». The state machineof the controller is defined by a UML state machine that is attached to thisUML class. States, transitions, events, and actions are represented by their

108

natural counterparts in the UML metamodel. Transitions are labeled witha string, containing a triggering event and an action to be executed duringstate transition, separated by a slash. We use event names to identify tran-sitions in our explanations. View states and subcontroller states are labeledwith the respective stereotypes «ViewState» and «SubControllerState».

Figure 7.2 shows a (partial) design model for an interactive applicationthat formalizes the scheduler workflow presented in Section 2.2.1. The con-troller class MainController is the top-level controller of the application andCreationController controls the creation of new meetings. In the follow-ing, we explain those parts of the application model that we need in orderto formalize an access control policy in the next section. We focus on thedesign of the MainController and omit details of the controller class Cre-

ationController.

The state machine of MainController is similar to that of Figure 2.3. Inthe state ListMeetings, a form is displayed that shows all meeting entries inthe database, independent of their owner. A user can trigger different actionsfrom this form. It is possible to select a meeting and to execute an actionon it. The selected meeting is stored in the attribute selectedMeeting ofthe controller object. An event of type delete triggers the execution of theaction deleteMeeting, whereas cancel causes the execution of the actioncancelMeeting. The transition edit causes a state transition to EditMeet-

ing, where the user can change the meeting information. The action update

on the outgoing transition apply of this state propagates the changes to thedatabase. The creation of a new meeting is triggered by an event of type cre-ate. In this case, the subcontroller state CreateMeeting is activated, whichin turn activates a controller of type CreationController. The referencefrom the subcontroller state CreateMeeting to the controller CreationCon-troller is not visible in the diagram. Instead, this information is stored ina tagged value of the subcontroller state.

7.2 SecureUML Dialect for ControllerUML

We now show how we extend ControllerUML to a security design languagethat supports the specification of access control policies. We start by defin-ing the SecureUML dialect at the level of abstract syntax. Afterwards,we describe how we combine the concrete syntax of SecureUML and Con-trollerUML.

109

ControllerActivateRecursive

CompositeAction (from SecureUML)

AtomicAction (from SecureUML)

StateActivateRecursive

Controller State

Resource (from SecureUML)

StatemachineAction

execute activateRecursive activate activateRecursive activate

Figure 7.3: Dialect Metamodel of ControllerUML

7.2.1 Extending the Abstract Syntax

To begin with, we import the SecureUML metamodel into the ControllerUMLmetamodel and set the default behavior of the new security design languageto “access allowed”, i.e. we set the tagged value DefaultBehavior on the Con-trollerUML package to “true”.

In the next step, we define the protected resources of ControllerUML.There are various ways to introduce access control into a process-orientedmodeling language like ControllerUML. Each way results in the definition ofa different SecureUML dialect for ControllerUML. Here we shall proceed byfocusing on the structural aspects of statecharts, which are described by theclasses of the metamodel (Figure 7.1) and the relations between them.

We identify the types Controller, State, and StatemachineAction as the re-source types in our language since their execution or activation can be sen-sibly protected by checkpoints in the generated code. Figure 7.3 shows thisidentification and also defines the composite actions for the dialect and theassignment of actions to resource types.

The resource type StatemachineAction offers the atomic action execute anda state has the actions activate and activateRecursive. The action activateRe-cursive on a state is composed of the actions activate on the state, executeon all state machine actions of the outgoing transitions of the state, and theactions activateRecursive on all sub states of the state. The respective OCLdefinition is as follows.

context StateActivateRecursive inv:self .subs = self .resource. actions−>select(name=”activate”)−>union(self .resource.substates . actions−>select(name=”activateRecursive”)−>union(self .resource.outgoing−>select(effect<>None).effect.actions−>select(name=”execute”)))

110

stereotype resource type naming convention

«ControllerAction» Controller empty string«StateAction» State state name«ActionAction» StatemachineAction state name + “.” + event name

Table 7.1: Action Reference Types for ControllerUML

This expression is built using the combined metamodel of ControllerUMLand SecureUML (cf. Figures 4.1, 7.1, and 7.3). First, the expression accessesthe resource the action belongs to (always a state) and selects the action withthe name “activate”. The next line selects all actions with name “activateRe-cursive” on all sub states of the state the action of type StateActivateRecursive

belongs to. The last line first queries all outgoing transitions on the stateand selects those transitions with an assigned state machine action (associa-tion end effect). Afterwards, for each state machine action, its (SecureUML)actions with the name “execute” is selected.

A controller possesses the actions activate and activateRecursive. Thelatter is a composite action that includes the action activate on the controllerand the action activateRecursive for all of its states. This is formalized bythe following OCL invariant.

context ControllerActivateRecursive inv:self .subs = self .resource. actions−>select(name=”activate”)−>union(

self .resource.behavior.states . actions−>select(name=”activateRecursive”))

Note that due to the definition of activateRecursive on states, the actionactivateRecursive of a controller (transitively) includes all sub states and allactions of the state machine.

7.2.2 Extending the Concrete Syntax

First, we combine the notation of both languages by combining the Se-cureUML notation with that of ControllerUML. Afterward, we define theaction reference types for controllers, states, and state machine actions, asshown in Table 7.1. Finally, well-formedness rules are defined on SecureUMLpermissions (1) that restrict the scope of permissions to UML classes with thestereotype «Controller» and (2) fix the set of valid types for action referencesto the types shown in Table 7.1.

111

UserCreation

<<ControllerAction>> CreationController : activate_recursive

UserMain

<<ControllerAction>> MainController : activate <<StateAction>> ListMeetings : activate <<StateAction>> CreateMeeting : activate

OwnerMeeting

<<ActionAction>> ListMeetings.delete : execute <<ActionAction>> ListMeetings.cancel : execute <<StateAction>> EditMeeting : activate_recursive

caller = self.selectedMeeting.owner.name

CreationController <<Controller>>

User <<Role>>

<<Permission>>

MainController

selectedMeeting : Meeting

<<Controller>> <<Permission>>

<<Permission>>

Supervisor <<Role>> <<Permission>>

SupervisorCancel

<<ActionAction>> ListMeetings.cancel : execute

Figure 7.4: Policy for Scheduling Application

7.3 Example Authorization Policy

We now return to our scheduling application model and extend it with aformalization of the security policy given in Section 2.1. In doing so, we usethe role model introduced in Section 4.2.

As Figure 7.4 shows, we use two permissions to formalize the first require-ment that all users should be allowed to create and to read all meetings. Thepermission UserMain grants the role User the right to activate the controllerMainController and the states ListMeetings and CreateMeeting. Thepermission UserCreation grants the role User the privilege to activate theCreationController including the right to activate all of its states and toexecute all of its actions.

The second requirement states that only the owner of a meeting entry isallowed to change or delete it. We formalize this by the permission Owner-

Meeting, which grants the role User the right to execute the actions on theoutgoing transitions delete and cancel of the state ListMeetings and theright to activate the state EditMeeting. This permission is restricted by theconstraint “self.selectedMeeting.owner.name = caller”.

In the example policy, only supervisors are allowed to cancel any meet-ing. Therefore, the permission SupervisorCancel grants this role the unre-stricted right to execute the action cancelMeeting on the transition cancel.

112

7.4 Transformation to Web Applications

In this section, we describe a transformation function that constructs secureweb applications from ControllerUML models. We first introduce a basictransformation function that converts UML classes and state machines intocontroller classes for web applications, executed in a Java Servlet environ-ment (cf. Section 2.4.3). Afterwards, we explain how we extend this functionwith generation rules that translate an access control policy specified in aControllerUML model into an access control infrastructure.

We specify transformation rules in the notation introduced in Section 6,where each rule operates on the relational representation of a ControllerUMLmodel in abstract syntax. As demonstrated in subsection 5.2.2 on the exam-ple of ComponentUML, this representation can be derived from the meta-models of ControllerUML (cf. Figures 7.1 and 7.3) and SecureUML (cf. Fig-ure 4.1) by applying the MOF-Mapping rules introduced in subsection 3.1.1.

7.4.1 Basic Transformation Function

The basic transformation creates web applications with the following archi-tecture. Each controller class in the model is transformed to a servlet com-ponent, designated as controller servlet. This servlet implements the controllogic formalized by the statemachine of its corresponding controller class.

In general, web clients communicate with web applications using HTTPrequests. In the web applications generated by this transformation function,HTTP requests correspond to the events in a ControllerUML model. A con-troller servlet receives HTTP requests and decides in dependence of its stateand the type of event what activities must be performed. Possible activitiesare the activation or deactivation of the controller itself, state transitions, theexecution of statemachine actions, the activation or deactivation of states,and the invocation of sub-controller. Each of these activities is performedin a dedicated method in the controller’s servlet class. As response to eachrequest, an HTML page is sent to the client.

A typical ControllerUML application model consists of several controllerswith one of them acting as the application’s top-level controller. The re-maining controllers are integrated into the control flow of the applicationusing sub-controller states. Such an application model is transformed intoa web application composed of several cooperating controller servlets. Theservlet created from the top-level controller acts as the entry point of theapplication. It receives all requests and forwards them (depending on theapplication state) to the other controller servlets.1

1Note that we give a simplified version of the transformation function for web applica-

113

The transformation function generates two types of artifacts: a deploy-ment descriptor for the web application and a java class for each controllerservlet. Each of these artifacts is created by a top-level transformation rule,which delegates the further processing to other accompanying transformationrules.

Deployment Descriptor The deployment descriptor of the web applica-tion is created by the following rule.

ModelControllerUML(m) 7→webDesc

<web-app>[[∀c ∈ Controller apply 7→servletDef (c)]][[∀c ∈ Controller apply 7→servletUrl (c)]]. . .

</web-app>

(7.1)

The rule generates the framework of the descriptor and delegates the defini-tion of servlet components and URL mappings to the transformation rules7→servletDef and 7→servletUrl . The rule

Controller(c) 7→servletDef

<servlet><servlet-name>[[name(c)]]</servlet-name><servlet-class>[[name(c)]]</servlet-class>

</servlet>

(7.2)

transforms a controller class to a servlet definition, which consists of thename of the servlet component and the name of the implementation class ofthe servlet. Additionally, the transformation rule

Controller(c) 7→servletUrl

<servlet-mapping><servlet-name>[[name(c)]]</servlet-name><url-pattern>/[[name(c)]]/*</url-pattern>

</servlet-mapping>

(7.3)

defines a URL used to address a servlet.

Controller Servlet Class For each controller class in the ControllerUMLmodel, a servlet class is generated by the following rule.

Controller(c) 7→controllerClass

public class [[name(c)]] extends HttpServlet {public void doPost(. . .) throws ServletException {. . .}protected void activate(. . .) throws ServletException {. . .}protected void deactivate(. . .) throws ServletException {. . .}[[∀s ∈ statemachineStates(controllerBehavior(c)) apply 7→state (s)]]}

(7.4)

tions. This is to keep the focus on the conceptual aspects of the transformation functionfor access control. For example, we omit details concerning the web application’s sessionmanagement, the rendering of HTML pages, and the handling of sub-controller states.

114

The name of controller is used as the name of the servlet class and the classis derived from the Java Servlet base class HttpServlet.

The template generates three methods into the servlet class. doPost isthe callback that is used by the servlet container to deliver HTTP requests.This method implements the event handling and the control logic of thecontroller. The methods activate and deactivate are used by doPost to activateand deactivate the controller servlet, respectively.

The embedded instruction applies the rule 7→state to each state of thestatemachine of the controller. This transformation rule is defined as follows.

State(s) 7→state

protected void activate[[name(s)]](. . .) throws ServletException {. . .}protected void deactivate[[name(s)]](. . .) throws ServletException {. . .}[[∀a ∈ stateActions(s) : apply 7→action (a)]]}

(7.5)

The rule creates two methods for activating and deactivating the correspond-ing state. Additionally, the embedded instruction applies the rule 7→action oneach statemachine action on the outgoing transitions of the state. This setof statemachine actions is determined by the function

stateActions : State → 2StatemachineAction ,

which is given as

stateActions(s) := {a ∈ StatemachineAction|∃t ∈ stateOutgoing(s)∧a ∈ stateTransitionEffect(t)} .

(7.6)

For each statemachine action, a corresponding method is generated in theservlet class by the rule

StatemachineAction(a) 7→action

public void performAction[[firstUp(name(a))]](. . .) {. . .} .(7.7)

7.4.2 Generating Access Control Infrastructures

Now we explain how we extend the basic transformation function with genera-tion rules that translate an access control policy specified in a ControllerUMLmodel into an access control infrastructure. We have already discussed therequirements for defining such a transformation function in Section 6.2.2. Re-call, that we must find a way to generate access control architectures whose

115

behavior is equivalent to the semantics of access control of the correspondingControllerUML model.

To begin with, we map the atomic actions of ControllerUML to the pro-tectable elements of the generated target system. This is quite simple in thecase of ControllerUML since there is a direct correspondence between theatomic actions on controllers (activate), states (activate) and statemachineactions (execute) and the methods generated in the controller servlet’s class.

In the next step, we select an appropriate mechanism of the target plat-form to enforce the access control policy. As explained in subsection 2.4.3,Java Servlet offers declarative and programmatic access control. Unfortu-nately, we cannot use the declarative mechanism (security-constraint elements)to protect the controller servlets for the following reason. The servlet con-tainer only enforces access control when a request arrives from outside theweb server. So access control is not enforced if subsequently requests areforwarded to other servlets in the same web server. This is ill-suited for thekind of web application we generate. There, the top-level controller of anapplication always receives the request and forwards them (depending on theapplication state) to the other servlets. Thus the declarative mechanism onlyprovides protection for the top-level controller. To overcome this weakness,we generate access control infrastructures that exploit the programmatic ac-cess control mechanism, only.

In detail, the transformation function works as follows. Security rolesare defined in the deployment descriptor of the web application. The basicidea for implementing access control is similar to the approach described inSection 6.2.2. We augment the existing transformation function for Con-trollerUML by generation rules, which generate proxy methods with asser-tions that replace the original methods for controller activation, state acti-vation, and action execution of a controller class. Each authorized call ispassed through to the original methods after access control.

In contrast to the approach described in Section 6.2.2, the static as wellas the dynamic part of an access control policy must be enforced by thegenerated assertions. Therefore proxy methods are generated if there is atleast one permission assigned to the corresponding action. Note that thisrule also results in an access control default behavior of “access allowed” ofthe generated systems.

Roles Each role in the model is transformed to a security-role element in thedeployment descriptor of the web application. We therefore extend the basicrule 7→webDesc (cf. Rule 7.1) as follows.

116

ModelControllerUML(m) 7→webDesc

<web-app>[[∀c ∈ Controller apply 7→servletDef (c)]][[∀c ∈ Controller apply 7→servletUrl (c)]]. . .[[∀r ∈ Role apply 7→webRoleDef (r)]]

</web-app>

(7.8)

The new instruction causes the application of the generation rule 7→webRoleDef

to every role in the model. This rule is specified as

Role(r) 7→webRoleDef

<security-role><role-name>[[name(r)]]</role-name>

</security-role> .(7.9)

Assertions The approach for generating proxy methods and assertions issimilar to subsection 6.2.2. Thus we only give an example that illustrates thenature of the proxy methods and assertions generated for web applications.

The following rule generates a proxy method that replaces the originalmethod for executing an action on a transition.

StatemachineAction(a) 7→actionProxy

public void performAction[[firstUp(name(a))]](. . .) {[[apply 7→webAssertion (actionForActionExecute(a))]]_performAction[[firstUp(name(a))]](. . .);}

(7.10)

The assertion in the proxy method is created by the rule

AtomicAction(a) 7→webAssertion

boolean accessAllowed = false;[[∀p ∈ AP(a) apply 7→webUnconstrPerm (p), 7→webConstrPerm (p)]]if (!accessAllowed) accessDenied.forward(request,response); .

(7.11)

The structure of the generated assertion is similar to the EJB assertion asexplained in Section 6.2.2. The set of permissions AP(a) that affect the exe-cution of an action is determined according to the Formula 6.23 on page 87.

For each permission in AP(a), either 7→webUnconstrPerm or 7→webConstrPerm

is applied to construct a Java expression that may set the value of accessAl-

lowed to true, i.e. grant access to the caller. However, instead of throwing anexception when access is denied, a request to a controller is forwarded to anerror page by the term in the last line.

A Java expression created by the rule

UnconstrainedPermission(p) 7→webUnconstrPerm

accessAllowed = accessAllowed || [[roleCheck(p)]];(7.12)

117

grants access if the caller is assigned to one of the roles assigned to thepermission p in PAExpanded . The only difference to 7→unconstrPerm given in Sec-tion 6.2.2 is the usage of the Servlet API for programmatic access control fordetermining the role assignment. The following shows an example expression.

accessAllowed = accessAllowed || request.isUserInRole(”Supervisor”);

Constrained expressions are translated to Java code with the followingstructure

ConstrainedPermission(p) 7→webConstrPerm

if (!accessAllowed && ([[roleCheck(p)]])){try{accessAllowed = [[webConstraintExpression(p)]];

}catch(Throwable ex){. . .}

}

(7.13)

This structure is equivalent to the structure generated by the rule 7→constrPerm

in Section 6.2.2. First, there is a check whether the caller is in one of theroles to which the permission can be applied. As in the previous example,the role check only differs from the EJB assertion in that it uses another APIcall to determine the role assignment.

The function webConstraintExpression produces a Java expression fromthe authorization constraint assigned to the permission p. The only differenceto the function LOCL → LJava that is used to produce Java expressions inEJB assertions is that the symbol caller is mapped to request.getRemoteUser().

Applying the generation procedure described above to the action cancel

on state ListMeetings results in the following proxy method.

public void performActionCancel(Event e){boolean accessAllowed=false;accessAllowed = accessAllowed || request.isUserInRole("Supervisor");if (!accessAllowed && (request.isUserInRole("User") ||

request.isUserInRole("Supervisor"))) {try {accessAllowed =

getSelectedMeeting().getOwner().getName().equals(request.getRemoteUser());}catch(Throwable ex){. . .}}if (!accessAllowed) accessDenied.forward(request,response);_performActionCancel(e);}

118

Chapter 8

Tool Support and DevelopmentProcess

We have implemented our approach in a prototype tool. It supports thedevelopment of security design models and the generation of systems withaccess control infrastructures. Moreover, we complement the tool by a de-velopment process, which guides developers during the analysis, design, andimplementation of such systems. This process is defined in terms of devel-opment guidelines that can be integrated in standard software developmentprocesses like the Rational Unified Process [26].

We first describe the prototype tool and introduce our development guide-lines afterwards.

8.1 Tool Support

We first explain the tools we have based our prototype upon. Then we give anoverview of the prototype architecture, describe how we process OCL-basedauthorization constraints, and explain the security design tool.

8.1.1 Tool Foundation

ArcStyler We based our prototype on the MDA-tool ArcStyler [21]. Arc-Styler offers UML-modeling support, is extensible by custom modeling tools,and has an extensible and customizable generator engine.

Different kinds of modeling tools, e.g. custom user interfaces for platformspecific model properties, can be embedded within the ArcStyler environ-ment. ArcStyler offers a Java-based tool integration interface that is usedto initialize and deactivate tools, and to propagate user interface events, e.g.

119

the selection of a menu option, to the tool. An embedded modeling tool canaccess the UML-model through a JMI-compliant repository interface.

The ArcStyler generator engine executes transformation functions thatare packaged in so called cartridges. Each cartridge implements a transfor-mation function from models given in a particular, typically UML-based,modeling language to a particular target platform. By configuring the gener-ator engine with different cartridges, software systems for different platformscan be generated from the same model.

The generator engine and the complementing object-oriented cartridgeframework allow one the creation of new cartridges as well as the extensionand customization of existing ArcStyler cartridges. For example, it is possibleto derive a custom cartridge from an existing ArcStyler cartridge and to addsub-functions for generating new source code artifacts, to adapt the rulesfor generating a particular artifact, or to globally change the algorithm forcomputing method names in the base cartridge.

A cartridge is implemented in a template language based on the Jython [36]scripting language. Basically, ArcStyler templates can use any model infor-mation accessible via a Java or Jython interface. Usually, the JMI-compliantinterface to the ArcStyler UML-repository is used but other repositories canbe accessed as well.

OCL Compiler In our prototype tool, we use the Dresden OCL Toolkit [44]as an OCL compiler. The toolkit is implemented in Java and provides mod-ules that parse, type check, and normalize OCL constraints. The type checkerof the toolkit can be integrated with custom metamodels through a modelfacade interface [17].

8.1.2 Prototype Architecture

Figure 8.1 shows a schematic representation of the prototype architecture.Each of the boxes represents a module of the prototype and the arrows be-tween the modules depict the flow of information.

Security design models are stored in the UML repository provided bythe ArcStyler tool. The concrete syntax of SecureUML and our securitydesign languages ComponentUML and ControllerUML is made available inthis environment by installing the corresponding UML-profiles (cf. Sections4.2, 5 and 7).

On top of the UML-repository operates the SecureUML repository. Thisrepository transforms the UML-encoded model information into a transientmodel in the abstract syntax of a security design language. The JMI-compliant

120

UML Repository UML profiles of SecureUML ,

ComponentUML and ControllerUML

SecureUML Repository combined metamodel of SecureUML , ComponentUML and ControllerUML

Security Designer

Generator Cartridges

Figure 8.1: Prototype Architecture

interface and parts of the implementation of the repository have been auto-matically generated from the combined metamodel of SecureUML and oursecurity design language using an existing ArcStyler cartridge. The modelinformation provided by the SecureUML repository are used by our generatorcartridges and the Security Designer.

The generator cartridges of the prototype extend existing ArcStyler car-tridges and transform models in the abstract syntax of a particular securitydesign language to system implementations with access control infrastruc-tures (cf. Sections 6 and 7.4).

The Security Designer is a custom modeling tool for defining and analyz-ing permissions. We have implemented this tools for the following reason:Basically, the UML-based concrete syntax of SecureUML has shown to besuitable and convenient for defining comprehensive access control policies,especially roles and authorization constraints. Additionally, models givenin UML are interchangeable among UML-tools. However, experiences gath-ered during our case study as well as feedback from other researchers andindustrial partners suggest a matrix-based notation as optimal notation formanaging permissions. The security designer offers such a notation.

8.1.3 OCL Support

The SecureUML repository provides support to process OCL-based autho-rization constraints, e.g. it is possible to syntax check a constraint or tocompile it into an abstract syntax tree. As explained in Section 4.2, au-thorization constraints are specified on permissions without giving an OCLcontext. This is because the effective context of an authorization constraint

121

Figure 8.2: Security Designer

is an action and the context can be computed from the structural modelinformation.

Since the context of an authorization constraint is always a SecureUMLaction, the constraint needs to be compiled in the context of each actionassigned to the permission. For each such an action, a legal OCL methodprecondition is created from the original constraint expression. This OCLprecondition is then compiled using the Dresden OCL Toolkit.

The question might arise, why we generally use method preconditions.The answer is obvious for actions whose resource corresponds to a method inthe model, e.g. execute on an entity method. But a constraint on the actionread of an entity attribute could also be mapped to an invariant of the entity.The reason is that we need to make the SecureUML symbol caller availableto the OCL expression. We achieve this goal by passing this symbol as anadditional parameter to the constraint. Thus we generally use preconditionswhen mapping authorization constraints to OCL constraint expressions. Incases, where the resource of an action does not correspond to a method inthe model, we use a “dummy” method instead.

8.1.4 Security Designer

The security designer is a tool for defining permissions and visualizing thesemantics of access control policies. As depicted by Figure 8.2, the tool usesa matrix-based notation. The vertical axis shows protected resources (nodes)

122

and their actions (leaves) in a tree structured way and the horizontal axiscontains roles. Each cell in the matrix corresponds to a tuple of a role andan action.

The work with the security designer is centered around these cells. Eachof them offers user interface elements that allow a developer to create orremove a permission between the action and the role of the cell and to assignauthorization constraints to this permission. Moreover, each cell shows theaccess control decision for the given pair of action a and role r, i.e. whetheraccess is granted for the role r on the action a.

A permission is created (removed) for a role on a particular action byenabling (disabling) the checkbox in the cell. If the checkbox is enabled,then the tool allows one to activate an authorization constraint editor bytriggering the radio button beside the checkbox. This editor is used to specifyand syntax check constraints.

For each cell of the matrix, there is an icon showing whether access isgranted (check mark) or denied (cross mark). All model information, includ-ing the side effects caused by the SecureUML hierarchies ≥Role and ≥Action aswell as the security design language’s default behavior, are considered in thisprocess. For example, the policy shown in Figure 8.2 assigns the role User apermission to create meetings. This is also confirmed by the correspondingcheck mark. Due to role inheritance this also entitles the role Supervi-

sor to access this action, which is symbolized by another check mark in thecorresponding matrix cell.

Permissions with an authorization constraint assigned impose the follow-ing problem. Although we are able to determine the conditions that musthold in order to grant access to the cell’s role on the cell’s action, we cannotdecide whether access is really granted. This decision depends on the systemstate (MOF level 0), which is not available during the design stage (MOFlevel 1). We nevertheless want to give users as much information as possible.Therefore, if access would be granted by the static part of the SecureUMLsemantics but there is an additional constraint, than the security designershows a check mark with an additional question mark nearby (conditionalaccess). This is shown in the example for the action update and the roleUser.

Composite actions to which no explicit permission is assigned are handleddifferently. Their access control decision is determined by recursively accu-mulating the decisions of all sub-actions. If the semantics of all sub-actionsis identical either access denied, access granted, or conditional access, thenthe marks as explained above are shown. Otherwise, an icon with both across and a check mark is displayed. We implemented this functionalitybecause only atomic actions are mapped to protected actions in the target

123

platform, whereas composite actions only function as grouping mechanism.This behavior of the security designer allows one to grasp the meaning of apolicy quickly without expanding all levels in the resource and action tree.For example, the computed access control decision for the action fullAccesson the entity Meeting and the role Guest is “access denied”. This meansthat although there is no explicit permission for any other role on fullAccess,access is effectively denied to any of the actions of Meeting because of theaccumulated permissions for other roles.

These features make the security designer a powerful tool for designingand understanding permissions. Note that the model information is still keptin the UML repository. All changes performed in the security designer aredirectly propagated to the UML model by the SecureUML repository.

8.2 Development Guidelines

One focus of our work is to propose how roles and permissions are designedand, in the later stages of the process, what the protocol is between softwaredevelopment and administration. A further issue is how users and groupsare managed and by whom. We therefore developed guidelines regarding thedevelopment process of an access control policy, which we present in thissection.

Today, a typical problem in the development of distributed applicationsis as follows. Software developers create an application with several hundredor even thousands of methods, e.g. provided as web services. Afterwards, itis the responsibility of an administrator to place this application into opera-tion. This typically includes the integration of the application into the localsecurity policy domain, i.e. to give users and groups the permissions theyneed to carry out their job. The problem is that the distributed applicationis a “black box” for the administrator. He does not know the semantics of theapplication’s different services. So how should he define a sensible embeddinginto the local policy domain?

There is a need for a protocol between software development and admin-istration that is used to propagate such information between the stages of thesoftware life cycle. We see roles as a promising concept to solve this problem.

The usage of roles as a protocol between application development andadministration is inline with the way modern technologies for distributedsystems, like EJB or .NET, use roles. There, every role represents a viewpointof the application, e.g. the view of a customer or an employee. We thereforecall this kind of roles application roles.

The idea is that application roles are the primary interface between soft-

124

ware development and operation. They formalize logical permissions or per-mission bundles according to certain views to the application. The applica-tion developer knows the internals of the system and can define such rolesand their required permissions, whereas the security administrator knows theusers and groups of the installation domain and assigns the right users to theright roles. In this way, the administrator does not have to care about thesemantics of all the methods (entry points) offered by the components of thesystem. What is missing in this picture is a systematic way for identifyingroles and assigning them the right permissions, also designated as role engi-neering [39]. We propose a use case centric approach that can be embeddedin every model-based development process.

The basic idea is as follows: Use cases specify the system functionality andpartitioning in terms of use cases and participating actors. Actors representviewpoints of the system and can be mapped to roles, whereas use casesidentify and describe activities these actors participate in. To carry out hisjob, an actor needs the necessary permissions on the underlying entities ofthe activity. Therefore, we propose to extract these permissions from theuse case description and all suitable design information, which describe thestructure and the behavior of a system. In that way, our approach supportsthe development of access control policies according to the “least privileges”principle [28], i.e., a user may only have those access rights that are necessaryto perform a job.

We want to seamlessly integrate role engineering into the software devel-opment process. The necessary information is gathered and defined in severalactivities, which are sub-activities of more general activities of the softwaredevelopment. These new activities are authorization requirements definition,authorization requirements analysis, access control policy definition, accesscontrol policy implementation, and access control policy customization.

The proposed development activities rely on the existence of informationproduced by other (more general) activities. e.g. use case models from theanalysis. We will explain the access control specific development activitiesand their dependencies on general model information in the context of ageneric development workflow, with analysis, design, implementation, anddeployment activities.

8.2.1 Analysis

In the analysis, we expect that functional requirements of an application areformalized with use cases. For example, a use case diagram for the schedulingapplication has been given in Section 2.2.1, Figure 2.1. The activity autho-rization requirements definition extends the requirements definition. The

125

Create Meeting Read Meeting Edit Meeting Delete Meeting

User

Cancel Meeting

Supervisor

Figure 8.3: Extended Use Case Diagram

goal of this activity is to gather and to document dedicated authorizationrequirements. In the scheduling application, we have stated that users areallowed to create and read meetings, and to edit, delete, and cancel theirown meetings. Additionally, supervisors are entitled to cancel any meeting.We represent this requirements in the use case model as follows: First, weintroduce a second actor Supervisor, representing a subset of users withspecial privileges, and derive Supervisor from User. Figure 8.3 shows therefined use case diagram. Second, we add authorization specific informationto the descriptions of the affected use cases. The following shows this for theuse case Cancel Meeting.

Authorization:- Only the owner of a meeting may cancel the meeting.- However, a supervisor can cancel any meeting.

8.2.2 Design

Generally, the structural design of a system is defined using classes and classdiagrams. The behavior of objects and interactions among objects can e.g.be formalized with dynamic diagrams, like state charts or sequence diagrams.It is especially useful to refine use case definitions with sequence diagrams,which demonstrate the realization of the use cases in the system design.This not only helps to verify the compliance of specified requirements andthe design. We also can utilize such information in the definition of accesscontrol policies.

The activities authorization requirements analysis and access control pol-icy definition are sub-activities of the design stage. In the authorizationrequirements analysis, an informal access control policy is deduced from all

126

available analysis and design information and specified as part of the usecase model. This information is used in the access control policy design toformalize the policy as part of the security design model.

Authorization requirements analysis First, we determine the permis-sions required to execute a single use case and specify them as additionalannotation of the use case. All available model information can be usedfor this purpose. Our experience shows that it is possible to deduce theused entities and their actions from the use case description and the struc-tural model in most cases. Additionally, OCL navigation expressions like“self.participants” can be used identify resources. For example, from thedescription of the use case Create Meeting

A form is displayed where the user can specify the participants, location,time and date of the meeting. The meeting is created on submission of theform. The new meeting is shown afterwards.

and the class diagram in Figure 5.2 we can derive the following requiredaccess rights.

Meeting.create, Meeting.read, Person.read, Room.read

A resource action is denoted by the entity type and the action name,separated by a dot and we list the required entities and actions in a commaseparated list. If a use case requires the same action on different resources,we sometimes use a shortcut and write “Meeting/Person/Room.read”, i.e.the resource names are separated by a slash and we append the action name.Note that we refer to the vocabulary of the security design language becausewe know which of the participating system entities are protected resourcesand what their actions are.

Conditions for granting access are documented in brackets. This is shownby the following annotation of the use case Edit Meeting.

Meeting.update (only the own meeting)

For nontrivial use cases, we recommend to analyze sequence diagrams thatrefine the use case. For example from the sequence diagram in Figure 2.4,we can determine the following required access rights for the use case CancelMeeting.

Meeting::cancel.execute,Meeting::notify.execute,Meeting::delete.execute

In the second step of the authorization requirements analysis, we collectand consolidate the required access rights for each actor from all of its usecases. Consolidation can also mean to simplify the policy, where this is ac-ceptable. We encourage and support the concept of “least privileges”, but we

127

also want to keep the access control policy manageable. To give an example:Our experiences have shown that it is recommendable to define one actor(and role) in the system as owner, i.e. being primary responsible for man-aging, a particular type of entities. For example, we could make the actorSupervisor the owner of all meeting, person and room data. This rule notonly simplifies the access control policy, it also avoids oversights in the policy.It is impossible that, unintentionally, a method is public accessible becauseno permission is specified for the method. The following shows the resultingaccess right for the actor Supervisor.

Meeting.fullAccess, Person.fullAccess, Room.fullAccess

Access control policy design Based on the consolidated information fora single actor, we start designing the access control policy by formalizingroles, permissions and authorization constraints.

First, we create one role per actor and introduce an inheritance relationbetween roles if such a relation also exists between the original actors. Af-terwards, we define the permissions for every role. We give each role thetransitive closure of all permissions that the corresponding actor needs forall of its use cases. Permissions that are inherited from super-roles can beomitted.

Next, we introduce authorization constraints where necessary. Note thatthe usage of authorization constraints may require an extension of the systemdesign model. For example, the role User is granted update access to meetinginformation in our example only if the caller is the owner of the meeting ob-ject. As a prerequisite, we need to store the name of the owner and thereforeadd an attribute of type String to the component Meeting and specify theconstraint as “self.owner = caller”.

8.2.3 Implementation

Because the access control infrastructure is generated automatically, the im-plementation stage is quite simple from the access control standpoint. Thesub-activity access control policy implementation only advises developers toensure that information needed in authorization constraints are supplied. Forexample, the implementation of the entity Meeting must initialize the valueof the attribute owner with the user name of the owner of the particularobject.

128

8.2.4 Deployment

In the deployment activity, the application is installed in the applicationserver. We add the sub-activity access control policy customization to thisactivity. Here the security administrator assigns the application roles tousers and groups of the local security policy domain. This also means thatthe management of users and groups falls under the responsibility of theadministrator.

A question remains: Why does SecureUML formalize a vocabulary forusers, groups, and role assignments? This vocabulary can be used for analy-sis purposes. Suppose, an application has been developed with an extensiveaccess control policy and the developers want to examine this policy in thecontext of a particular security policy domain. They do not need to imple-ment, package, and install this application. Instead, they can import theuser and group information and use the tools for Model Driven Security tocarry out their analysis.

129

130

Chapter 9

Case Study

We have evaluated our concepts in an extensive case study based on a model-driven version of the J2EE “Pet Store” application, which is a standard ex-ample application designed to demonstrate the use of the J2EE platform.Pet Store is an e-commerce application with web front-ends for shopping,administration, and order processing.

We will show how we extended the “Pet store” application with an accesscontrol architecture using the prototype tool for Model Driven Security andthe development guideline given in the previous chapter. First, we will in-troduce the use case and the design model of the application. Afterwards,we will explain the access control policy that we derived from this informa-tion and will give some details of its formalization in an access control policymodel.

9.1 Use Case Model

The first use case diagram in Figure 9.1 shows the use cases and actors cen-tered around customers and shopping. We differentiate the two actors Visi-tor and Customer and define Customer as a sub-actor of Visitor. Visitorrepresents unregistered, and therefore anonymous, users of the web shop.Such users may browse the pet catalog, add/remove items to/from the shop-ping cart, register to the shop and login as a registered user. All other usecases are restricted to registered users, which are represented by the actorCustomer. A customer may checkout, view and change his account data,browse his own orders, and logout from the shop.

The diagram in Figures 9.2 describes the functionality for the internalmanagement (back office) of the shop. We have three functional areas, repre-sented by three the different actors Catalog Manager, Customer Relations

131

Add Item to Shopping Cart

Customer Registration Login existing customer

Remove Item from Shopping Cart

Update Cart

Browse Catalog

<<includes>>

Browse Shopping Cart

<<includes>>

<<includes>>

Login Customer to Shop

<<includes>> <<includes>>

Visitor Checkout

Change Account Data

Logout Customer

Browse Own Orders Customer

<<uses>>

Figure 9.1: Use Case Diagram for Shopping Functionality

Catalog Maintenance

populating the database via XML

Catalog Manager

Remove Customer

Maintain Customer Data

Direct Marketing

Customer RelationsManager

Remove Order

Change Order Data

Check Pending Order Order Processing Manager

Checkout Browse Catalog

Browse Customers

Browse Orders Employee

(from Employees)

<<uses>>

Figure 9.2: Use Case Diagram for Back office Functionality

132

Manager, and Order Processing Manager and a common base actor Em-

ployee.

The shop has a catalog of all pets it offers and it is the responsibility ofthe catalog manager to keep this catalog up-to-date. This includes catalogmanagement (Catalog Maintenance) as well as the initial population of thecatalog from a XML file (populating the database via XML).

The actor Customer Relations Manager participates in all use casesregarding the care of customer relations. He coordinates direct marketingactivities (Direct Marketing), and keeps the customer records up-to-dateMaintain Customer Data. If a customer has not bought any goods from theshop for a period of one year, then it is the responsibility of the customerrelations manager to remove the customer from the operational data base(Remove Customer).

The actor Order Processing Manager represents system users who areresponsible for processing purchase orders. This includes the approval of or-ders of they are more than 100d (Check Pending Orders), changes to orderdata if a customer calls in to change the contents of an already submittedorder (Change Order Data) or simply to remove orders (Remove Order).

The actor Employee formalizes the general role of a shop employee andparticipates in use cases for accessing information about customers, catalogdata and purchase orders. This actor has been introduced during authoriza-tion requirements definition for the purpose of giving all employees a commonbase set of privileges.

9.2 Design Model

The class diagram in Figure 9.3 gives an overview of the system design. At theleft-hand side, we see several entities (Customer, Account, Profile, Credit-Card, ContactInfo and Address) for managing customer related data. Atthe right-hand side there are the main entities of the shop’s catalog. Thecatalog is organized along categories (Category), products (Product) andcatalog items (CatalogItem). In the center of the diagram, there are theentities representing orders (PurchaseOrder) and order items (LineItem).The diagram only shows the main entities of the system; there are additionalhelper and process components. The complete application model consists of31 components and several front-end controllers.

Based on the static design, we have defined sequence diagrams showingthe interaction of the system entities in the fulfillment of several use cases. Forexample, Figure 9.4 shows the sequence diagram for the use case Checkout.

133

Cat

egor

y

id :

strin

g na

me

: str

ing

desc

riptio

n : s

trin

g

Pro

file

loca

le :

strin

g

Pro

duct

id :

strin

g na

me

: str

ing

desc

riptio

n : s

trin

g

0..1

0..*

cate

gory

0.

.1

prod

ucts

0.

.*

Cat

alog

Item

desc

riptio

n : s

trin

g im

ageL

ocat

ion

: str

ing

item

Id :

strin

g lis

tPric

e : d

oubl

e un

itCos

t : d

oubl

e

0..1

0..*

prod

uct

0..1

Item

s 0.

.*

Cre

ditC

ard

card

Num

mer

: st

ring

card

Typ

e : s

trin

g ex

piry

Dat

e : s

trin

g ex

piry

Mon

th :

strin

g ex

piry

Yea

r : s

trin

g

Cus

tom

er

1

1

cust

omer

1

prof

ile

1

Line

Item

quan

tity

: int

un

itPric

e : f

loat

1

cata

logI

tem

1

Acc

ount

stat

us :

strin

g

1 1

acco

unt

1

cred

itCar

d 1

1

1

cust

omer

1

acco

unt

1

Add

ress

city

: st

ring

coun

try

: str

ing

stat

e : s

trin

g st

reet

Nam

e1 :

strin

g st

reet

Nam

e2 :

strin

g zi

pCod

e : s

trin

g

Pur

chas

eOrd

er

orde

rDat

e : D

ate

orde

rId

: str

ing

stat

e : s

trin

g to

talP

rice

: dou

ble

0..*

lineI

tem

s

0..*

Con

tact

Info

emai

l : s

trin

g fa

mily

Nam

e : s

trin

g gi

venN

ame

: str

ing

phon

e : s

trin

g

1 1

acco

unt

1

cont

actIn

fo

1

1 1

cont

actIn

fo

1

addr

ess

1

1 bi

lling

Info

1

1 sh

ippi

ngIn

fo

1

Figure 9.3: Overview of the System Design

134

user Shop OrderCreator order:PurchaseOrder LineItem

checkOut() createOrder(ShoppingCart)

create(String,Customer,ContactInfo, ContactInfo)

create(CatalogItem, Integer, Double)

Figure 9.4: Sequence Diagram for Checkout Use Case

9.3 Use Case Model Annotations

In the Authorization Requirements Analysis, we extended the use case modelwith annotations regarding access control. In this section we illustrate thisby some examples of use case and actor annotations.

For example, the required permissions for the use case Browse own or-

ders are

CatalogItem.read, Product.readPurchaseOrder/LineItem.read (only the customer’s own orders)Customer/Account/CreditCard/ContactInfo.read (only the customer’s own data).

The required rights for the use case Checkout are deduced from the se-quence diagram in Figure 9.4 and are

PurchaseOrder.create, LineItem.create, CatalogItem.read, Product.readContactInfo.create, ContactInfo.read(own), ContactInfo.update(own).

Note that the need to read products and catalog items has been deter-mined from additional annotations (using OCL) in the use case like

The line items of the purchase order are determined by the catalogitems referenced by the shopping cart (path:cart.items.item).

The consolidated required rights for the actor Customer are as follows

Customer/CreditCard/Account/Address/ContactInfo/Profile.createCustomer/CreditCard/Account/Address/ContactInfo/Profile.read/update (own)PurchaseOrder/LineItem.createPurchaseOrder/LineItem/ContactInfo.read (own)CatalogItem/Product.Read.

135

Visitor <<Role>>

Customer <<Role>>

Employee <<Role>>

OrderProcessingManager <<Role>>

CatalogManager <<Role>>

CustomerRelationsManager <<Role>>

Figure 9.5: The Pet Store Role Model

9.4 Access Control Policy

Based on the information gathered during the Authorization RequirementsAnalysis, we formulate the following access control policy:

• The Visitor requires the right to read CatalogItem, Category, andProduct.

• Customers need to create and read all kinds of customer data, to updatetheir own customer data, to create purchase orders and line items andto read the own purchase orders.

• The Employee has need for reading all system data.

• Catalog Manager is the owner of catalog data and thus is given thefull access right to CatalogItem, Category and Product.

• Customer Relations Manager is the owner of all customer data andis therefore entitled for full access on Account, Address, ContactInfo,CreditCard, Customer, and Profile.

• The Order Processing Manager is the owner of PurchaseOrder andLineItem and is granted full access to this entities.

We now formalize the access control in a security design model. First,we need to define the roles. Figure 9.5 shows our roles, which are directlyderived from the actors of the use case model.

Afterwards, we formalize the policy given above by defining permissionsand authorization constraints. We use the security design tool introducedin Section 8.1.4 for this activity. Figure 9.6 shows the permissions on theentity PurchaseOrder in the Security Designer, whereas Figure 9.7 presentsthe underlying UML model.

136

Figure 9.6: Permissions on PurchaseOrder (Security Designer)

ReadOwnData

<<EntityAction>> PurchaseOrder : read

self.ownerId=caller

ReadCustomerData

<<EntityAction>> Customer : read

Owner

<<EntityAction>> Customer : fullAccess

CreateCustomerData

<<EntityAction>> PurchaseOrder : create

Employee <<Role>>

Customer <<Role>>

PurchaseOrder

orderDate : Date orderId : string ownerId : string state : string totalPrice : double

<<Permission>> <<Permission>>

<<Permission>>

OrderProcessingManager <<Role>>

<<Permission>>

Figure 9.7: Permissions on PurchaseOrder (UML)

137

The three roles Customer, Employee, and OrderProcessingMamnager areassigned permissions to actions of the entity. The OrderProcessingMam-

nager has full access to PurchaseOrder. The role Customer is granted theright to create order objects. Additionally, there is a constrained permis-sion for reading the order data. This constraint is formalized based on theattribute ownerId. The role Employee is entitled to read PurchaseOrder.

9.5 Evaluation

The modeled access control policy in our case study comprises six roles and 60permissions, 15 of which are restricted by authorization constraints. The cor-responding infrastructure is generated automatically and consists of roughly5,000 lines of XML (overall application: 13,000) and 2,000 lines of Java sourcecode (overall application: 20,000).

This large expansion is due to the high abstraction level provided by themodeling language. Recall for example, it allows one to grant “read” accessto a role, whereas EJB only supports permissions for whole components orsingle methods. Therefore, a modeled permission to read the state of a com-ponent may require the generation of many method permissions, e.g., forevery get-method of an attribute. Clearly, this amount of information can-not be managed at the source code level. The low abstraction level providedby the access control mechanisms of today’s middleware platforms thereforeforce developers to take shortcuts and make compromises in the use of accesscontrol mechanisms. For example, roles are assigned full access privilegeswhere they only require read access, or access control is enforced by provid-ing different applications for different viewpoints while the backend is onlyprotected against external attackers by using firewalls and virtual private net-works. However, this ignores the threats of internal attacks. Model DrivenSecurity can help to ease the transition from security requirements to secureapplications and to formalize and meet exact application requirements.

We were able to design and implement the complete access control ar-chitecture within two days. For the sake of comparison, the developmentof the whole application took about three weeks. This ratio suggests thatour approach only requires a small additional effort to add complete accesscontrol architectures to software systems.

The quality and reliability of the role description and permission assign-ment substantially depends on the quality of the design information, e.g.which component uses which services of other components to carry out aparticular task. All kinds of general design information should be used forpermission engineering, e.g. verbal descriptions, action semantics specifica-

138

tions, sequences diagrams, state chart diagrams, or collaboration diagrams.Sometimes, we even needed to reverse engineer code in order to gather thenecessary information for defining permissions.

Our experiences have shown that a post-hoc integration of access controlmay require an application redesign. In the example application if the petcatalog was empty, the catalog had been filled with data during the startup of the client application. This design had been chosen in order to makethe installation and usage of the example as simple as possible. This wasno longer feasible in the extended application because a customer does nothave the permissions for performing this task. To overcome this deficiency,we moved the population task into an administrative application.

Our experiences have also shown that the introduction of access controlin an application tends to be a complex task, if not an obstacle for thewhole development process. At the moment when the first permission isdefined, large parts of the application no longer work as expected. Reasonsinclude access control violations due to undocumented dependencies betweencomponents, and incompletely or incorrectly designed policies. The resultsof our case study have demonstrated that the concepts and tools of ModelDriven Security are a promising solution to this problems.

The usage of application roles as the interface between software devel-opment and administration offers considerable flexibility for adapting theapplication access control policy to the needs of a particular organization.However, the current approach for implementing authorization constraintsappears to be too static. Should constraints be configurable by the admin-istrator? Probably yes, but this would require a more sophisticated andexpensive (at least in terms of execution performances) infrastructure. Itshould be emphasized that constraints depend on the structure of an appli-cation, so changing constraints may also require to changing this structure,which is a software development task. The proposed solution is robust andinexpensive because the syntax is checked at build time and all informationneeded to evaluate a constraint can directly be accessed in the component.Furthermore, modern application servers allow one to rebuild and reinstallapplications within minutes without taking the application offline. So timeis not the problem here.

Apart from this it seems to be a promising idea to make bounds in con-straints, e.g. transfer limits, configurable by properties. Instead of literals wecould then use property names to refer to bounds as shown by the following

amount < {amountUpperBound}.

This would require to extend OCL as well as the prototype tool. We thereforedid not include this here.

139

140

Chapter 10

Conclusions

We have proposed Model Driven Security as a new software engineering ap-proach for the development of secure systems. Based on the concepts ofmodel-driven and generative software construction, Model Driven Securityproposes to formalize security properties as an integral part of system mod-els and to automatically generate systems with complete security infrastruc-tures from the models. The integration of security engineering into the over-all software development process is supported by guidelines and dedicateddevelopment activities.

In our language schema, we have developed new ideas for language devel-opment based on a combination of object-oriented metamodels and first-orderlogic. In our experience, metamodels are well suited for both formalizing andcombining modeling languages. Moreover, we were able to exploit availabletool support in the development of our prototype tool. We have extendedobject-oriented metamodeling in that a corresponding relational model iscreated from models in abstract syntax. These relational models are thefoundation for giving security design models a formal semantics and to pre-cisely define transformation functions. We have given examples of languagecombinations that illustrate our methodology as well as its application.

In this work, we applied Model Driven Security to the security aspectof access control, i.e. we have shown how access control architectures fordistributed systems can be developed based on our concepts. As a foun-dation, we proposed the security modeling language SecureUML, which isbased on substantial extensions to RBAC. We have given SecureUML a se-mantics based on first-order structures, which is used to give models a formalmeaning and to prove the correctness of code generation. We integrated Se-cureUML into two different system design modeling languages, gave exampleaccess control policies with the integrated languages and defined transforma-tion functions for generating access control architectures for different target

141

platforms.

In order to evaluate the feasibility of our approach, we have built a pro-totype tool and conducted an extensive case study. We also developed ideasof how to integrate the development of access control policies in the overalldevelopment process. We specified guidelines of how to identify roles andpermissions in a use case centric approach. As the most important practicalresult, we were able to extend the existing application by a working accesscontrol architecture according to the “least privileges” principle in compara-tively short time. The large ratio between model information and correspond-ing code in the target system (cf. Section 9.5) suggests that Model DrivenSecurity also helps to utilize platform mechanisms that would otherwise notbe manageable.

10.1 Related Work

Various extensions to the core RBAC model have been presented in the lit-erature. The need for flexible constraints on role assignments to expressdifferent kinds of high-level organizational policies, like separation of duty, isemphasized by [22]. A formal language to express these constraints, basedon first-order logic, is, for example, proposed by [10]. Ahn and Sandhu de-velop the “RSL99 language for Role-Based Separation of Duty Constraints”[1] and the Role-Based Constraint Language RCL2000 [2]. [4] show how theseconstraints can be expressed using OCL. In contrast to these works, we useauthorization constraints as additional restrictions on the permissions thata role has. As a result, SecureUML can (unlike RBAC) be used to expressaccess control policies that depend on the system state.

[3] give a description of the static, functional, and dynamic view of RBACusing UML diagrams. In contrast, our SecureUML metamodel provides astatic view of our RBAC extensions. However, we can combine SecureUMLwith other design modeling languages and use the results to develop systemswith access control infrastructures using security design models that supportthe formalization of different system views.

In the area of using UML for modeling security and access control, [16]show how UML can be used to model RBAC-like situations, in particularthe RBAC Framework for Network Enterprises (FNE). Although the au-thors also use a UML-based notation to express access control policies, theirsyntax is different from SecureUML. Furthermore, we propose an approachfor integrating policy models into system design models and facilitate thisby allowing the definition of authorization constraints on the system state.Also, they don’t consider the question of implementing infrastructures for

142

enforcing access control policies, where we propose a generative approach.

Jurjens [24, 25] proposes an approach to developing secure systems usingan extension of UML called UMLsec. Using UMLsec, one can annotate UMLmodels with formally specified security requirements, like confidentiality orsecure information flow. In contrast, our work focuses on a semantic ba-sis for annotating UML models given by class or statechart diagrams withaccess control policies, where the semantics provides a foundation for gener-ating implementations from these models or for analyzing the access controlpolicies.

Probably the most closely related work is the Ponder Specification Lan-guage [13, 12], which supports the formalization of authorization policieswhere rules specify which actions each subject can perform on given targets.As in our work, Ponder supports the organization of privileges in a RBAC-likeway where one may specify roles and define role-based policy rules. Ponderalso allows rules to be restricted by conditions expressed in a subset of OCL.Policies given in the Ponder Specification Language can directly be inter-preted and enforced by a policy management platform. As an alternative,the authors propose using code generators to create infrastructures for par-ticular access control technologies.

There are, however, important differences. To begin with, the possi-ble actions on targets are defined in Ponder by the target’s visible interfacemethods. Hence, the granularity of access control in Ponder is at the level ofmethods, whereas in our approach higher-level actions (e.g., updating an ob-ject’s state) can be defined using action hierarchies. Second, while Ponder isgiven an operational semantics, we employ a denotational semantics directlybased on our RBAC extensions. Finally, and most importantly, Ponder’sauthorization rules refer to a hierarchy of domains, in which the subjects andtargets of an application are stored. In contrast, our approach integrates thesecurity modeling language with the design modeling language, providing ajoint vocabulary for building combined models. In our view, the overall secu-rity of systems benefits by building such security design models, which tightlyintegrate security policies with system design models during system design,and using these as a basis for subsequent development.

10.2 Future Work

There are a number of promising directions for future work. To begin with,the languages we have presented constitute three different, representativeexamples of security and design modeling languages. There are many in-teresting questions remaining on how to design such languages and how to

143

specialize them for particular modeling domains.On the security modeling side, new security modeling languages could

be defined for other security aspects, like digital signatures or auditing, butalso SecureUML and access control offer promising options for future work.For example, one could enrich SecureUML with primitives for modeling ad-ditional access control aspects, like impersonation, or information about de-pendencies between protected actions. Support for impersonation would offernew design options, whereas formalized dependencies between action wouldbe helpful in the analysis of access control policies. For example, this in-formation could be used to determine whether the execution of a particularaction is likely to succeed under the consideration of the permissions of thecaller on the action and all actions it depends on. Moreover, SecureUMLcould be extended by a formally defined vocabulary for defining authoriza-tion requirements similar to the annotations proposed in Section 8.2.

On the design modeling side, one could explore other design modelinglanguages, e.g., other UML diagram types (like Use Case Diagrams or Se-quence Diagrams), which would support modeling different views of systemsat different levels of abstractions. What is attractive here is that our use ofdialects to join languages provides a way of decomposing language design sothat these problems can be tackled independently.

We have given SecureUML a first-order semantics based on relationaland state-oriented extensions of RBAC. Our semantics has the advantage ofbeing fairly simple: everything is formalized using basic concepts from many-sorted, first-order logic. Formalizing access control this way, by focusing onparticular time points, is adequate to explain the operational decisions madeduring system execution. However, it has the disadvantage that one cannotreason about and compare the behavior of a system at different time points.To support this, one should probably move to a richer formalism like a first-order temporal logic.

We have used our semantics both to clarify what models mean and toreason about the correctness of code generation. Moreover, we have shownin Section 6.4 how the semantics can also be used to provide a basis forformally verifying the correctness of the code generators. However, we havejust scratched the surface of what is possible here and we believe that ModelDriven Security can play a central role in analyzing and certifying securesystems. Since our models are formal, we can ask questions about themand get well-defined answers, like the examples given in Section 5.3.1. Morecomplex kinds of analysis should be possible too. Just as some CAD toolshave built-in model checkers for analyzing properties of designs, it should bepossible to provide mechanical support, within a CASE-tool, for calculatingwith security design models or analyzing safety and other kinds of invariance

144

properties. For example, we might calculate a symbolic description of thosestates that allow Alice to withdraw money from her account, or, alternatively,prove that in all system states Alice cannot withdraw money from Bob’saccount.

145

146

Appendix A

Appendix

Here we sketch details of several transformation functions, which were omit-ted in the body of the thesis. In Section A.1 we provide details on thetranslation of OCL expressions to first-order syntax. Afterwards, we listthe generation rules for mapping the atomic actions of ComponentUML toXML method elements. In Section A.3 we explain the translation of OCLexpressions to Java syntax.

A.1 OCL Translation to First-order Logic

Our semantics for authorization constraints is completed by giving a function

[[.]] : LOCL → LFOL ,

translating OCL syntax to first-order syntax.Boolean expressions are translated directly to their first-order counter-

parts as follows

[[φ1 and φ2]] := [[φ1]] ∧ [[φ2]]

[[φ1 or φ2]] := [[φ1]] ∨ [[φ2]]

[[ not φ]] := ¬[[φ]]

Equality of Boolean expressions is translated as

[[t1 = t1]] := [[t1]] ↔ [[t2]] ,

and equality of expression of other types is simply translated as

[[t1 = t1]] := [[t1]] = [[t2]] .

147

The translation of the relational operators uses the corresponding first-orderrelations,

[[t1 <> t2]] := 6=s ([[t1]], [[t2]])

[[t1 < t2]] := <s ([[t1]], [[t2]])

[[t1 > t2]] := >s ([[t1]], [[t2]])

[[t1 <= t2]] := ≤s ([[t1]], [[t2]])

[[t1 >= t2]] := ≥s ([[t1]], [[t2]]) ,

where s is the sort corresponding to the type of the expressions t1 and t2.The base cases for the translation of OCL expressions of general type are

the translations of self and caller:

[[self]] := selfs[[caller]] := caller ,

where s is the sort corresponding to the type of the context of the expression.There are three recursive cases:

• method calls

[[term.function(arg1, . . . , argn)]] := f([[term]], [[arg1]], . . . , [[argn]]) ,

where f is the function symbol (or predicate symbol, in case of a func-tion returning a Boolean) corresponding to the function “function” be-longing to the term “term”.

• navigation on attributes and association ends of multiplicity 1

[[term.feature]] := f([[term]]) ,

where f is the function symbol (or predicate symbol, in case of a func-tion returning a Boolean) corresponding to the feature “feature” be-longing to the term “term”.

• existentially quantified expressions on attributes and association endsof type Set (multiplicity 0..1 or n).

[[term.feature->exists(x|expression)]] := ∃x : p([[term]], x)∧([[expression]]) ,

where p is the predicate symbol corresponding to the association endor attribute ”feature” belonging to the term “term”.

148

A.2 Translation of ComponentUML Atomic

Actions to EJB method-elements

EntityCreate(a) 7→entityCreate

<method><ejb-name>[[actionBeanName(a)]]</ejb-name><method-intf>LocalHome</method-intf><method-name>create</method-name><method-params/>

</method>

EntityDelete(a) 7→entityDelete

<method><ejb-name>[[actionBeanName(a)]]</ejb-name><method-intf>Local</method-intf><method-name>remove</method-name></method-params>

</method><method><ejb-name>[[actionBeanName(a)]]</ejb-name><method-intf>LocalHome</method-intf><method-name>remove</method-name><method-params><method-param>javax.ejb.EJBLocalObject</method-param>

</method-params></method>

MethodExecute(a) 7→methodExecute

<method><ejb-name>[[actionBeanName(a)]]</ejb-name><method-intf>Local</method-intf><method-name>[[actionMethodName(a)]]</method-name>[[actionMethodParameters(a)]]

</method>

AttributeRead(a) 7→attrRead

<method><ejb-name>[[actionBeanName(a)]]</ejb-name><method-intf>Local</method-intf><method-name>get[[firstUp(name(a))]]</method-name><method-params/>

</method>

AttributeUpdate(a) 7→attrUpdate

<method><ejb-name>[[actionBeanName(a)]]</ejb-name><method-intf>Local</method-intf>

149

<method-name>set[[firstUp(name(a))]]</method-name><method-params><method-param>[[attrType(a)]]</method-param>

</method-params></method>

AssocEndRead(a) 7→assocEndRead

<method><ejb-name>[[actionBeanName(a)]]</ejb-name><method-intf>Local</method-intf><method-name>get[[firstUp(name(a))]]</method-name><method-params/>

</method>

ToOneUpdate(a) 7→toOneUpdate

<method><ejb-name>[[actionBeanName(a)]]</ejb-name><method-intf>Local</method-intf><method-name>set[[firstUp(name(a))]]</method-name><method-params><method-param>[[assocEndType(a)]]</method-param>

</method-params></method>

ToManyUpdate(a) 7→toManyUpdate

<method><ejb-name>[[actionBeanName(a)]]</ejb-name><method-intf>Local</method-intf><method-name>addTo[[firstUp(name(a))]]</method-name><method-params><method-param>[[assocEndType(a)]]</method-param>

</method-params></method><method><ejb-name>[[actionBeanName(a)]]</ejb-name><method-intf>Local</method-intf><method-name>removeFrom[[firstUp(name(a))]]</method-name><method-params><method-param>[[assocEndType(a)]]</method-param>

</method-params></method>

A.3 OCL Translation to Java

The translation from OCL to Java is given by the function

[[.]] : LOCL → LJava ,

150

translating an expression in OCL syntax to an expression in Java syntax.Boolean expressions are translated to their Java counterparts, e.g.,

[[φ1 and φ2]] := [[φ1]] && [[φ2]]

[[φ1 or φ2]] := [[φ1]] || [[φ2]]

[[notφ]] := ! [[φ]] .

Equality of expressions of type Boolean, Real or Integer is translated as

[[t1 = t1]] := [[t1]] = [[t2]] ,

and equality of expression of other types is simply translated as

[[t1 = t1]] := [[t1]].equals([[t2]]) .

The translation of the comparison operators for Real and Integer uses thecorresponding Java operators or combinations of these operators, e.g.,

[[t1 <> t2]] := [[t1]]! = [[t2]]

[[t1 > t2]] := [[t1]] > [[t2]]

[[t1 < t2]] := [[t1]] < [[t2]] .

Comparison on strings is translated to

[[t1 <> t2]] := !([[t1]].equals([[t2]])) .

The base cases for the translation of OCL expressions of general type arethe translations of self and caller:

[[self]] := this

[[caller]] := ctx.getCallerPrincipal().getName() ,

where ctx is the object provided by the EJB container to access contextinformation. In this case, ctx is used to obtain the current callers name. thecaller name.

There are three recursive cases:

• method calls

[[term.function(arg1, . . . , argn)]] := [[term]].method([[arg1]], . . . , [[argn]]) ,

where method is the method corresponding to the function “function”belonging to the term “term”.

151

• navigation on attributes and association ends of multiplicity 1

[[term.feature]] := [[term]].getFeature() ,

where getFeature is the method for reading the value of the corre-sponding attribute or association end belonging to the term “term”.

• existentially quantified expressions on attributes and association endsof type Set (multiplicity 0..1 or n). This case is much more difficultto implement because we have to iterate over a set of objects and toevaluate an (arbitrary) expression on (possibly) each of these objects.This cannot be implemented in a single java expression. Therefore, weuse (a) additional runtime classes and (b) java anonymous inner classesto implemented this kind of expressions. The transformation has twoparts. First, the term

[[term.feature->exists(x|expression)]]

is transformed to the Java Boolean expression

new OCLSet([[term]].getFeature()).exists(expressionObject) .

In the first part of this expression, an object of type OCLSet is in-stantiated from the result of the call to the get-method of the feature”feature” of the term ”term”. OCLSet is a class provided by our proto-typical runtime framework. Its method exists(OCLExpression) is used toevaluate a Boolean expression for all objects in the set. The expressionis passed in as an object of type OCLExpression. Therefore, for eachterm of type

[[term.feature->exists(x|expression)]]

a java anonymous class is generated as subclass of OCLExpression asfollows

OCLExpression expressionObject = new OCLExpression(){public Boolean evaluate(Object cursor){entryType x = (entryType )cursor;return [[expression]];

}};

Such an object has a method evaluate, which gets passed an object outof a collection, casts it to the collection’s element type, e.g. String, andevaluates the expression for this object.

152

Bibliography

[1] Gail-Joon Ahn and Ravi S. Sandhu. The RSL99 language for role-basedseparation of duty constraints. In Proceedings of the fourth ACM work-shop on Role-based access control, pages 43–54. ACM Press, 1999.

[2] Gail-Joon Ahn and Ravi S. Sandhu. Role-based authorization con-straints specification. ACM Transactions on Information and SystemSecurity, 3(4):207–226, November 2000.

[3] Gail-Joon Ahn and Michael Eonsuk Shin. UML-based representation ofrole-based access control. In 9th IEEE International Workshop on En-abling Technologies: Infrastructure for Collaborative Enterprises (WET-ICE 2000), pages 195–200. IEEE Computer Society, June 2000.

[4] Gail-Joon Ahn and Michael Eonsuk Shin. Role-based authorization con-straints specification using object constraint language. In 10th IEEEInternational Workshop on Enabling Technologies: Infrastructure forCollaborative Enterprises (WETICE 2001), pages 157–162. IEEE Com-puter Society, June 2001.

[5] David Akehurst and Stuart Kent. A relational approach to definingtransformations in a metamodel. In UML 2002 - The Unified Model-ing Language. Model Engineering, Languages, Concepts, and Tools. 5thInternational Conference, Dresden, Germany, September/October 2002,Proceedings, volume 2460 of LNCS, pages 243–258. Springer, 2002.

[6] David A. Basin, Jurgen Doser, and Torsten Lodderstedt. Model drivensecurity for process-oriented systems. In 8th ACM Symposium on AccessControl Models and Technologies, pages 100–109. ACM Press, 2003.

[7] David A. Basin, Jurgen Doser, and Torsten Lodderstedt. Model drivensecurity: from UML models to access control infrastructures. TechnicalReport 414, ETH Zurich, July 2003.

153

[8] Derek Beyer. C# COM+ Programming. John Wiley & Sons, book andcd-rom (october 15, 2001) edition, 2001.

[9] Achim D. Brucker and Burkhart Wolff. A Proposal for a Formal OCLSemantics in Isabelle/HOL. In Cesar Munoz, Sophiene Tahar, and Vıc-tor Carreno, editors, TPHOLs 2002, LNCS. Springer-Verlag, 2002.

[10] Fang Chen and Ravi S. Sandhu. Constraints for role-based access con-trol. In Proceedings of the first ACM Workshop on Role-based accesscontrol, pages 39–46. ACM Press, 1996.

[11] Common Criteria Recognition Arrangement. Common Criteria forInformation Technology Security Evaluation, 1999. http://www.

commoncriteria.org/cc/cc.html.

[12] Nicodemos Damianou. A Policy Framework for Management of Dis-tributed Systems. PhD thesis, Imperial College, University of London,2002.

[13] Nicodemos Damianou, Naranker Dulay, Emil Lupu, and Morris Sloman.The ponder policy specification language. In Morris Sloman, Jorge Lobo,and Emil C. Lupu, editors, Policies for Distributed Systems and Net-works (POLICY 2001), number 1995 in LNCS, pages 18–38. Springer-Verlag, January 2001.

[14] Premkumar T. Devanbu and Stuart Stubblebine. Software engineeringfor security: a roadmap. In Proceedings of the conference on The futureof Software engineering, pages 227–239. ACM Press, 2000.

[15] Wolfgang Droschel (Editor) and Manuela Wiemers (Editor). Das V-Modell 97. Oldenbourg, 1999.

[16] Pete Epstein and Ravi S. Sandhu. Towards a UML based approach torole engineering. In Proceedings of the fourth ACM workshop on Role-based access control, pages 135–143. ACM Press, 1999.

[17] Frank Finger. Design and Implementation of a Modular OCL Compiler,2000. http://www-st.inf.tu-dresden.de/ocl/ff3/diplom.pdf.

[18] Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides.Design Patterns Elements of Reusable Object-Orientated Software.Addison-Wesley, 1995.

[19] Li Gong. Inside JavaTM2 Platform Security: Architecture, API Design,and Implementation. Addison-Wesley, 1st edition, 1999.

154

[20] Jason Hunter. Java Servlet Programming, 2nd Edition. O’Reilly &Associates, 2001.

[21] Interactive Objects Software GmbH. ArcStyler Product Documentation,2003. http://www.arcstyler.com/.

[22] Trent Jaeger. On the increasing importance of constraints. In Proceed-ings of fourth ACM workshop on Role-based access control, pages 33–42.ACM Press, 1999.

[23] Java Community Process. Java Metadata Interface(JMI) Spec-ification, Version 1.0, 2002. http://www.jcp.org/aboutJava/

communityprocess/final/jsr040/.

[24] Jan Jurjens. Towards development of secure systems using UMLsec. InHeinrich Hussmann, editor, Fundamental Approaches to Software Engi-neering (FASE/ETAPS 2001), number 2029 in LNCS, pages 187–200.Springer-Verlag, 2001.

[25] Jan Jurjens. UMLsec: Extending UML for secure systems development.In Jean-Marc Jezequel, Heinrich Hussmann, and Stephen Cook, editors,UML 2002 - The Unified Modeling Language, volume 2460 of LNCS,pages 412–425. Springer-Verlag, 2002.

[26] Philippe Kruchten. The Rational Unified Process. An Introduction.Addison-Wesley Professional, 2000.

[27] Torsten Lodderstedt, David A. Basin, and Jurgen Doser. SecureUML:A UML-based modeling language for model-driven security. In UML2002 - The Unified Modeling Language. Model Engineering, Languages,Concepts, and Tools. 5th International Conference, Dresden, Germany,September/October 2002, Proceedings, volume 2460 of LNCS, pages 426–441. Springer, 2002.

[28] Terry Mayfield, J. Eric Roskos, Stephen R. Welke, and John M. Boone.Integrity in automated information systems. Technical report, NationalComputer Security Center, 1991.

[29] Richard Monson-Haefel. Enterprise JavaBeans (3rd Edition). O’Reilly& Associates, 2001.

[30] Object Management Group. OMG Unified Modeling Language Specifi-cation, Version 1.4, 2001. (document: formal/01-09-67).

155

[31] Object Management Group. Meta Object Facility (MOF), version 1.4,2002. (document: formal/2002-04-03).

[32] Object Management Group. MOF 2.0 Query / Views / TransformationsRFP, 2002. (document: ad/2002-4-10).

[33] Object Management Group. UML Profile for Enterprise DistributedObject Computing Specification, 2002. (document: ptc/2002-02-05).

[34] Object Management Group. MDA Guide Version 1.0.1, 2003. (docu-ment: omg/2003-06-01).

[35] Office for Official Publications of the European Communities. Informa-tion Technology Security Evaluation Criteria, Version 1.2, 1991.

[36] Samuele Pedroni and Noel Rappin. Jython Essentials. O’Reilly & As-sociates, 1st edition, 2002.

[37] James Rumbaugh, Ivar Jacobson, and Grady Booch. The Unified Mod-eling Language Reference Manual. Addison-Wesley, 1998.

[38] Ravi S. Sandhu, Edward J. Coyne, Hal L. Feinstein, and Charles E.Youman. Role-based access control models. IEEE Computer, 29(2):38–47, 1996.

[39] Dongwan Shin, Gail-Joon Ahn, Sangrae Cho, and Seunghun Jin. Onmodeling system-centric information for role engineering. In SACMAT2003 - Eighth ACM Symposium on Access Control Models and Tech-nologies, June 2-3, 2003, Villa Gallia, Como, Italy, Proceedings, pages169–178. ACM Press, 2003.

[40] Sun Microsystems, Inc. Enterprise JavaBeans Specification, Version 2.0,2001. http://java.sun.com/ejb/docs.html.

[41] Sun Microsystems, Inc. JavaTMServlet Specification Version 2.3, 2001.http://java.sun.com/products/servlet/download.html.

[42] Sun Microsystems, Inc. XML DTD for the EJB 2.0 deployment descrip-tor, 2001. http://java.sun.com/dtd/ejb-jar 2 0.dtd.

[43] Sun Microsystems, Inc. XML DTD for the Java Servlet 2.3 deploymentdescriptor, 2001. http://java.sun.com/dtd/web-app 2 3.dtd.

[44] Technische Universitat Dresden. Dresden OCL Toolkit, 2003. http:

//dresden-ocl.sourceforge.net/.

156