Model Driven Engineering

Model driven engineering (MDE) [16] is a software engineering approach that uses models to abstract and reduce the complexity in implementing systems. It also can be used as a means to capture the ‘knowledge’ of a system during run- time [2, 16] (i.e., the ‘K’ in MAPE-K [73]). Models are viewed as first class entities in MDE [125], where they provide understanding of a system (e.g., its structure, state, configuration). A common approach within MDE is to abstract a given system in terms of three layers, known as the 3+1 MDE architecture [15] (Figure 4.1).

CHAPTER 4. MODEL DRIVEN SELF-ADAPTIVE AUTHORISATION 84

Figure 4.1: The 3+1 MDE architecture [15]

The 3+1 MDE architecture classes model layers in terms of the real world, M0 (i.e., the system), and the modelled world, M1 to M3 (i.e., abstractions of the real world). A concrete example of this is an organisation’s requirements of access M0 is modelled as a UML class diagram M1. The class diagram conforms to the UML standard [106], which in this case represents a metamodel M2 of what can exist within a UML model. Lastly, the UML metamodel must conform to a meta- metamodel M3, defining the constructs of the UML modelling language (in this case, the model object family (MOF) [105]).

Models in MDE are contextual, as without context a model is ambiguous. Bezivin et al. argue that in order to provide context, a technical space [16, 78] must be considered. The technical space describes a specific modelling framework in accordance to the 3+1 MDE architecture, where there exists a family of lan- guages to express models, and a set of tools capable of developing, generating, and processing models. For example, the MOF technical space has already been described for UML, another example is the XML technical space.

This research makes use of MDE to develop metamodels that are used to model authorisation infrastructures at runtime. In this case, metamodels are developed to describe states of access control methodologies, such as Attribute Based Ac- cess Control (ABAC). The benefits of this approach allows for abstraction from implementation specific knowledge, enabling a SAAF autonomic controller that reasons and adapts at a model level to be free from constraints in interpreting complexity in the target system. It enables a concise definition of the state of access, one that can be transformed (into various implementations) and verified for its conformance to an access control methodology.

Model Transformation

Model transformation [126] is useful for simplifying models, or aggregating mul- tiple models in order to reason about emergent properties. It has the benefit of ensuring output models conform to their corresponding metamodel, negating con- cerns that an output model may contain invalid types. This can be achieved in terms of transforming a source model to a target model within the same technical space (i.e., endogenous), or to a target model in a different technical space (i.e., exogenous) [85].

Figure 4.2: Exemplified model transformation pattern [67]

Jouault et al. discuss a model transformation pattern (instantiated in Fig- ure 4.2), for endogenous transformation [67]. In this example, transformation is confined to the Ecore [23] technical space, a prominent model management frame- work. An ABAC PERMIS access control policy [31] (Section 2.2.4) is modelled in terms of a PermisPolicyM, conforming to a metamodel PermisMM. A transfor-

mation program aims to transform the PermisPolicyM into a homogeneous model

of access ABACM, conforming to the ABACMM metamodel. The transformation

program is created using the Atlas transformation language (ATL) [67]), a domain specific language for transforming models within the Ecore technical space. Given a set of diverse ABAC policy formats, transformation enables the generation of a homogeneous model of access that an autonomic controller can reason and adapt.

Model Verification

Model verification enables software developers to ascertain a level of confidence in the modelled state of the system before deployment. It is concerned with how

CHAPTER 4. MODEL DRIVEN SELF-ADAPTIVE AUTHORISATION 86

accurately the model achieves its intended goal.

Relevant to this research is the verification of the state of access. Verifying that a model of access meets an organisation’s requirements is a complex and non-trivial task, yet several approaches provide programmatic solutions. Hu et al. make use of a model checker [38] in which MAC [75] access control policies are modelled and assessed against logical constraints. In similar work, Hughes and Bultan use a SAT solver [95] to verify XACML access control policies [59]. Here, properties of access control are modelled as mathematical logical formulas that result to true or false, and assessed against access requirements. A final exam- ple is verifying RBAC access control through rbacDSML [87], by Montrieux. In Montrieux’s approach, requirements are captured within a UML model of access, and are evaluated using OCL constraints [145].

Traditionally, model verification is conducted at development time, where each change requires verification. However, a self-adaptive approach requires verifica- tion at runtime, whereby model verification is conducted in line with adaptations. The challenge with adopting such approaches is the cost in verification, as most model verification techniques perform an exhaustive task to produce a high level of confidence of verified models.

4.2.2

rbacDSML: RBAC Verification Tool

As discussed previously, Montrieux’s rbacDSML approach [87] allows for the ver- ification of RBAC access control models, enabling large organisations to manage their access control models with greater accuracy, efficiency, and assurance.

rbacDSML defines a domain specific modelling language (DSL). It enables the modelling of RBAC access control criteria in conformance to the RBAC standard. A standalone tool has also been developed [88], and enhanced for self-adaptive authorisation [8]. In addition to enabling the design of RBAC models, it also enables verification of the model against the RBAC standard and access require- ments. Finally, given a RBAC model that fails to meet the access requirements, the rbacDSML tool is capable of identifying fixes to the model. However, this is a time consuming process and currently inappropriate for runtime use.

rbacDSML is implemented as a profile that extends the Unified Modelling Language (UML). It defines UML stereotypes and associations to express what can exist in an RBAC model, and how elements of an RBAC model relate. Figure 4.3 conveys rbacDSML’s metamodel, in which users (subjects), roles, permissions, and

Figure 4.3: Extended rbacDSML metamodel [8] in MOF

resources are defined as stereotypes. Facets of the RBAC standard are defined with rbacDSML’s metamodel as stereotyped associations between stereotyped classes. In addition to the stereotyped classes to represent the RBAC standard, the rbacDSML tool also includes ‘scenario’ stereotypes. These stereotypes are critical to capturing access requirements that an RBAC model must be verified against. The use of OCL constraints enables the verification of scenarios against the RBAC model, and can verify the model in a variety of ways: User scenarios exist to specify an access control requirement, where a user must be granted (or denied) access to a particular resource (e.g., User ‘bob’ can access Resource ‘printer’). User - role scenarios express a condition where a role must be assigned to at least one user (e.g., Role ‘staff’ must have at least one user). Role - resource scenarios can be verified against an RBAC model to ensure a particular role has access to a given resource, via the role’s permissions. Finally, Resource scenarios define a minimum availability of access to a resource, where at least one user should be capable in accessing a given resource.

4.3

SAAF Controller: Prototype

This section describes the design and implementation of the Self-Adaptive Autho- risation Framework (SAAF) controller prototype. The aim of the prototype is to showcase a fully working feedback loop, capable of monitoring and controlling a class of authorisations infrastructures (i.e., categorised by a given access control

CHAPTER 4. MODEL DRIVEN SELF-ADAPTIVE AUTHORISATION 88

model). For implementation reasons, some processes within the controller’s feed- back loop have been simplified in order to close the loop, these processes can be improved upon by future projects. Statistics pertaining to the substantive nature of the prototype’s code base are identified in Appendix A.1.