A model driven engineering approach to build secure information systems

HAL Id: tel-01514651

https://tel.archives-ouvertes.fr/tel-01514651

Submitted on 26 Apr 2017

HAL is a multi-disciplinary open access archive for the deposit and dissemination of sci-entific research documents, whether they are pub-lished or not. The documents may come from teaching and research institutions in France or abroad, or from public or private research centers.

L’archive ouverte pluridisciplinaire HAL, est destinée au dépôt et à la diffusion de documents scientifiques de niveau recherche, publiés ou non, émanant des établissements d’enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

A model driven engineering approach to build secure

information systems

Thi Mai Nguyen

To cite this version:

Thi Mai Nguyen. A model driven engineering approach to build secure information systems. Modeling and Simulation. Université Paris-Saclay, 2017. English. �NNT : 2017SACLL001�. �tel-01514651�

DOCTORAT EN CO-ACCREDITATION

TELECOM SUDPARIS ET L’UNIVERSITE PARIS-SACLAY Spécialité: Informatique

Ecole doctorale: Sciences et Ingénierie Présenté par

Mme Thi-Mai Nguyen

Pour obtenir le grade de

DOCTEUR DE TELECOM SUDPARIS

A MODEL DRIVEN ENGINEERING

APPROACH

TO
BUILD
SECURE
INFORMATION

SYSTEMS

Soutenue le 13/01/2017 devant le jury composé de :

Directeurs de thèse :

Mme. Amel Mammar Maître de conférences, HDR, TELECOM SudParis, France Mme. Régine Laleau Professeur, Université Paris-Est Créteil, France

Rapporteurs :

M. Yves Roudier Professeur, Université Nice Sophia Antipolis, France M. Christian Attiogbé Professeur, Université de Nantes, France

Examinateurs :

M. Pascal Poizat Professeur, Université Paris Ouest Nanterre La Défense, France M. Akram Idani Maître de conférences, Université Grenoble Alpes , France M. Paul Gibson Maître de conférences, HDR, TELECOM SudParis, France

3

Acknowledgment

G

I would like to express my deepest appreciation and gratitude to my supervi-sors Dr. Amel Mammar and Professor Régine Laleau for their regular feedback, encouragement, and excellent advices throughout this research. Without their mentorship, I would have not been able to finish this dissertation.

I am also thankful to Dr. Akram Idani for his scientific advices and support. It has been a real pleasure to work with him.

I would like to thank all members of the jury. I thank Professor Christian Attiogbé and Dr. Ludovic Apvrille for accepting being my thesis reviewers and for their attention and thoughtful comments. I also thank Professor Pascal Poizat, Dr. Akram Idani and Dr. Paul Gibson for accepting being my thesis examiners.

I wish to thank all the members of the computer science department of Tele-com SudParis, whose friendly Tele-company during my thesis was a great pleasure. I would like to thank Brigitte Houassine for her kind help and assistance. A spe-cial thank to my colleagues Karn, Nabila, and Monika for their moral support and the lovely moments we spent. I would like to express my deepest gratitude to Nathan for all his encouragement and support when I needed the most.

Next, I owe my deepest gratitude to my friends especially Son, Huy, Long, Hoa for their support. I would like to express my warmest affection to Minh for always being by my side, helping me unconditionally and for all the beautiful moments we shared in France.

I am forever thankful to my family: my father, my mother, my sister and my brothers who were always there for me with encouraging words. Your en-couragement made me go forward and made me want to succeed. I would like to express my heartiest gratitude to my boyfriend, Luong. His love, encour-agement, understanding and support helped me to get through all the difficult times. This is because of him that I can reach the goal. Thank you so much for having faith in me even when I doubted myself! I love you so much. I dedicate this thesis to all of you, my wonderful family.

Abstract

Nowadays, organizations rely more and more on information systems to collect, manipulate, and exchange their relevant and sensitive data. In these systems, security plays a vital role. Indeed, any security breach may cause serious con-sequences, even destroy an organization’s reputation. Hence, sufficient precau-tions should be taken into account. Moreover, it is well recognized that the earlier an error is discovered, the easier and cheaper it is debugged. The ob-jective of this thesis is to specify security policies since the early development phases and ensure their correct deployment on a given technological infrastruc-ture.

Our approach starts by specifying a set of security requirements, i.e. static and dynamic rules, along with the functional aspect of a system based on the Unified Modeling Language (UML). Fundamentally, the functional aspect is ex-pressed using a UML class diagram, the static security requirements are modeled using SecureUML diagrams, and the dynamic rules are represented using secure activity diagrams.

We then define translation rules to obtain B specifications from these graphi-cal models. The translation aims at giving a precise semantics to these diagrams, thus proving the correctness of these models and verifying security policies with respect to the related functional model using the AtelierB prover and the ProB animator. The obtained B specification is successively refined to a database-like implementation based on the AOP paradigm. The B refinements are also proved to make sure that the implementation is correct with respect to the initial ab-stract specification. Our translated AspectJ-based program allows separating the security enforcement code from the rest of the application. This approach avoids scattering and tangling the application’s code, thus it is easier to track and maintain.

Finally, we develop a tool that automates the generation of the B specifica-tion from UML-based models and the derivaspecifica-tion of an AspectJ implementaspecifica-tion from the refined B specification. The tool helps disburden developers of the difficult and error-prone tasks and improve the productivity of the development process.

Résumé

Aujourd’hui, les organisations s’appuient de plus en plus sur les systèmes d’-information pour collecter, manipuler et échanger leurs données. Dans ces sys-tèmes, la sécurité joue un rôle essentiel. En effet, toute atteinte à la sécurité peut entraîner de graves conséquences, voire détruire la réputation d’une or-ganisation. Par conséquent, des précautions suffisantes doivent être prises en compte. De plus, il est bien connu que plus tôt un problème est détecté, moins cher et plus facile il sera à corriger. L’objectif de cette thèse est de spécifier les politiques de sécurité depuis les premières phases de développement et d’assurer leur déploiement correct sur une infrastructure technologique donnée.

Notre approche commence par spécifier un ensemble d’exigences de sécurité, i.e. des règles statiques et dynamiques, accompagnées de l’aspect fonctionnel d’un système basé sur UML (Unified Modeling Language). L’aspect fonction-nel est exprimé par un diagramme de classes UML, les exigences de sécurité statiques sont modélisées à l’aide de diagrammes de SecureUML, et les règles dynamiques sont représentées en utilisant des diagrammes d’activités sécurisées. Ensuite, nous définissons des règles de traduction pour obtenir des spéci-fications B à partir de ces modèles graphiques. La traduction vise à donner une sémantique précise à ces schémas permettant ainsi de prouver l’exactitude de ces modèles et de vérifier les politiques de sécurité par rapport au modèle fonctionnel correspondant en utilisant les outils AtelierB prover et ProB anima-tor. La spécification B obtenue est affinée successivement à une implémentation de type base de données, qui est basée sur le paradigme AOP. Les affinements B sont également prouvés pour s’assurer que l’implémentation est correcte par rapport à la spécification abstraite initiale. Le programme d’AspectJ traduit permet la séparation du code lié à la sécurité sécurité du reste de l’application. Cette approche permet d’éviter la diffusion du code de l’application, et facilite ainsi le traçage et le maintien.

