Model Driven Security
from UML Models to Access Control Architectures
Dissertation zur Erlangung des Doktorgrades der Fakult¨at f¨ur Angewandte Wissenschaften der Albert-Ludwigs-Universit¨at Freiburg im Breisgau
vorgelegt von Torsten Lodderstedt
• Dekan: Prof. Dr. Thomas Ottmann • Pr¨ufungskommision:
– Prof. Dr. Stefan Leue
– Prof. Dr. Christoph Scholl
– Prof. Dr. David Basin
– Prof. Dr. G¨unter M¨uller • Termin der Disputation: 15.03.2004
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 f¨ur solche Technologien sind Zugriffskontrolle zum Schutz von Systemressourcen vor unerlaubtem Zu-griff, Verschl¨usselung, um die Vertraulichkeit von Daten w¨ahrend ihrer ¨ Uber-tragung ¨uber ein Netzwerk zu sch¨utzen, und die Verwendung von digitalen Signaturen zum elektronischen Unterzeichnen von Vertr¨agen. Obwohl eine große Anzahl von Sicherheitsarchitekturen und -technologien verf¨ugbar ist, gibt es beinahe t¨aglich Berichte von Fehlern in den Sicherheitsmechanismen von IT-Systemen.
Warum ist es so schwierig, robuste, sichere Systeme zu entwickeln? Eine Analyse der Softwareentwicklungsprozesse wie sie heute typischerweise ange-wendet werden zeigt, daß Sicherheit nicht systematisch sondern zumeist ad hoc behandelt wird. In vielen F¨allen werden Sicherheitsanforderungen erst kurz vor oder w¨ahrend der Inbetriebnahme eines Systems analysiert und im-plementiert. Hinzu kommt, daß die Systementwicklung und die Realisierung von Sicherheitmechanismen zumeist getrennt von verschiedene Personengrup-pen durchgef¨uhrt werden, den Software-Entwicklern auf der einen Seite und den Sicherheitsexperten auf der anderen Seite. Daf¨ur gibt es technologische und kulturelle Gr¨unde.
Insbesondere muß man ein Defizit an Methoden und Werkzeugen kon-statieren, die eine enge Integration der Sicherheit in den allgemeinen Soft-wareentwicklungsprozeß unterst¨utzen. Selbst Standardprozesse, wie der Ra-tional Unified Process [26] oder das deutsche V-Modell [15] geben nur ober-fl¨achliche Hinweise, wie Sicherheit ber¨ucksichtigt werden sollte. Des weite-ren spielt die Sicherheit im typischen Projektplan keine prominente Rolle und sie wird auch durch die Struktur der meisten Entwicklungsorganisatio-nen nicht unterst¨utzt. Auch dort kann man eine starke Trennung zwischen Software-Entwicklern und Sicherheitsexperten beobachten. Das Resultat die-ser Vorgehensweise sind IT-Systeme in denen die Sicherheit als nachrangiges Problem behandelt wird und wo Sicherheitsmechanismen nur schlecht in das Gesamtsystem integriert sind.
Die Notwendigkeit diese M¨angel zu beheben wurden in der Literatur schon festgestellt (z.B. in [14]) und die zunehmende Nachfrage am Markt nach Sy-stemen mit zertifizierten Sicherheitseigenschaften verst¨arkt den Druck. Denn Zertifizierungsstandards wie die “Information Technology Security Evalua-tion Criteria” [35] oder die “Common Criteria” [11] erfordern vor allen Dingen eines: einen ausgereiften Softwareentwicklungsprozeß, in welchem Sicherheit ein integraler Bestandteil ist.
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 gew¨ unsch-ten Sicherheitseigenschafunsch-ten des Systems beschreiben. Basierend auf diesen Modellen werden dann mit Hilfe von Werkzeugen Systemarchitekturen mit kompletten und vollst¨andig konfigurierten Sicherheitsmechanismen generiert. Auf diese Weise erm¨oglicht Model Driven Security die enge Integrati-on vIntegrati-on Sicherheit in den Entwicklungsprozess. Unsere Methode kann daher verwendet werden, um die Produktivit¨at bei der Entwicklung von sicheren Softwaresystemen zu erh¨ohen und die Qualit¨at der resultierenden Systeme zu verbessern.
Anstatt eine einzige Modellierungssprache f¨ur diesen Prozeß vorzugeben, schlagen wir ein Schema f¨ur die Definition solcher Sprachen vor, in welchem Sprachen f¨ur die Systemmodellierung mit solchen f¨ur die Modellierung von Sicherheitseigenschaften kombiniert werden.
Wir pr¨asentieren verschiedene Beispiele f¨ur die Anwendung dieses Sche-mas, in welchen UML-basierte Modellierungssprachen mit einer Sprache f¨ur die Spezifikation von Zugriffskontrollmodellen kombiniert werden. Wir zeigen außerdem, wie auf der Basis von Modellen in diesen Sprachen Zugriffskon-trollarchitekturen f¨ur verteilte Systeme generiert werden k¨onnen. Die Model-lierungssprachen und der Generierungsprozess sind semantisch wohl fundiert und basieren auf einer Erweiterung von rollenbasierter Zugriffskontrolle. Wir haben unsere Methode in einem Werkzeug implementiert, welches wir im Rahmen einer Fallstudie angewendet haben, und wir berichten von unseren Erfahrungen.
Preface
We present a new approach to building secure systems. In our approach, which we call Model Driven Security, designers specify system models along with their security requirements and use tools to automatically generate sys-tem architectures from the models including complete, configured security infrastructures. In that way, Model Driven Security helps to tightly integrate security into the software development process. As a result, our approach can be used to improve both the productivity of the developers of secure software systems and the quality of the resulting systems.
Rather than fixing one particular modeling language for this process, we propose a schema for constructing such languages that combines languages for modeling systems with languages for modeling security. Thus the schema allows language designers to leverage expert know-how that is required to define a modeling language for a particular area as well as accompanying methods and tools.
We present different instances of this schema, which combine different UML modeling languages with a security modeling language for formalizing access control requirements. From models in these languages, we automati-cally generate access control architectures for distributed applications. The modeling languages and generation process are semantically well-founded and are based on an extension of role-based access control. We have implemented this approach in a prototypical tool that we used to conduct a case study and report on experiences.
Contents
1 Introduction 11 1.1 Contributions . . . 15 1.2 Organization . . . 16 2 Background 19 2.1 A Design Problem . . . 192.2 Model Driven Architecture . . . 20
2.2.1 The Unified Modeling Language . . . 21
2.2.2 The Meta Object Facility . . . 25
2.2.3 Defining Modeling Languages . . . 28
2.2.4 Model Transformations . . . 30
2.3 Role-Based Access Control . . . 30
2.4 Security Architectures . . . 32
2.4.1 Enterprise JavaBeans . . . 32
2.4.2 Enterprise Services for .NET . . . 35
2.4.3 Java Servlets . . . 35
3 Model Driven Security: an Overview 37 3.1 Language Definition Techniques . . . 39
3.1.1 MOF-Mapping to Relational Models . . . 39
3.1.2 The Role of Semantics in Model Driven Security . . . . 41
3.2 Combining Modeling Languages . . . 41
3.3 Model Transformation . . . 44
3.4 Outlook . . . 45
4 SecureUML 47 4.1 Abstract Syntax . . . 47
4.2 Concrete Syntax . . . 49
4.3 Building SecureUML Dialects . . . 53
4.3.1 Integrating the Abstract Syntax . . . 54
4.3.3 The Structure of Security Design Models . . . 56
4.4 Semantics . . . 57
4.4.1 Static Part . . . 58
4.4.2 Dynamic Part . . . 59
4.4.3 Default Behavior . . . 62
5 Example Modeling Language: ComponentUML 63 5.1 Language Definition . . . 63
5.2 SecureUML Dialect for ComponentUML . . . 65
5.2.1 Extending the Abstract Syntax . . . 65
5.2.2 Formal Definition of ComponentUML Models . . . 68
5.2.3 Extending the Concrete Syntax . . . 70
5.3 Example Authorization Policy . . . 72
5.3.1 Policy Semantics . . . 73
6 Generating Systems from ComponentUML Models 75 6.1 Notation . . . 76
6.2 Enterprise JavaBeans . . . 77
6.2.1 Basic Generation Rules for EJB . . . 77
6.2.2 Generating Access Control Infrastructures . . . 81
6.3 Correctness of Generation . . . 91
6.3.1 Informal Semantics of EJB Access Control . . . 91
6.3.2 Proof Strategy and Discussion . . . 92
6.4 Verification of the Sub-function for Declarative Access Control 95 6.4.1 EJB Declarative Access Control . . . 96
6.4.2 Model Transformation Function . . . 97
6.4.3 Proof . . . 99
6.4.4 Discussion . . . 103
6.5 Transformation Function for .NET Systems . . . 103
6.5.1 Basic Generation Rules for .NET . . . 103
6.5.2 Generating Access Control Infrastructures . . . 104
7 ControllerUML 107 7.1 Language Definition . . . 107
7.2 SecureUML Dialect for ControllerUML . . . 109
7.2.1 Extending the Abstract Syntax . . . 110
7.2.2 Extending the Concrete Syntax . . . 111
7.3 Example Authorization Policy . . . 112
7.4 Transformation to Web Applications . . . 113
7.4.1 Basic Transformation Function . . . 113
8 Tool Support and Development Process 119 8.1 Tool Support . . . 119 8.1.1 Tool Foundation . . . 119 8.1.2 Prototype Architecture . . . 120 8.1.3 OCL Support . . . 121 8.1.4 Security Designer . . . 122 8.2 Development Guidelines . . . 124 8.2.1 Analysis . . . 125 8.2.2 Design . . . 126 8.2.3 Implementation . . . 128 8.2.4 Deployment . . . 129 9 Case Study 131 9.1 Use Case Model . . . 131
9.2 Design Model . . . 133
9.3 Use Case Model Annotations . . . 135
9.4 Access Control Policy . . . 136
9.5 Evaluation . . . 138
10 Conclusions 141 10.1 Related Work . . . 142
10.2 Future Work . . . 143
A Appendix 147 A.1 OCL Translation to First-order Logic . . . 147
A.2 Translation of ComponentUML Atomic Actions to EJBmethod -elements . . . 149
A.3 OCL Translation to Java . . . 150
Chapter 1
Introduction
Security is an integral part of most modern IT systems and designing such systems requires properly identifying, integrating, and configuring different security technologies. Examples of such technologies include access control for preventing unauthorized access to system resources, encryption to ensure the confidentiality of data during network transmissions, and digital signa-tures for electronic contract signing. Although a broad number of security architectures 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 the system development processes typically used suggests one reason: security is often managed in an ad-hoc fashion where requirements are analyzed and mechanisms are implemented shortly before, or even during, the system in-stallation and deployment phase. Concerns are often separated and handled separately by software engineers and security specialists. This has technolog-ical reasons as well as cultural ones. In particular, there is a lack of methods and tools for tightly integrating security into the development process. Even standard 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 typical project plan nor is it supported by the structure of most development orga-nizations with a strong separation between software developers and security experts. The result is systems where security is often dealt with as an af-terthought and where security mechanisms are poorly integrated into the system.
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 software systems with certified security properties. Certification standards like the “Information Technology Security Evaluation Criteria” [35] or the “Common
Criteria” [11] first of all require a mature software development process in which security is an integral part.
We propose Model Driven Security as an approach to overcoming this deficiency. Model Driven Security provides methods and tools to tightly integrate security into the development process. The key idea is to use high-level, visual models that integrate system design and security design and to use generative techniques to automate the construction of systems from these designs. Furthermore, developers are guided with rules and patterns how to use these tools in the development of secure systems.
Describing systems using models and generating implementations from these models is an established practice in software engineering. Most mod-ern CASE-tools support the generation of source code skeletons for different programming languages and database schema definitions from system mod-els. In contrast, models are typically used in security engineering to analyze and verify the security relevant system properties, but not for automatically constructing security mechanisms for these systems.
By combining models both of the system and the security design we close the 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 general software 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 defining modeling languages and the Unified Modeling Language (UML) [30] as the standard modeling language in the area of object-oriented software devel-opment. Furthermore, a language for specifying transformation functions is currently being standardized [32]. Many development tools implement these standards and they can be extended to support Model Driven Security.
As Figure 1.1 suggests, MDA supports a development philosophy where a system 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 state charts for formalizing a system design. Models are automatically translated to other models of the same system by applying model transformation func-tions. For example, a requirement specification can be transformed into an initial system design model that functions as a starting point for designing the system in detail. Afterwards, a system implementation for a particular execution platform can automatically be generated from the system design model.
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 syssys-tem design models is an application of model transformation. As an example, Figure 1.1 depicts the transformation of the system model to a system of distributed components that can be executed in an application server.
In Model Driven Security, security requirements are directly integrated into design models. Design models are combined with security models, lead-ing to new kinds of models that we call security design models. In these models, security policies refer to the elements of the core system model, e.g., components, business objects, methods, attributes, etc. In this way, we avoid the creation of separate and partially redundant security models. This is be-cause most of the information needed to express security properties, e.g. the protected 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 this can work on the example of access control: here, the design model is given with a class diagram enriched with new modeling elements that represent security roles and permissions. This combination can be used to define an application’s access control policy.
Figure 1.2 also depicts the generative part of Model Driven Security. We extend existing transformation rules (as part of Model Driven Architecture) in order to automatically generate a policy-conform security infrastructure using the security mechanisms that are available in the target system plat-form.
+ Security Model
System Model
A B <<Permission>> Customer<<Role>>
(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, we propose a schema for constructing security design languages by combining existing security modeling and system design modeling languages. In this schema, we use models, designated as metamodels, to define and combine different modeling languages in a modular way. Moreover, mathematical techniques 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 to the development of access control architectures for distributed systems. We propose the security modeling language SecureUML, which is based on role-based access control (RBAC) [38], and show its integration into two system design languages based on UML class diagrams and state charts. From mod-els in these languages, we generate systems with access control architectures for the technologies Enterprise JavaBeans (EJB) [29], .NET [8], and Java Servlets [20]. Moreover, we propose a development process, which guides developers during the analysis, design, and implementation of systems with access 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 have designed and implemented an access control policy for an EJB-based appli-cation. We also used the case study to validate our software development process and report on experiences.
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 new methodology for the development of secure systems is to make security an in-tegral part of the overall software development process. We show how the gap between software and security engineering can be closed by combining general design and security relevant information in integrated security design models. We also show how to close the gap between security requirements analysis and implementation by automatically generating systems with complete se-curity architectures from sese-curity design models. Moreover, we illustrate how these measures can be integrated into the overall software development pro-cess by adding security-specific development activities to the different stages of the development process.
The definition of security design languages is at the heart of Model Driven Security. We therefore propose a language schema for building security de-sign languages in a modular way. We show how modeling languages can be combined using metamodels in a way similar to combining software building blocks and how this affects the model semantics. In this way, the language schema allows language designers to exploit existing system as well as security modeling 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 the abstract syntax of a modeling language can be defined with object-oriented metamodels and how mathematical techniques can be used to give models a formal semantics. We also show how modeling languages can be equipped with a graphical concrete syntax on the example of UML notations. Thus our language schema combines the best of both worlds, object-oriented and formal methods.
Although our focus is on security, we believe that our approach has gen-eral applicability and is relevant to research on other software development methodologies. Our work contributes to an understanding of how one can create software development methods that combine the advantages of both object-oriented and formal methods. With Model Driven Security we show a pragmatic approach for extending modern model-driven development ap-proaches with formal techniques. Both the formal methods community and practical software engineers can benefit from such an approach. From the formal method perspective this means we show a way how formal methods can be made available to general software engineers by using them under the hood of development tools or during their development. In that way, prac-tical software engineers can be provided with a new generation of software
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 to the development of access control architectures for distributed systems. We introduce SecureUML, which is a security modeling language for defining access control policies based on an extended model of role-based access con-trol. As a foundation, we propose a substantial extension to RBAC that is called 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, which is impossible with standard RBAC (cf. [38]).
We explain in detail how we have developed SecureUML based on the language definition techniques proposed by Model Driven Security. We show how a modeling language for RBAC can precisely be defined that is both extensible and semantically well-founded. Furthermore, we illustrate how to integrate SecureUML into system design languages in order to equip these language with a vocabulary and semantics for access control on the example of 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 potential of 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 design problem 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 the focus on the language schema and model transformation. The security mod-eling language SecureUML will be introduced in Chapter 4 and afterwards in Chapter 5, we will show how a security design language can be built based on SecureUML. We will introduce the example system design language Com-ponentUML, which is based on UML class diagrams, and integrate it with SecureUML afterwards.
A key aspect of Model Driven Security is the automatic generation of security infrastructures. In Chapter 6 we will explain how we extended the existing transformation function for creating EJB and .NET systems from ComponentUML models with rules for generating access control infras-tructures. Our extensions are semantically well-founded and we will discuss
transformation correctness and demonstrate the usage of formal proofs for verifying the correctness of transformation functions on an example.
In order to demonstrate the general applicability of our approach, we will create a second security design language. In Chapter 7, we will introduce the system modeling language ControllerUML, which is based on UML state charts, and afterwards integrate it with SecureUML. We will also outline a transformation function that translates ControllerUML models to access control 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 control architectures. Chapter 9 will discuss the case study we have conducted using our prototype tool. We will show exemplary parts of the example model and discuss our experiences afterwards. We will draw our conclusions in Chapter 10 along with a discussion of related and future work.
Chapter 2
Background
We first introduce a design problem along with its security requirements that will serve as a running example throughout this thesis. Then we explain the framework we based our development methodology upon: the Model Driven Architecture. Afterwards, we introduce the technological foundations of our work, 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 of a system for administrating meetings. The system should maintain a list of users (we will ignore issues such as user administration) and records of meetings. A meeting has an owner, a list of participants, a time, and a place. Users may carry out standard operations on meetings such as creating, reading, editing, and deleting them. A user may also cancel a meeting, which deletes the meeting entry and also notifies all participants by email.
As the thesis proceeds, we will see how design models for this system are enriched with the following (here informally given) access control policy:
1. All users of the system can create new meetings and read all meeting entries.
2. Only the owner of a meeting may change meeting data and cancel or delete 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 a complete access control infrastructure.
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 the divergence 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 an initiative to tackle these problems. The so-called Model Driven Architecture (MDA) is centered around building models and generating software systems from 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-level representation into a more (mostly platform) specific one. The MDA goes a step further in that it provides an architecture formodel driven development processes and managed system evolution.
MDA enables a development process where a system is defined by models at 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 to generate 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 transforming models into other models or code and tracking dependencies among models. Managed system evolution means to actively manage all transitions of a software system, including changes in the underlying execution and ment platforms. This imposes two key requirements to a software develop-ment architecture:
1. Execution platform independence: The system models should be as independent as needed of the execution technology, e.g. Java 2 Platform Enterprise Edition (J2EE) or Microsoft .NET. This will consequently require to define system models that comprise all aspects of a system, including business logic, thus enabling the generation of complete and executable system infrastructures.
2. Development platform interoperability: It should be possible to create and to manipulate system models using modeling tools of different ven-dors. The same should hold for the generators, which implement the transformation rules mapping models to (refined) models as well as to code.
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 defining modeling 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 a system. Furthermore, UML is extensible and thus can be the foundation of domain 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 the current status of model transformations within the standardization process of 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 version 1.4 of UML.
The language specification differentiates between an abstract syntax and a notation (also called concrete syntax). The abstract syntax defines the language primitives used to build models and is independent of a notation, whereas the notation defines the graphical presentation of these primitives as icons, strings, or geometric figures. UML supports the description of structural and behavioral aspects of a software system by different model element types and corresponding diagram types. In this section, we give an overview of the UML model elements used through the thesis.
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 boundaries
of a system and to specify its functional requirements. An use case diagram consist of actors, use cases, and relations between these model elements. An actor represents a class of system users or agents, whereas a use case formalizes a part of the functionality of the system. Figure 2.1 shows an use 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, we have 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 cases symbolizes the participation of the actor in the particular use case.
There are further relationships, which are not shown in the figure. An arrow between two actors depicts a generalization relationship between them and use cases can be in include orextend 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 by attributes, and relationships are represented by associations. Every class par-ticipating in an association is connected to the association by an association end, which may also specify the role name of the class and its cardinality in the association. The behavior of a class can be characterized by other UML elements such as a state machine that is attached to the class.
Classes are depicted in class diagrams as illustrated by Figure 2.2, which shows the structure of our scheduling application. The model consist of three classes: Meeting, Person, and Room. A Meeting has attributes for storing
thestartdate and the planned duration. The participants, the owner, and
the location of the meeting are specified using the association ends
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 is used to cancel the meeting, which includes notifying the participants.
State Charts State machines describe the behavior of a system or a class
in terms of the states of the system or class and the events that cause a transition between states. A state machine is graphically represented by a statechart diagram. The rectangles and circles represent states and the arrows represent transitions. Transitions may be labeled with the name of the triggering event and (separated by a slash) the name of the action that is 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 and can 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 selected meeting is edited. An event of type create causes a transition to the state
CreateMeeting, where a new meeting is created from data entered by the
user. An event of type delete in state ListMeetings triggers a transition that executes the actiondeleteMeeting, where the currently selected meet-ing is deleted from the database. Similarly, an event of type cancel causes the 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 how the functional requirements given by use cases are realized by a system de-sign. The sequence diagram in Figure 2.4 shows how the cancellation of a meeting in our scheduling application is handled internally by a meeting
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 or other message on top of the line.
Object Constraint Language UML also provides a specification
lan-guage called the Object Constraint Lanlan-guage (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 Meeting
in Figure 2.2 the following OCL constraint:
contextMeetinginv:
self . participants−>includes(self.owner)
The constraint defines an invariant of the class Meeting stating that the owner of a meeting must be contained in the set of participants. Each OCL expression is evaluated in the context of an instance of a specific type and the 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-notaassocia-tion”. In our example expression, participants and owner denote the respective association ends of the meeting.
OCL has some built-in primitive and collection types, e.g. Boolean orSet, whose operations can be accessed using the “arrow” operator. For example, the OCL typeSethas the operationincludesof typeBooleanthat tests whether the expression passed as parameter holds on at least one element of the set. Thusincludes is the OCL form of an existential quantified expression. In our
example expression, we check whether the set of persons referenced by the association endparticipants contains the owner of the meeting object.
Extensibility UML can also serve as a foundation for building domain
specific languages. Stereotypes are used to introduce new language primitives by subtyping core UML types. Model elements are assigned to such types by labeling them with the corresponding stereotype. Tagged values, which are pairs of tags and values, represent new properties of model elements. Additional restrictions on the syntax of the domain specific language can be defined using OCL constraints. Such constraints are designated as well-formedness rules.
A coherent set of stereotypes, tagged value definitions, and well-formedness rules constitutes aUML profile.
2.2.2
The Meta Object Facility
The Meta Object Facility (MOF) [31] is a facility for managing all kinds of metadata about software systems. The term metadata refers to data that describe other data. In the context of MDA the MOF is primarily used to define modeling languages and to built repository infrastructures from such definitions. The most prominent modeling language that has been formalized using the MOF is the UML.
We will use the MOF for the same purpose; to define our security modeling language SecureUML and the example system design modeling languages as well as for integrating SecureUML into these example languages. Our work is based on version 1.4 of the MOF [31].
The MOF uses models for specifying metadata; these models are called metamodels. The modeling framework of MOF is essentially a subset of the UML. So metamodels are expressed using familiar object-oriented concepts, like class and inheritance. The elements that constitute a metamodel are called metaobjects.
The term metamodel describes a relation between models, i.e. a modelm2
can be the metamodel of another modelm1. This means that each metaobject
in m2 is a description of a type of objects in m1 and each object in m1 is
an instance of a metaobject in m2. In that way, metamodels specify the
vocabulary that can be used to define other models. Note that the termmeta is 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 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.
Meta level Description Example elements
M3 MOF model MOF Class, MOF Attribute
M2 Metamodel, defines a
language
Entity, 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 purpose of each level and lists example elements.
The objects in the levels M0-M2 are instances of the objects one level above. So the model in the higher level is the metamodel of the other model and thus stipulates the vocabulary used to formalize this model. The MOF model 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 metamodeling
language that is used to define the syntax of modeling languages at the M2 level. The main concepts of the language are class, association, inheritance, and package. We will explain the language elements that are needed in our thesis in the following paragraphs.
AMOF Classdefines a metaobject at the M2 level, i.e. there are instances of this class at the M1 level with a state and a behavior. In the context of modeling language definition this means that a MOF class specifies a class of model elements that can be instantiated in a system model.
The Figure 2.5 is specified using the UML profile for MOF as defined in [33]. It depicts the definition of the syntax of an example system modeling language at the M2 level. The example illustrates how the two MOF classes
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 example language in a UML-based notation. There we see the two entities Meeting
and Person, denoted by UML classes with the stereotype «Entity». These
entities are instances of the MOF class Entity. Every attribute owned by such a class is automatically considered as a attribute of the entity (MOF class Attribute), so no further stereotypes are necessary.
A MOF Association formalizes a relation between two MOF classes. In our example in Figure 2.5, the classesEntity and Attribute are related by the association EntityAttributes. As a result, the instances of Entity in the system model at the M1 level may have zero or more attributes as shown in Figure 2.6.
A MOF Attribute defines a named value holder in each instance of its MOF class. In our example in Figure 2.5, the attribute name of the MOF classEntity specifies that each entity can have a name. This corresponds to the names “Meeting” and “Person” of the entities in Figure 2.6.
EachMOF Operation specifies a service of its MOF class. These services can be performed on each instance of the MOF class at the model level M1. In our example, there is an operationgetAttributeByNamethat retrieves the attribute of its entity with the given name. MOF operations typically are utility 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 to specify an inheritance relation between MOF classes. If two MOF classes are in a generalization relation then the sub-class derives all attributes, associa-tion ends, and operaassocia-tions applicable to its super-class.
The MOF Package is the MOF Model construct for grouping elements in a metamodel and it also provides a namespace for naming metamodel elements. The Figure 2.5 shows the packageExampleLanguage, which is the container for the metamodel classesEntity 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 need
will use the import relation (not shown in the example figure) that has the following meaning. If a packagep1imports a packagep2, then the metaobjects
inp1 may refer to the metaobjects inp2, e.g. as a super-class or an attribute
type.
MOF Mappings The MOF also defines mappings from MOF-based
meta-models to technologies for metadata management, namely XML and CORBA IDL.
The mapping to XML is designated asXML Metadata Interchange(XMI) and stipulates how models of a particular modeling language are stored in XML documents. Transformation rules specify how MOF-based metamodels are 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 interchanging UML models among different UML-based CASE-tools.
The mapping from MOF-metamodels to CORBA-IDL-Interfaces defines the interfaces of a MOF-repository for storing models of the particular lan-guage. An alternative mapping that is promoted by the Java Community Process is the Java Metadata Interface (JMI) [23]. It defines a mapping from MOF-based metamodels to Java-Interfaces for MOF-repositories. Be-cause it leverages the capabilities of Java, like reflection, and is seamlessly integrated into the programming environment, it is far more convenient then the CORBA IDL mapping and thus is enjoying increasing popularity in the industry.
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 modeldefin-ing languages with various relations between the model primitives. Moreover, there is tool support for automatically creating repositories and maintaining 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 is to have modeling languages, which perfectly suit the needs of a particular problem class or domain. There are several approaches for defining modeling languages.
Lightweight UML extensions First, it is possible to extend UML through profiles. This is supported by most UML-based CASE-tools and by far the easiest 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 and ambiguous for more comprehensive languages. Additionally, the type system for tags is weak because tagged values are always of type string.
Heavyweight UML extensions As an alternative, MOF can be used
to directly extend the UML metamodel. Metamodels are better suited to precisely define the syntax of a modeling language. A problem may arise due to the fact that heavyweight extensions would at best require one to extend the CASE-tool itself, the repository and the visualization components.
Since this is not an option in most cases, an alternative is to encode the new language primitives as a UML profile and to build a layer on top of the CASE-tool, which offers the interfaces defined by the metamodel of the heavyweight extension. A general drawback of heavyweight UML exten-sions is that the custom language metamodel is based on the whole UML metamodel, which is quite complex.
New Modeling Language As a consequence of the disadvantages of the
approaches explained above, a common practice is to define a modeling lan-guage using MOF that focuses on a particular problem or domain without any dependency on UML. The resulting language definitions usually have an intuitive domain-specific vocabulary that is much more concise than the vo-cabulary of UML-based languages. Moreover, the interfaces for querying and manipulating the metadata are simpler than a heavyweight UML interface.
There are different options to define an adequate notation for the new modeling 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 of notation 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 a better 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).
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 an overview on the current status of the standardization.
The primary goal of QVT is that specifications of model transformations shall 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 level of the metamodels involved, which is the M2 level. Note that this will require to 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 in a OMG standard language, e.g. UML or MOF. Based on this specification, it shall be possible to automatically create a model of the target language from a source model.
As mentioned before, the philosophy of MDA is that all artifacts required to build a software system are models (in the sense of specifications). Thus even programming language source code is considered as a special kind of model, where the textual form is just one possible kind of model represen-tation. For example, a metamodel can be given for the Java programming language 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 hybrid languages. Because there is currently no approved standard language, we use our 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 Users and a set of Permissions:
AC ⊆Users×Permissions.
A useru is granted the permission p if and only if (u, p) ∈AC. Aside from the technical question of how to integrate this relation into systems so that
the granting of permissions respects this relation, a major challenge concerns how to effectively represent this information since just enumerating all the (u, p) pairs scales poorly. Moreover, this view is rather “flat” and does not support natural abstractions like sets of permissions.
Role-based access control (see [38]), or RBAC, addresses both of the above limitations. The core idea of RBAC is to introduce a set of roles and to decompose the relation AC into two relations: user-assignment UA and 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 larger roles inherit permissions from all smaller roles. Formally, this means that the 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 in his original roles, but also in all smaller roles. Alternatively, one can give roles additional permissions, i.e., a role not only has its assigned permissions, but also all permissions of smaller roles. The introduction of a hierarchy, like the decomposition of relations, leads to a more expressive formalism in the sense that one can express access control relations more concisely.
Apart from addressing the problem ofscalability mentioned above, RBAC also improves theusability of the access control configuration and its admin-istration in that roles provide a convenient and intuitive abstraction that corresponds 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 generative construction of secure systems. However, RBAC also has limitations. For
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 method parameters. Furthermore, although many technologies support RBAC, they differ in details, like the degree of support for role-hierarchies and the types of protected resources. As we will see in later sections, our approach of generat-ing architectures from models provides a means to overcome such limitations and differences in technologies.
2.4
Security Architectures
We use three different security architectures as examples of target platforms in 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] for the development of server-side components in Java. These components usu-ally form the “business logic” of multi-tier applications and run on application servers. Our work is based on version 2.0 of the EJB specification [40].
The standard specifies an infrastructure for system-level aspects such as transactions, persistence, and security and defines an execution environment for three types of EJB components, which are entity, session, and message driven beans. In this work, we will focus on entity beans. These are persistent and transactional components that are typically used to represent entities of the application domain.
The core of an EJB entity component is thebean class, which contains the business logic of the component. An entity component may have up to four interfaces; these interfaces can be categorized along two dimensions. First, there are home and component interfaces. Home interfaces are e.g. used for creating and finding bean instances whereas component interfaces define the methods applicable to the component instances. Second, such an interface can either be aremote or alocal interface. Remote interfaces can be accessed from outside the application server process, whereas local interfaces are only accessible within the Java virtual machine where the component resides.
EJB employs a declarative programming model. This means that several aspects of an EJB application are declared by properties, which are managed by the application server. This configuration information is stored in deploy-ment descriptors, which are XML documents that are installed together with the components. There are different types of deployment descriptors. First, the EJB standard specifies the schema (cf. [42]) of a standard descriptor file
“ejb-jar.xml” that is mandatory for every EJB application. Additionally, ap-plication server vendors may allow developers to configure product specific features in vendor-specific deployment descriptors. The transformation rules given in this thesis only produce standard descriptor code. Thus we will focus the explanation on this kind of descriptors. The following shows fragments of 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 the components of the EJB application and the sub-elements ofassembly-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 specified by the elementejb-name and the component interfaces (remote home, remote component, local home, and local component) and the bean class are gen-erally identified using elements of type home, remote, local-home, local, and
ejb-class, respectively. Note that an entity component must have at least one pair of either remote or local home and component interfaces. In our example, the entity beanMeetingis composed of the bean classMeetingBean and the local interfacesMeetingHomeandMeetingLocal. The elementpersistence-type
is set to Container meaning that the EJB container is responsible for storing the 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.
con-figured in the deployment descriptors of an EJB application. The security subsystem of the EJB application server is then responsible for enforcing this policy 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. The following example shows the definition of the two rolesSupervisorandUser.
<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. The following example shows the definition of a permission that authorizes the
role 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 individual methods. Amethod-permission element lists one or more roles using elements of typerole-nameand one or more EJB methods using elements of typemethod. The listed roles are granted the right to execute the listed methods.
In general, for realistic applications the information needed to specify a comprehensive access control policy is quite voluminous and there is the danger that developers introduce errors due to oversights or shortcuts taken. For example, suppose a high-level security policy states that a role is granted the 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 one
method-permission element containing one method element for each of these read 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 would
be too liberal. As we indicate later, modeling security policies at a high ab-straction level and automatically generating the corresponding deployment descriptors provides a promising solution to this problem.
In addition to the declarative mechanisms, programmatic access control offers the possibility of implementing access control decisions within the busi-ness logic of components. This mechanism is based on inserting appropriate Java 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 his name or roles. The following shows an assertion that authorizes the roleUser
to execute the method cancel of the component Meeting only if the caller is 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 as distributed transactions, life-cycle management, and security.
The Enterprise Services support declarative and programmatic access control [8]. Here, programmatic access control allows one to obtain the identity of the caller of a method and to check its role assignments. The declarative mechanism supports the configuration of access control restric-tions at the level of applicarestric-tions, components, interfaces, and methods. To achieve 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 the method cancel().
[SecurityRole("Supervisor")] public void cancel(){...}
2.4.3
Java Servlets
The Java Servlets Standard [20] defines an execution environment for web components implemented in Java. These components are calledservlets and their execution environment is designated as servlet container. A servlet is essentially a Java class that processes HTTP requests and creates HTTP responses. Servlets can be used to dynamically create HTML pages or to
control the processing of requests in web applications. Our work is based on version 2.3 of the Java Servlet specification [41].
One or more servlets form a web application whose properties, similar to the approach in EJB (cf. Section 2.4.1), are declared in a XML deployment descriptor (cf. [43]). The following shows an example of such a deployment descriptor. <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 names the servlet and identifies its Java class. The element of type servlet-mapping
defines a uniform resource locator (URL) that is used to address the servlet in HTTP requests.
Access Control A servlet environment supports declarative and
program-matic access control. The security roles of a web application are specified us-ingsecurity-roleelements in the deployment descriptor. The following example shows the definition of the roleUser.
<security-role>
<role-name>user</role-name> </security-role>
Declarative access control permissions are defined at the level of URLs usingsecurity-constraintelements. The following security constraint authorizes the 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 and the roles of a caller and to implement decisions within a servlet.
Chapter 3
Model Driven Security: an
Overview
Model Driven Security aims to close two gaps: the gap between software and security engineering and the gap between design and implementation of se-cure applications. We use a model-centric and generative approach founded on 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 automatically generate systems with complete security architectures from the models.
This approach yields a new kind of models, which we call security design models and requires correspondingsecurity design modeling languages. Such a modeling language is capable of defining the system’s functionality as well as security requirements for one or more security aspects, like access control or 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 a particular class of applications. And, as we illustrated in Section 2.2, the common approach in MDA is to use custom modeling languages, developed to 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, the development of a security design language is a time-consuming task, which also requires an extensive knowledge of the problem domain as well as the particular security mechanism.
We therefore propose a schema for constructing security design modeling languages in a modular way. The schema, as shown in Figure 3.1, has three parts:
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. asystem design modeling languagefor constructing system models (e.g., components with their business methods, attributes, and associations to other components),
2. asecurity modeling language for expressing security policies (e.g., access control policies), and
3. an integration model which “glues” both languages together. We call such an integration model adialect 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 it with system modeling languages. Thus the nature of a dialect depends on the integration concept of the particular security modeling language.
For example, in the case of SecureUML, elements of the system design modeling language are formalized as being protected resources of SecureUML by 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 build different languages, tailored for expressing different kinds of designs and se-curity policies.
To automate our approach to Model Driven Security, for each schema instance we must define, as depicted in Figure 1.2, transformation functions mapping models (in the security design language) to security infrastructures.
As we will show in this thesis, we do this by extending the transformation functions accompanying the system design modeling language of the partic-ular language schema instance.
The remainder of this chapter is organized as follows. First, we describe the techniques we use for defining modeling languages. Second, we discuss the general concept of security modeling language dialects and give examples. Afterwards, we discuss model transformation in the context of Model Driven Security in more detail. We conclude the chapter by giving an outlook of the particular modeling languages and transformation functions we will present in this thesis.
3.1
Language Definition Techniques
We based our language definition techniques upon the third approach given in 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 as a 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 custom notation. For example, we have defined a matrix-based notation for defining access control permissions. Note that a custom notation is just an alterna-tive view of a security design model. Thus the information specified in this notation 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 from models in abstract syntax (M1 level) to corresponding relational models (sorts and relations). The rules are specified in terms of theMOF model (M3 level) and the MOF metadata architecture as follows.
• A modelm(M1 level) given in the language lis translated to a n-tuple ml := (c1, . . . , cn),
where each component ofml is a sort or relation created from the MOF
classes, associations or attributes in the metamodel of l (M2 level). • A MOF Class in the language definition (M2 level) is mapped to a sort
As an example, we consider the example language and model given in Section 2.2.2. The metamodel in Figure 2.5 defines the MOF classes
Entity and Attribute. The corresponding model in Figure 2.6 given in this language is translated to
Entity :={Meeting,Person},
Attribute :={start,duration,name,eMail}.
• Each MOF association is translated to a relation with one entry for each link in the association. As a convention, the name of the relation is 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 in this association, which results in the following definition of the corre-sponding relationEA⊆Entity ×Attribute
EA:={(Meeting,start),(Meeting,duration), (Person,name),(Person,eMail)}.
Optionally, a function may be defined for each association end. The name of the function is built from association end’s name prefixed by the class name. In our example, the function
entityAttributes :Entity 7→2Attribute would correspond to the association endattributes of Entity.
• As explained in Section 2.2.2, a MOF Attribute defines a named value holder in each instance of its MOF class. Thus each MOF attribute is mapped to a relation with one entry for each class instance. The name of the relation is built from the first letters of both the name of the class and the name of the attribute, transformed to upper cases. As an example, the relation EN ⊆Entity ×String corresponds to the attribute nameof the MOF class Entity and is
EN :={(Meeting,‘Meeting’),(Person,‘Person’)}.
Optionally, a function may by defined for each attribute in a way similar to the mapping rule for association ends. In our example, we would create the function
• The inheritance relation between two MOF Classes is mapped to a subset 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 following purposes: They can be the foundation for giving modeling languages a formal semantics 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 to protected resources. Second, it guides our translations and provides a basis with which we can prove their correctness.
The techniques used to give a modeling language a formal semantics strongly depend on the nature of the modeling language itself as well as on the purpose of the semantics. Basically, the relational model as intro-duced above can be used for giving models a semantics but our schema is open to other techniques as well.
We will outline the approach on the example of the modeling language SecureUML that we will introduce in Section 4. SecureUML extends RBAC in a way that access control decisions depend on the system state. Therefore, giving a semantics for access control requires us to consider particular system states (MOF M0 level).
The semantics is therefore given in two steps. Without authorization con-straints, the semantics of access control is g