Enfin, nous développons un outil qui génère automatiquement la spécifi-cation B à partir des modèles UML, et la dérivation d’une implémentation d’AspectJ à partir de la spécification B affinée. L’outil aide à décharger les développeurs des tâches difficiles et à améliorer la productivité du processus de développement.

List of Publications

1. Thi Mai Nguyen, Amel Mammar, Regine Laleau and Samir Hameg, A tool for the generation of a secure access control filter, IEEE 10th International Conference on Research Challenges in Information Science, RCIS 2016, Grenoble, France, June 01-03, 2016.

2. Amel Mammar, Thi Mai Nguyen and Regine Laleau, Formal develop-ment of a secure access control filter, IEEE 17th _{International Symposium}

on High Assurance Systems Engineering, HASE 2016, Orlando, Florida, USA, January 07-09, 2016.

Table of contents

1 Introduction 23 1.1 Research Motivations . . . 24 1.2 Research Contributions . . . 26 1.3 Thesis Structure . . . 27 2 Background 29 2.1 Introduction . . . 30 2.2 The B Method . . . 30 2.2.1 Abstract machine . . . 30 2.2.2 Refinement . . . 34 2.2.3 Discussion . . . 36 2.3 Model-Driven Engineering . . . 37 2.3.1 An overview . . . 37 2.3.2 Model-Driven Architecture . . . 37

2.4 Role Based Access Control . . . 38

2.4.1 Core RBAC . . . 39

2.4.2 RBAC Constraints . . . 40

2.4.3 SecureUML . . . 41

2.5 RBAC in Database Management Systems . . . 41

2.5.1 Database User . . . 42

2.5.2 User-defined Database Role . . . 42

2.5.3 User-Role assignment . . . 42

2.5.4 Permission assignment . . . 43

2.6 Aspect Oriented Programming . . . 44

2.6.1 An overview . . . 44

2.6.2 AspectJ . . . 46

2.7 Conclusion . . . 48

3 State of The Art 49 3.1 Introduction . . . 50

3.2 Techniques for Security Specification . . . 50

3.2.1 UML and OCL based approaches . . . 50

3.2.2 Alloy-based Approaches . . . 58

3.2.3 Z-based Approaches . . . 63

3.2.4 A B-based Approach . . . 68

3.2.5 Discussion . . . 72

3.3 Support Tools for Access Control Policies . . . 74 13

14 Table of contents

3.3.1 SecureMOVA . . . 74

3.3.2 B4MSecure . . . 77

3.3.3 Discussion . . . 79

3.4 Implementation of An Access Control Specification . . . 80

3.5 Enforcement of Access Control Policies . . . 82

3.5.1 Java Authentication and Authorization Service . . . 83

3.5.2 Annotation-based approaches . . . 83

3.5.3 AOP-based approaches . . . 84

3.5.4 Discussion . . . 86

3.6 Conclusion . . . 88

4 Formal Development of a Secure Access Control Filter 89 4.1 Introduction . . . 90

4.2 The case study: a bank system . . . 92

4.3 Graphical modeling of security requirements . . . 93

4.3.1 SecureUML . . . 93

4.3.2 Activity diagrams for dynamic security rules . . . 94

4.4 Generation of a B specification . . . 96

4.4.1 Overview of the B method . . . 97

4.4.2 Translation of the functional model: the class diagram . 97 4.4.3 Formalizing SecureUML in B . . . 99

4.4.4 Translation of the secure UML activity diagrams into B . 101 4.4.5 Putting all the security and functional constraints together105 4.5 Verification and validation . . . 107

4.6 Conclusion . . . 109

5 A Tool for the Generation of a Secure Access Control Filter 111 5.1 Introduction . . . 112

5.2 Overview of the tool . . . 113

5.3 Overview of the B method . . . 115

5.4 Graphical modeling of the application: case study . . . 115

5.5 From graphical diagrams to B formal notations . . . 121

5.5.1 Translation of the class diagram . . . 121

5.5.2 _{Translation of the SecureUML diagram . . . 123}

5.5.3 Translation of the secure UML activity diagram . . . 124

5.6 The B specification of a secure filter . . . 126

Table of contents 15

6 A Formal Approach to Derive an AOP-Based Implementation

of a Secure Access Control Filter 131

6.1 Introduction . . . 132

6.2 The case study: a purchase order system . . . 134

6.3 A formal B specification of a secure filter . . . 136

6.3.1 Translation of the class diagram into a B specification . . 136

6.3.2 Translation of the SecureUML diagram into a B specification137 6.3.3 Translation of the secure UML activity diagrams into a B specification . . . 139

6.3.4 Designing the secure filter . . . 140

6.4 From an abstract B specification to a relational-like B implemen-tation . . . 141

6.4.1 Data refinement . . . 141

6.4.2 Behavioral refinement . . . 143

6.5 The AspectJ implementation of the application . . . 146

6.5.1 Transformation rules of B into JAVA/SQL . . . 148

6.5.2 Deployment of the class diagram . . . 151

6.5.2.1 Definition of the tables and the associated JAVA methods and stored procedures . . . 153

6.5.2.2 Translation of the operations of the class diagram154 6.5.3 Deployment of the SecureUML diagram . . . 155

6.5.4 Deployment of the secure activity diagrams . . . 158

6.5.4.1 Definition of the log tables and the associated JAVA classes . . . 158

6.5.4.2 Translation of the secure operations of the secure activity diagrams . . . 160

6.5.4.3 Translation of the log operations . . . 161

6.5.5 Deployment of the filter . . . 161

6.6 Tool support . . . 163

6.6.1 Translating the B specification of the class diagram . . . 163

6.6.2 Translating the B specification of the SecureUML diagram 164 6.6.3 Translating the B specification of the secure activity dia-gram . . . 166

6.6.4 Translation of the access control filter . . . 167

6.7 Conclusion . . . 168

7 Conclusions and Future Work 171 7.1 Contributions . . . 172

List of Tables

2.1 The visibility of the SEES clause . . . 33 2.2 The visibility of the INCLUDES clause . . . 34 2.3 The visibility of the IMPORTS clause . . . 36 3.1 Synthesis of formal-based approaches for security specifications . 75 4.1 Results of the proof phase . . . 109 6.1 Type mappings table among B, JAVA, and SQL Server . . . 149 6.2 Transformation of B expressions to SQL Server . . . 150

List of Figures

2.1 Software development process in B . . . 31

2.2 B machine . . . 32

2.3 Core RBAC [1] . . . 40

2.4 SecureUML metamodel [2] . . . 41

2.5 Normal compilation process (left) and AOP compilation process (right) . . . 45

3.1 A static model [3] . . . 51

3.2 A functional model [3] . . . 52

3.3 Collaboration Diagram: Permission Approval [3] . . . 52

3.4 Conceptual class model for RBAC [4] . . . 53

3.5 A RBAC class diagram template [5, 6] . . . 55

3.6 A RBAC class diagram for a banking system [6] . . . 56

3.7 Violation of SSD Constraint [5, 6] . . . 56

3.8 Object Diagram for SSD Policies [6] . . . 56

3.9 Use case: TeamWorker [7] . . . 57

3.10 Model Driven Security [8] . . . 58

3.11 Assurance Management Framework [9] . . . 62

3.12 The transformation method [10] . . . 63

3.13 An access control filter [11] . . . 69

3.14 A dynamic access control rule in ASTD [11] . . . 70

3.15 A secure operation . . . 72

3.16 A dynamic operation [12] . . . 73

3.17 An access control filter [12] . . . 73

3.18 Validation/Verification activities supported by B4MSecure [13] . 77 3.19 The architecture of B4MSecure . . . 78

3.20 UML to B translation . . . 78

3.21 SecureUML to B translation . . . 79

3.22 A secure operation . . . 79

3.23 The AAC metamodel [14] . . . 82

3.24 Aspect code for object-based access control [15] . . . 85

3.25 An example of the JSAL implementation in AspectJ [16] . . . . 87

3.26 JSAL architecture [16] . . . 88

4.1 The class diagram of a simplified banking system . . . 92

4.2 Generic SecureUML model . . . 94

4.3 Static access control model . . . 94 19

20 List of Figures

4.4 A generic form of a secure activity diagrams . . . 95

4.5 Example of dynamic security rules modeled by activity diagrams: Rule 3 . . . 96

4.6 Example of dynamic security rules modeled by activity diagrams: Rule 4 . . . 96

4.7 Machine Context . . . 98

4.8 The static part of the functional B specification . . . 98

4.9 The functional specification of Operation validateDeposit . . . . 99

4.10 The B context machine of the SecureUML diagram of Figure 4.3 101 4.11 The B machine managing the roles of users . . . 101

4.12 B translation of a SecureUML permission (Figure 4.2) . . . 102

4.13 B translation of a SecureUML operation (Figure 4.3) . . . 102

4.14 Machine ActionsHistory . . . 103

4.15 Translation of a secure operation of an activity diagram . . . 104

4.16 Translation of the activity diagram of Figure 4.5 . . . 104

4.17 Translation of the activity diagram of Figure 4.6 . . . 105

4.18 The abstract specification of Machine Secure Filter . . . 106

4.19 The concrete specification of Machine Secure Filter . . . 107

4.20 The architecture of the B specification . . . 108

5.1 Translation workflow . . . 114

5.2 _{Editing a class diagram under the B4MSecure platform . . . . 116}

5.3 The SecureUML metamodel (adapted from [17]) . . . 117

5.4 _{Editing a SecureUML diagram under the B4MSecure platform 118} 5.5 The secure UML activity metamodel . . . 119

5.6 Example of dynamic security rules modeled by activity diagrams: Rule 2 . . . 120

5.7 Example of dynamic security rules modeled by activity diagrams: Rule 4 . . . 120

5.8 Translation of the class diagram . . . 122

5.9 Generation of the B operation makePayment of the class Hospi-talStay . . . 122

5.10 The B context machine of the SecureUML diagram of Figure 5.4 124 5.11 The B modeling of the static secure operation corresponding to the operation makePayment of Figure 5.4 . . . 125

5.12 The B specification of the history execution of the operation makePayment . . . 125

5.13 The B translation of the activity diagram of Figure 5.6 . . . 126 5.14 The B specification of the filter for the operation makePayment 127

List of Figures 21

5.15 The concrete specification of the filter of the operation makePayment 128 6.1 The class diagram of a simplified purchase order . . . 135 6.2 A secure activity diagram modeling a dynamic security rule . . 136 6.3 The B specification of the class diagram . . . 137 6.4 The B translation of the SecureUML diagram . . . 138 6.5 The B translation of the activity diagram in Figure 6.2 . . . 139 6.6 The B specification of the filter of the operation Receive . . . . 140 6.7 The B specification of a relational table . . . 142 6.8 The B evaluation of a predicate . . . 142 6.9 The B specification of a log table . . . 144 6.10 The B implementation of the operation receive . . . 145 6.11 The B implementation of a log operation LogReceive . . . 145 6.12 The B implementation of the operation ADReceive . . . 146 6.13 Derivation of the AspectJ implementation . . . 147 6.14 AspectJ implementation principle . . . 148 6.15 Transformation of a B operation to a stored procedure . . . 149 6.16 Transformation of B operation to JAVA method . . . 151 6.17 Transformation of B expressions into JAVA . . . 152 6.18 Generation of a table . . . 163 6.19 Generation of a stored procedure NotReceive . . . 163 6.20 Generation of the associated JAVA method NotReceive . . . 164 6.21 Generation of the stored procedure receive . . . 164 6.22 Generation of the associated JAVA method receive . . . 165 6.23 Generation of the security data . . . 165 6.24 Generation of the class SecureUMLJAVATrans . . . 166 6.25 Generation of a log class . . . 167 6.26 Generation of a log table . . . 167 6.27 Generation of the log method . . . 167 6.28 Generation of the method ADOp . . . 168 6.29 Generation of the aspect class . . . 168

Chapter 1

Introduction

Contents

1.1 Research Motivations . . . 24 1.2 Research Contributions . . . 26 1.3 Thesis Structure . . . 27

An information systems (IS) is any system for the collection, organization, storage and communication of information. The impact of ISs on our economic and social life is increasing significantly due to the spreading of the ubiquitous computing. In these systems, security plays a vital role and is a central issue in their construction and manipulation. ISs are required to be more secure in order to resist to potential attacks. Due to the importance of security in ISs, it has been receiving a large number of interests.

One of the most common security issues is access control. An access control policy regulates accesses to the protected resources of a system. There are several access control mechanisms available, such as Mandatory Access Control (MAC), Discretionary Access Control (DAC), and Role-Based Access Control (RBAC). In this thesis, we choose RBAC for its advancement over MAC and DAC in term of simplifying the permissions management and improving the organizational productivity. Moreover, a large number of products support RBAC directly, and others support close forms of the role concept, such as user groups [18]. For example, the notion of role is considered as a part of the SQL standard in some commercial database management systems, such as Oracle [19] and SQL Server [20].

An important and challenging task is to tackle security requirements in the early stages of the development process. That can avoid an ad-hoc integration

24 Introduction

of security mechanisms after the system has been implemented. It is also easier to analyze security policies at the abstract level because security specifications contain less details about specific platforms and underlying technologies in these early stages.

UML is a de facto standard to model requirements of secure systems on top of its textual descriptions. Graphical models provide intuitive and synthetic views of a system that can facilitate the communication among stakeholders, such as developers, designers and users. However, their semantics are often blurred, and therefore their meaning can be ambiguous to the interpretation. This may end up in implementing some undesirable functionalities. OCL is then designed to minimize the ambiguity of UML models [21]. Likewise, formal languages, such as Alloy [22], Z [23], and B [24] can be alternative techniques for precisely representing a system. Combining graphical and formal notations in software development has been an interesting area. As such, it is able to take advantages of both techniques, and they can complement each other: graphical models offer the visualization of a system, but they are not precise enough for the reasoning; due to the precision of mathematical notations and automatic reasoning, formal methods can overcome the ambiguity of these graphical models and provide rigorous specifications of the system.

Security is seen as a crosscutting concern of an application since it impacts on nearly each component of the application. The classical methods often in-tegrate security codes inside the components that they affect. That is a major cause of the code tangling and scattering. Consequently, it is remarkably dif-ficult to maintain the program, especially in large systems. We believe that security policies should be enforced as crosscutting concerns. It means that the security logic is separated from the application program, but it should be able to automatically intercept method invocations. Regarding the separation of concerns, the aspect oriented programming (AOP) stands out to be the best technique. It allows the modularity of crosscutting concerns by introducing ad-ditional behaviors into an existing code without any modification. Indeed, it separately encodes these concerns within aspects, specifies which pieces of code are modified through pointcuts, and injects additional behaviors implemented in advices into the business program without cluttering it.

1.1

Research Motivations

The literature review shows that functional and security models of a secure information system are generally treated separately in the design step. However, security requirements have a large impact on the functional model. Thus, it is

Research Motivations 25

necessary to consider both models at the same time in order to specify the effect of security concerns and to have a complete security analysis. There are a few attempts that specify the security aspect along with the functional model of a secure system. For example, the work of Basin et al. [2] allows to point out which elements of the functional model are protected in the security model. Our work is influenced by this direction.

The use of formal languages, such as Z, B, and Alloy on top of graphical models of secure systems has been investigated in several studies [10, 11, 25]. The combination of formal and graphical techniques can produce specifications which, on one hand, can be understood and then validated by participants (e.g. developers, designers, and users) and, on the other hand, can be formally ver-ified using the different tools available for formal methods. We are interested precisely in the B method as it is a complete formal language, and it has been used in many industrial projects, especially in railway systems (Metro line 14, the Charles de Gaule airport shuttle automated pilot, etc.). Moreover, it has reliable free tools (AtelierB [26], ProB [27]) to support the whole software de-velopment process.

Despite the benefits of combining graphical and formal methods, developers are still reluctant to apply such approaches. The reason is that using formal methods requires a well-prepared knowledge about mathematical basics, which is difficult and challenging for their users. Automating model transformations from security models to formal specifications is an obvious need of developers. It can also improve the quality of the produced system and the productivity of the development process. Several efforts are deployed to automatically trans-late UML models into B specifications [28–30]. Nonetheless, these works focus only on the functional aspect of a secure system. The B4MSecure platform [13] permits to extract various B specifications from functional and static security models, but it does not consider dynamic security requirements. We particu-larly complement this work by supporting the dynamic security aspect of secure information systems.

Once security and functional requirements are specified, the development process consists in implementing them. Our goal is to separate the security and functional codes so that the structure of the final system is clear and easy to maintain. That is why we choose an approach based on AOP. There are many efforts on applying this paradigm to enforce security policies [14–16, 31– 33]. Notwithstanding, these works consider access control constraints in the implementation stage [15, 16, 31, 32] or generate security codes from not-yet-verified models [14, 33]. Our approach covers the whole development life-cycle of secure systems: it starts by graphically modeling the functional and security

26 Introduction

requirements; the graphical models are then translated into formal specifications that are successively validated and verified; the proved specifications are in turn refined until it is possible to straightforwardly map them into an AOP-based program.

1.2

Research Contributions

The dissertation aims at providing a Model Driven Engineering (MDE) ap-proach to build secure information systems. The following describes our contri-butions to the specification, model transformations, and enforcement of security policies involving the functional aspect of such systems:

• Specification of security design models: we propose to graphically express functional and security models by UML-based diagrams: UML class diagrams are used to represent the functional requirements, Se-cureUML models static security rules, and UML activity diagrams de-scribe dynamic security rules related to ordering and history-based con-straints. These visual models are then translated into B specification modules. This translation intends to have rigorous descriptions and to avoid multiple interpretations for the specifications. It also allows to vali-date and verify a security policy at the platform independent level. That means that the security policies are specified and validated before their implementation. Therefore, the security enforcement code can vary in different settings. We also derive an access control filter that integrates different specifications related to a secure operation: i.e. functional, static, and dynamic specifications. As such, the security policies can be verified with respect to the functional specification.

• Enforcement of access control policies: our security enforcement ap-proach allows a separation of concerns. In other words, the security logic and the main functionalities of an application are separated. To do so, we devise translation rules from the B specification to an AOP-based appli-cation. Essentially, the verified B specification is refined until obtaining a relational-like B implementation that is straightforwardly mapped into an AspectJ-based program connected to a Relational Database Management System (RDBMS).

• Automation of the languages transformations (from UML to B and from B to AspectJ/JAVA/SQL): as stated above, the graphical models of a secure application are transformed into the B specifications.

Thesis Structure 27

We have done this transformation automatically by developing a tool. The generated B specifications are correctly checked using AtelierB [26] without any additional modification. Most proofs are automatically dis-charged: the abstract and the refinement specifications of the filter are automatically proved. The verification of these models can also be done by playing scenario using the ProB [27] animator. ProB implements an automatic model-checking technique to verify a B specification. Such a specification is moved through several state changes, starting from a valid initial state into a state that violates its invariant. As such, security flaws that the static check cannot detect can be recognized.

The initial B specification is successively refined into a relational-like im-plementation, which can be mapped into an AspectJ-based application connected to a DBMS. Using our tool, the executable code can be auto-matically generated from the formal implementation. The security code and the main program are produced separately, making the application easier to track and maintain. The JAVA/SQL program is derived from the functional specification, while the access control filter results in the aspect code. The generated SQL statements are correct with respect to the SQL Server syntax.

1.3

Thesis Structure

The thesis is organized in seven chapters:

• Chapter 2: Backgrounds presents a description of the different con-cepts needed for understanding the rest of the manuscript. It includes theoretical details of the B method. It also presents an overview of Model Driven Engineering, role based access control, and aspect oriented pro-gramming. SecureUML and RBAC features supported in database man-agement systems are also covered in this chapter.

• Chapter 3: The State of The Art reviews the existing works related to the development of secure systems. We present techniques for the speci-fication of access control requirements and supporting tools for specifying and validating RBAC models. This chapter also includes a number of approaches that deal with model transformations of RBAC policies to im-plementation codes. The state of the art in the security enforcement based on AOP is also considered in this chapter.

28 Introduction

• Chapter 4: Formal Development of a Secure Access Control Fil-ter describes graphical representations of a secure system using UML-based models and their translation into B. We present the mapping rules from UML class diagrams, SecureUML, and secure activity diagrams into B specifications, through which we can ensure the consistency of these models and validate the system. Finally, a proved filter, which permits to take into account different security rules, is formally derived using the B refinement technique.

• Chapter 5: A Tool for the Generation of a Secure Access Control Filter describes a tool that automates the translation presented in Chap-ter 4. The tool is built based on the Eclipse platform which integrates the TopCased modeling environment.

• Chapter 6: A Formal Approach to Derive an Aspect Oriented Programming-Based Implementation of a Secure Access Control Filter proposes an AOP-based approach for the security enforcement. It describes the translation rules from the presented B specifications into an AspectJ implementation connected to a SQL server. The automation of this transformation is also provided here.

• Chapter 7: Conclusions and Future Works sum up our claimed contributions along with future perspectives.

Chapter 2

Background

Contents

2.1 Introduction . . . 30 2.2 The B Method . . . 30 2.2.1 Abstract machine . . . 30 2.2.2 Refinement . . . 34 2.2.3 Discussion . . . 36 2.3 Model-Driven Engineering . . . 37 2.3.1 An overview . . . 37 2.3.2 Model-Driven Architecture . . . 37 2.4 Role Based Access Control . . . 38 2.4.1 Core RBAC . . . 39 2.4.2 RBAC Constraints . . . 40 2.4.3 SecureUML . . . 41 2.5 RBAC in Database Management Systems . . . 41 2.5.1 Database User . . . 42 2.5.2 User-defined Database Role . . . 42 2.5.3 User-Role assignment . . . 42 2.5.4 Permission assignment . . . 43 2.6 Aspect Oriented Programming . . . 44 2.6.1 An overview . . . 44 2.6.2 AspectJ . . . 46 2.7 Conclusion . . . 48

30 Background

2.1

Introduction

This chapter presents the basic knowledge and concepts to help the readers understand the different contributions described in the rest of the manuscript. We will start by the B method in Section 2.2. Afterwards, we will give an overview of Model Driven Engineering in Section 2.3. Role-based access control and its features supported in relational database management systems will be introduced in Sections 2.4 and 2.5 respectively. Finally, we will present aspect-oriented programming in Section 2.6.

2.2

The B Method

The B method is a formal language introduced by J-R Abrial. Based on first-order logic, it provides a means for “the central aspects of the software life cycle, namely: the abstract specification, the design by successive refinement steps, the layered architecture, and the executable code generation” [24]. In other words, the B method covers most of the life-cycle stages of the software development process: from the design phase to the implementation phase. That allows the early error detection of systems. It is commonly known that the earlier an error is detected, the easier and cheaper it is to fix

B formal representations express different levels of abstraction of a system, from an abstract specification to an executable code (Figure 2.1). The abstract specification describes the fundamental properties of the product. Conceptual details are added incrementally through the refinement process. The last result of the refinement step, called the implementation, should be close to the target programming language. As such, we may generate an executable code.

The benefit of using B is the availability of supporting tools. For instance, AtelierB [26] developed by ClearSy is an industrial tool for analyzing, checking types, and generating proof obligations of a B component. AtelierB provides an automatic prover with a predefined rule base and an interactive prover permit-ting users to define their own rules. Another tool, called ProB [27], allows the automatic animation of a B specification.

2.2.1

Abstract machine

An abstract machine is a fundamental concept in B. It is seen as a “pocket calculator” [24], which includes an invisible memory and a number of keys. The memory stores the state of the machine, while the keys are operations used for any modification of the state.

The B Method 31

Figure 2.1: Software development process in B

Each abstract machine is composed of static and dynamic parts (See Figure 2.2):

• The static part declares the state of a system in terms of sets (the SETS clause), constants (the CONSTANTS clause), and variables (the VARIABLES clause). The definition of these declarations is specified by the Predicate Calculus and Set Theory languages. Predicates denoting the properties of the constants are defined in the PROPERTIES clause. The INVARIANT clause permits to type the variables and to define the properties that they must always verify.

• The dynamic part is expressed through the initialisation (the INITIAL-ISATION clause) and the operations (the OPERATIONS clause). The initialisation aims to set initial values for the variables. The operations describe the evolution of a machine by modifying the state of that ma-chine. An operation is specified as a non-executable pseudo-code, and it does not include any sequence or loop. This pseudo-code is formalized

32 Background

Figure 2.2: B machine

in the Generalized Substitution Language. Each substitution used in our work is an assignment statement that specifies variables to be modified. An operation is executed under a precondition (P ) specifying the neces-sary and sufficient conditions that make the invariant satisfied after its execution (after executing S ). An operation may also assume parameters (w ) and return a value (r ). The general form of a B operation can be defined as follows:

r ← O (w ) = PRE P THEN S END;_b

Abstract machine correctness

Definition: “A proof obligation is a mathematical formula to be proven, in order to ensure a B component is correct” [24].

The proof obligations generated for an abstract machine cover:

• the correctness of the initialisation (2.1): the initialisation is correct if and only if the invariant (I ) is true after executing the initialisation (Init ):

The B Method 33 Table 2.1: The visibility of the SEES clause

Objects (of seen machine)

Clauses (of seeing machine)

PROPERTIES INVARIANT OPERATIONS

sets visible visible visible

constants visible visible visible

variables no no read-only

operations no no no

• the correctness of operations (2.2): the proof obligations of an opera-tion verifies that the invariant remains verified after the execuopera-tion of that operation:

I ∧ P ⇒ [S ]I (2.2)

Modularity of an abstract specification

Modularity is an efficient solution to deal with the complexity of a system [34]. The concept of an abstract machine is very close to some well-known concepts, such as class and module in programming languages. This notion supports the modularity in software development, thus it allows us to construct abstract machines in a shared way.

At an abstract level, B introduces four clauses relating to the modularity. These clauses differ on the visibility rules. Here, we only present the clauses that are used in our work.

• The SEES clause addresses a list of machines sharing a part of data with the seeing components. The visibility of the elements of a seen machine within different clauses of the seeing machine is shown in Table 2.1. The rows correspond to the elements of the seen machine and the columns cor-respond to the elements of the seeing machine. The value visible indicates that the considered element of the seen machine is accessible in specific clauses of the seeing machine. The value no means that the considered element of the seen machine cannot be referenced in specific clauses of the seeing machine.

Table. 2.1 shows that the sets and the constants of the seen machine are fully visible within the seeing machine. The variables of the seen machine can not be referenced within the invariant of the seeing machine. Although they are visible in the operations of the seeing machine, they cannot be

34 Background Table 2.2: The visibility of the INCLUDES clause

Objects

(of included machine)

Clauses

(of including machine)

PROPERTIES INVARIANT OPERATIONS

sets visible visible visible

constants visible visible visible

variables no visible read-only

operations no no visible

modified. The operations of the seen machine are fully invisible within the seeing machine.

The SEES clause is non-transitive: if a machine M1 sees a machine M2

which, in turns, sees another machine M3, then M1 has to see M3 again if

M1 requires certain information of M3.

• The INCLUDES clause allows us to include other machines in a given machine. The visibility of the different elements of an included machine is shown in Table. 2.2.

As we can notice, the sets and the constants of an included machine are accessible from anywhere in the including machine. The variables can be only read by the operations of the including machine. The operations of the included machine can be called within the operations of the including machine.

The INCLUDES mechanism is transitive: if a machine M1 includes a

machine M2, then M1 does not need to include again the machines already

included in M2. These included machines of M 2 are implicitly included

in M1.

2.2.2

Refinement

Refinement is a technique that is used to transform an abstract model into a more concrete one. Basically, refinement consists in weakening preconditions and replacing a parallel substitution by a sequence one. The last refinement step, called implementation, aims at obtaining data and substitutions close to those of a programming language such that the translation into the chosen target language of the data and control structures (used in this level) must be a straightforward task. Each refinement primarily concerns the two following notions:

The B Method 35

• VARIABLES: abstract variables may be preserved, deleted, or changed the form within the VARIABLES clause of a refinement. A refinement can also introduce new variables. In this case, the invariants that links the abstract variables and the concrete ones must be specified.

• OPERATIONS: each abstract operation must be refined accordingly in refinements. To do so, we remove non-executable elements of each operation, such as precondition and choice. We can use more concrete and deterministic substitutions or call operations of other abstract machines imported within the implementation.

The refinement of an abstract machine is performed gradually in several steps rather than all at once. Details of the problem are added incrementally through each step. Note that the B refinement cannot change the signature of the operations or introduce new operations. The last level of the refinement is called implementation which should be close to a particular programming language, such as C, Ada, or Java.

Refinement correctness

To prove the correctness of a refinement, we have to establish:

• The correctness of the initialisation (2.3): it proves that the ini-tialisation of a refinement (Initr) establishes its invariant (Ir) without

contradicting the initialisation of the refined component (Init ).

[Initr]¬[Init ]¬Ir (2.3)

• The correctness of the operation (2.4): assuming that Sr is the

sub-stitution of the concrete operation, Ir is the invariant of the refinement.

A refinement operation is correct when it preserves the invariant without contradicting the specified operation. In other words, the effects of the re-finement operation must not be in contradiction with the effects specified in the abstract operation. The aim of the proof obligation will therefore be built around a double negative.

36 Background Table 2.3: The visibility of the IMPORTS clause

Objects

(of imported machine)

Clauses (of implementation)

PROPERTIES INVARIANT OPERATIONS

sets visible visible visible

constants visible visible visible

variables no visible no

operations no no visible

Implementation

Implementation is the last refinement. It cannot be refined further. As al-ready mentioned, the implementation should be easily translated into a given programming language. The implementation data must be concrete and the abstract sets have to be valued. The precondition, parallel, choice, and ANY substitutions are not allowed in the implementation.

Modularity of an implementation

The implementation of a refinement may import some machines to implement its variables and operations (the IMPORTS clause). The imported machines offer their data and operations, which are either refined into an implementation or easily translated into the target language. Table 2.3 describes the visibility of the IMPORTS clause. As we can see, the sets and the constants of the imported machine are fully visible within the implementation. The variables of the imported machine are only accessible within the invariant of the imple-mentation. This aims to express the relationship between the variables of the imported machine and those of the component refined by the implementation. The operations of the implementation are encoded by calling the operations of the imported machines.

2.2.3

Discussion

To summarize, the main advantages of the B method are: • the modularization facilities.

• the code generation

Model-Driven Engineering 37

The B method has been successfully used in industrial projects, especially in the domain of safety critical systems [35]. Among industrial large-scale projects developed in B, the METEOR project [36] is the first one that fully applies the formal process to develop the first automatic train operating system in Paris (line 14). In the establishment of the VAL shuttle for Roissy Charles de Gaulle airport [37], driverless light trains developed by Siemens Transportation Systems, B has been used for construction of the software.

2.3

Model-Driven Engineering

2.3.1

An overview

Model Driven Engineering [38], MDE for short, is a promising paradigm for software development. The goal of MDE is to increase the abstraction level in representing a system and the automation in constructing it. In MDE, mod-els play an important role in software development. The automation in the production of the system can be achieved by model transformations.

Models are considered as central entities in MDE. A model is an abstract representation of a (part of) system. It shows a partial view of the system by simplifying the one that needs to be captured or automated. A model focuses on the relevant information of a (part of) system rather than details from a given viewpoint. Therefore, it often requires multiple models for a better repre-sentation of a system. Promoting the use of models intends to improve quality of the resulting software, because it is easier to understand, simulate, analyze, and validate abstract models than computer programs.

Model transformations allow a source model to be automatically transformed into a target model according to transformation rules. One can define mappings between models in the same or different languages. Transformation tools are essential to maximize the benefits of using models and minimize the effort of constructing the modeled system. Using supporting tools can reduce the bur-den of hand-coded tasks, that are tedious and error-prone. Thus, they can significantly improve the productivity of the software development.

2.3.2

Model-Driven Architecture

Model Driven Architecture (MDA) [39] is known as the best MDE initiative. It is a mission of the Object Management Group (OMG) in “solving integration problems through open, vendor-neutral interoperability specifications” [39]. The objective of MDA is to improve productivity, portability, interoperability, and

38 Background

reusability by using models to describe a system. The core of MDA is multiple OMG’s standards, including: the Unified Modeling Language (UML), Meta Object Facility (MOF), XML Metadata Interchange (XMI), and the Common Warehouse Metamodel (CWM).

The MDA framework includes the following three model types:

• Computation Independent Model (CIM) describes what a system is expected to do, but hides all information on how this system will be implemented.

• Platform Independent Model (PIM) describes the function and the structure of a system without any technical details. It provides a degree of independence to the features of a specific platform. Not surprisingly, all PIMs are expressed in UML.

• Platform Specific Model (PSM) represents the business model with technical concepts of a particular type of platform. Although it is still a UML model, it should be able to simulate how a system operates on the target platform.

Automating model transformations is a major goal of MDA. A transforma-tion can be executed through tools to transform PIM to PIM, PIM to PSM, PSM to PSM, and PSM to code. In some restricted cases, the whole application can be generated: the more completely the PSM specifies the target platform environment, the more completely the code is generated. As a result, we can re-duce the effort of hand programming and the cost of the models maintenance. In the transformation step, MOF is used to define languages and transformations between languages.

During the development, some tools can be used to model, verify, compare, transform, analysis, test, and simulate.

2.4

Role Based Access Control

Role based access control (RBAC) [40] is a de facto standard for controlling access to information systems. It has been standardized by the NIST (National Institute of Standards and Technology) and widely used in industrial projects. The idea is to regulate accesses to the resources of a system basing on the roles of the users. RBAC permits to reduce the complexity and cost of security man-agement within enterprises [41]. Indeed in RBAC, a role is relatively persistent with respect to a job function or title within an organization. Individual users

Role Based Access Control 39

are assigned to roles, which permissions are associated with. As a result, a user gains rights based on his roles.

There are two principal RBAC concepts, namely the core RBAC and con-straints. These concepts are explained in the following subsections.

2.4.1

Core RBAC

Core RBAC is an essential part in any RBAC system. The static aspect of core RBAC addresses five basic data elements: users (Users), roles (Roles), permis-sions (Permispermis-sions), objects (Objects), and operations (Operations) executed on objects.

• Users are people who use the system.

• Roles are permanent job tittles within enterprises.

• Permissions are the ability to perform operations on protected objects. • Objects are potential resources to protect, that contain or receive

infor-mation, such as files or directories in an operation system.

• Operations are actions through which users can perform on objects in the system. The type of these operations depends on the considered system. For example, within a database management system, operations include insert, select, delete, and update.

Figure 2.3 shows the core RBAC elements and their relations. The central of RBAC is the concept of role relations, including User Assignment and Per-mission Assignment. A user assignment shows that a user can play one or more roles, and a single role can be assigned to more than one user. Comparably, a permission assignment is a many-to-many relation. That means that a single permission can be assigned to several roles, and a single role can be associated to multiple permissions.

Core RBAC also introduces the concept of Sessions, which is associated with the dynamic aspect of RBAC. During a session, a user might activate one or many roles. At a given moment, the permissions which are available to a user are those associated to the roles activated during the user’s session. A user may establish one or more sessions, but a session is established by a single user.

40 Background

Figure 2.3: Core RBAC [1]

2.4.2

RBAC Constraints

It has been long recognized that collusions among users is a major security issue within an organization. To minimize such a fraud, additional constraints are addressed in RBAC models. For example, one may require different users to perform a delicate business function. This is a type of separation of duty constraints.

Separation of duty can be either static or dynamic [42]. The distinction between static separation of duty (SSD) and dynamic separation of duty (DSD) constraints is based on the moment they are established. A SSD constraint can be defined during the assignment of users to roles. For example, we may want to state that two conflict roles should not be assigned to the same user. On the other hand, a DSD policy should be verified during the execution of the system. For instance, a user is allowed to activate two exclusive roles independently but it is prohibited to activate them simultaneously.

History-based constraints can be seen as a special type of DSD constraints. This kind of constraints takes into account the history of the system resources access. In some situations, a coordination of permissions is necessary in order to prevent fraud. For example, within a shopping online system, a special order has to be received by the client who demanded it. That means we have to store the actions history in order to grant or deny other actions. On the other hand, a fraud prevention can be implemented by splitting a business functionality into a set of actions that are assigned to different users. For example, in an inventory system, we may want to state that a purchase order cannot be created and received by the same user.

RBAC in Database Management Systems 41

2.4.3

SecureUML

SecureUML [2,43] is a UML-based modeling language for access control policies. SecureUML extends UML models with concepts of RBAC, such as roles, users, and permissions. Using SecureUML, it is possible to visually represent security requirements based on RBAC along with the functional aspect of secure systems. The metamodel encoding the abstract syntax of SecureUML is depicted in Figure 2.4. Essentially, this language expresses which roles are assigned to which users, which permissions are assigned to which roles, which actions and constraints are assigned to which permissions, and which resources are assigned to which actions. Actions related to permissions can be either atomic or com-posite. An atomic action denotes an actual operation from the modeled system, whereas a composite action groups lower-level actions to specify permissions for a set of actions.

Figure 2.4: SecureUML metamodel [2]

SecureUML allows a separation of the functional and security aspects of the system to secure. The functional component is represented using UML diagrams, whereas the security component is designed using UML profile exten-sions like stereotypes, tagged values, and constraints. SecureUML can also be combined with other design modeling languages, such as ComponentUML and UML class diagrams. The goal is to automatically generate applications and their associated security infrastructures from those combined models.

2.5

RBAC in Database Management Systems

RBAC has received a considerable attention as an alternative approach for tra-ditional mandatory and discretionary access controls, because it significantly simplifies the security management within organizations. Recently, most popu-lar commercial database management systems support RBAC. In this section, we analyze RBAC features supported in Microsoft SQL Server (version 2014).

42 Background

2.5.1

Database User

Each database has a list of database users. Every user is mapped to a login, which is an identity that the user uses to authenticate himself within a database instance. A login can be created, changed, and removed from a database. Sim-ilarly, we can create a new user and delete an existing user in a database.

Before creating a user in SQL Server, a login must be created. The CRE-ATE LOGIN statement creates a new login that can be used to connect to a SQL Server instance. Because it is a high-rank privilege, only security admin-istrators can have this right. A login name within a database must be unique. The following statement creates the bobLogin login with a password bobPwd.

CREATE LOGIN bobLogin WITH PASSWORD = bobPwd

After a login is created, it is then mapped to a user. To create a new user, we must use the CREATE USER statement. Only a security administrator has the right to execute this statement for it is a powerful privilege. For example, the following statement creates a user whose name is bob for the login bobLogin:

CREATE USER bob FOR LOGIN bobLogin;

2.5.2

User-defined Database Role

In SQL Server, a user-defined database role is created through the CREATE ROLE statement. The name of a role must be unique in the database. We can also specify the owner of the new role, i.e. a database user or role, by the AUTHORIZATION option. If no owner is specified, the new role will be owned by the user who executed the creation of that role. The following syntax creates the manager role.

CREATE ROLE manager;

2.5.3

User-Role assignment

Microsoft SQL Server supports a many-to-many relation between the users and the roles. That means that a role can have multiple users called members, and a user can play more than one role. To assign a role to a user, we use the ALTER ROLE statement together with the ADD MEMBER option. For example, the statement that assigns bob to the manager role is as follows:

RBAC in Database Management Systems 43

ALTER ROLE manager ADD MEMBER bob;

2.5.4

Permission assignment

In SQL Server, database-level permissions regulate the use of specific commands that access certain objects within the scope of the specified database. An object in SQL Server can be a table, a view, a table-valued function, a stored procedure, etc. In the thesis, we consider solely the granting of permissions on stored procedures.

Stored procedures

A stored procedure is a compiled database object that contains one or more SQL statements. Its goal is to reuse the code that is called in many places within applications. Instead of writing a query each time needed, we can encode it as a part of a stored procedure and call it when needed. A stored procedures is created using the CREATE PROCEDURE statement. For example, a simple stored procedure that gets all the bills in the OnlineShop database is defined by:

CREATE PROCEDURE getBill AS

SELECT ∗ FROM OnlineShop.Bill GO

The stored procedure offers several advantages, such as:

• As they are saved within the database, the syntax is checked in the database.

• Writting redundant code is avoided. Indeed, a stored procedure can be called as many times as needed from any machine that connects to the database.

• Grant permissions to execute a stored procedure can be assigned to user-s/roles.

Grant permissions

The owner of an object has the right to grant permissions on that object, and permissions can be assigned to roles or users. The syntax of granting permissions on objects is defined by:

44 Background

GRANT <some_permission> ON <some_object>

TO <some_user|some_login|some_role>

Regarding the stored procedure, the granting syntax implies: • < some permission >: EXECUTE.

• < some object >: the name of the granted stored procedure.

• < some user | some login | some role >: a database user, a log in, or a database role.

The following example grants the EXECUTE permission to the manager role on the stored procedure getBill within the OnlineShop database. The OBJECT phrase is optional if the schema name is specified. If the OBJECT phrase is used, the scope qualifier (::) is required.

GRANT EXECUTE

ON OBJECT::OnlineShop.getBill TO manager;

Granting the execution of a stored procedure to a role also means that this role is allowed to performed actions encapsulated within the stored procedure. The below list details the actions of the objects, that can be included in the body of the stored procedure.

• Table actions: DELETE, INSERT, REFERENCES, SELECT, UPDATE. • Column actions: SELECT, REFERENCES, UPDATE.

• ...

2.6

Aspect Oriented Programming

2.6.1

An overview

Aspect-Oriented Programming (AOP) [44] is a programming technique for im-proving the separation of crosscutting concerns in softwares. The goal is to help the engineer develop and maintain large applications. By doing so, it allows the developer to separately specify crosscutting concerns, and to insert them into the main logic without modifying the program itself.

Aspect Oriented Programming 45

Crosscutting concerns tend to affect several other modules in the system. Thus, their related implementations often span multiple implementation mod-ules. This can cause code scattering: code is duplicated in several modmod-ules. Thus, changing a concern requires to modify all the affected modules. On the other hand, in the system, a module may interact simultaneously with different crosscutting concerns. This can cause code tangling: several concerns are imple-mented in the same modules. That means that changing a concern may cause unintended modifications of other tangled concerns. Examples of crosscutting concerns are security, logging, synchronization, persistence, and so on.

AOP attempts to solve the tangling and scattering problems related to cross-cutting concerns by allowing the implementation of such concerns in stand-alone modules called aspects. The concept of an aspect is similar to a class: it can be abstract or concrete; it can extend other classes and aspects; it can contain at-tributes and methods. Applying AOP, the concern remains being a crosscutting to other modules, but localizing concerns is easier and clearer.

The compilation of a program developed using AOP differs from the com-pilation of an ordinary program in the way that, the aspect weaver tailors the aspect code with the main code before compiling into an executable code (Fig-ure 2.5). The weaver accepts the core functionality and the aspect program as inputs, and produces the desired total system operation.

Figure 2.5: Normal compilation process (left) and AOP compilation process (right)

AOP languages define three main elements for the modularization of cross-cutting concerns. These elements are explained in Subsection 2.6.2 introducing

46 Background

AspectJ:

• Joinpoints.

• A means for identifying joinpoints.

• A means for specifying behaviors at joinpoints.

2.6.2

AspectJ

AspectJ [45] is a general-purpose aspect-oriented extension for Java. It is a de facto standard for AOP. AspectJ uses Java syntax for encoding crosscutting concerns. As a result, AspectJ code is compiled into standard Java bytecode.

Joinpoint

The central concept in AOP is the joinpoint. A joinpoint is a position in the execution of a program. AspectJ allows a diversity of locations where a joinpoint can refer to, including:

• Method/Constructor call at which a method (a constructor of a class) is called.

• Method/Constructor execution at which an individual method/construc-tor is invoked.

• Field get at which a field of a class, object, or interface is read. • Field set at which a field of an object or class is set.

...

Pointcut

A pointcut (or a pointcut designator) is a collection of joinpoints and optional values in the execution context of the pointcut. A pointcut selects a number of joinpoints based on defined criteria. The criteria can be method names or method names specified by wild-cards. Pointcuts can be combined using and (&&), or (||), and not (!) operators.

Aspect Oriented Programming 47

Advices

The concept of advice is similar to that of function. Advices are used to specify code that should be executed at each joinpoint specified in a pointcut.

In AspectJ, there are three critical types of advices as follows:

• Before advice: the advice code starts execution when a joinpoint is reached but before the computation proceeds.

• After advice: the advice code starts execution after the computation of a joinpoint, but before exiting this point.

• Around advice is the most important and powerful advice. Such an advice surrounds the joinpoint, i.e. a part the advice code is executed before and another part is executed after the execution of the joinpoint. This advice can also choose to proceed the execution of the joinpoint or not.

Aspect

Aspects are modular units of crosscutting implementation. An aspect is a class that implements concerns that cut across other classes. In AspectJ, an aspect is declared by the keyword aspect. It includes pointcuts and advices. Only an aspect can define advices.

An example

To illustrate how AspectJ works, let us take a simple HelloWorld example. The method sayHello simply prints a hello message to a given name.

//HelloWorld.java

public class HelloWorld {

public static void sayHello(String name) {

System.out. println ("Hello, " + name); }

}

The aspect in this example aims to add messages before and after executing the method sayHello. Before printing the greeting message "Hello, name", the program should print "A greeting message from aspect! ". After printing the greeting message, it should print "See you soon! ".

48 Background

//HelloWorlAspect.java

public aspect HelloWorldAspect {

pointcut callSayHello() : call (public static void HelloWorld.sayHello(...) ) ;

//A before advice

before() : callSayHello () {

System.out. println ("A greeting message from aspect!"); }

//An after advice

after() : callSayHello () {

System.out. println ("See you soon!"); }

}

2.7

Conclusion

This chapter describes the basic concepts related to our work. First, we intro-duced the B method, a formal language that we use to formalize, validate, and verify security rules together with the functional requirements of an informa-tion system. Then, we presented an overview of model-driven engineering that is a software development methodology applied in our research. The security mechanism that we aim to treat, namely role-based access control, was carried on. Its features integrated in a commercial database management system was also studied. Finally, we specified the aspect oriented programming paradigm that we target to. In the next chapter, we will advance our investigations with existing works related to the topics that we are interested in.

Chapter 3

State of The Art

Contents

3.1 Introduction . . . 50 3.2 Techniques for Security Specification . . . 50 3.2.1 UML and OCL based approaches . . . 50 3.2.2 Alloy-based Approaches . . . 58 3.2.3 Z-based Approaches . . . 63 3.2.4 A B-based Approach . . . 68 3.2.5 Discussion . . . 72 3.3 Support Tools for Access Control Policies . . . 74 3.3.1 SecureMOVA . . . 74 3.3.2 B4MSecure . . . 77 3.3.3 Discussion . . . 79 3.4 Implementation of An Access Control Specification . . . 80 3.5 Enforcement of Access Control Policies . . . 82 3.5.1 Java Authentication and Authorization Service . . . 83 3.5.2 Annotation-based approaches . . . 83 3.5.3 AOP-based approaches . . . 84 3.5.4 Discussion . . . 86 3.6 Conclusion . . . 88

50 State of The Art

3.1

Introduction

In this chapter, we survey the state of the art on the specification and enforce-ment of access control policies together with a number of supporting tools in the security development. We start by examining approaches on security spec-ification using semi-formal and formal languages in Section 3.2. Afterwards, we review supporting tools for modeling, analysis and model transformations of security policies in Section 3.3. A selection of approaches on security code gen-eration is described in Section 3.4. Section 3.5 summarize a number of security enforcement techniques. Finally, we conclude the literature review in Section 3.6.

3.2

Techniques for Security Specification

This section reviews the literature on security specification techniques that em-ploy RBAC variants [40]. These techniques fall into two categories: semi-formal techniques refer to approaches using UML and OCL, while formal techniques are based on formal languages, such as Alloy [22], Z [23], and B [24]. The benefits and limitations of the presented approaches are also discussed.

3.2.1

UML and OCL based approaches

UML has been a standard modeling language in the software industry for decades. Meanwhile, OCL [46] has been used for expressing and analyzing constraints in object oriented models as a standard constraints specification language. Due to the fact that UML and OCL are widely used in industrial environments, there are a large number of UML and OCL based approaches to specifying access control requirements. In this manuscript, we highlight a selection of them.

Shin et al. in [3] used different UML models to represent various views of RBAC. These views are as follows:

• Static: the static view embodies the conceptual structure of RBAC using a UML class diagram. Figure 3.1 depicts the static model of RBAC. Classes are used to represent the basic elements of RBAC, namely User, Role, Permission, Constraint, and Session. The Role and Permission classes may be specialized into two categories, i.e. user and administrative, depending on the level of users’ qualification. A constraint is defined for a user, a role, a permission, or a session. In addition, the static model

Techniques for Security Specification 51

has a special class called Session Hour. This class is used when a user has to establish a session to activate her/his roles. This notion is useful to express session-based constraints. For example, an organization may require that a session is only valid within one hour.

Figure 3.1: A static model [3]

• Functional: the functional view constructs more clearly functions that the RBAC system should provide by using UML use case diagrams. For example, this view can be used to describe roles within a system and their permitted actions. Figure 3.2 illustrates that the actor User is permitted to establish sessions, request permission approval, and close sessions. • Dynamic: the dynamic view uses UML collaboration diagrams to refine

the use cases of the functional view. The goal is to show interactions among elements of the use case diagram. The collaboration diagram for Permission Approval is illustrated in Figure 3.3. It requires that a session should be created to activate roles before approving the permission. Although UML models are investigated to represent the different aspects of RBAC, this approach does not address the validation of these models. Also, it omits the notion of protected resources in RBAC. As a result, there is no interaction between security and functional requirements.

In [4], Ahn et al. proposed to use UML and OCL to express RBAC con-straints at the design stage. In this work, the basic entities of RBAC and their relations are represented using a UML class diagram (Figure 3.4), whereas the