A domain-specific language for the specification of UCON policies

Journal of Information Security and Applications 64 (2022) 103006 Available online 2 November 2021 2214-2126/© 2021 The Author(s). Published by Elsevier Ltd. This is an open access article under the CC BY-NC-ND license (http://creativecommons.org/licenses/by-nc-nd/4.0/). Contents lists available at ScienceDirect Journal of Information Security and Applications journal homepage: www.elsevier.com/locate/jisa A domain-specific language for the specification of UCON policies Antonia M. Reina Quinteroa,∗, Salvador Martínez Pérezb, Ángel Jesús Varela-Vacaa, María Teresa Gómez Lópeza, Jordi Cabotc aDpto. Lenguajes y Sistemas Informáticos, Universidad de Sevilla, Spain1 bLab-STICC, IMT Atlantique, Brest, France cICREA-UOC, Barcelona, Catalunya, Spain ARTICLE INFO Keywords: Cybersecurity Access control Model-driven engineering UCON DSL ABSTRACT Security policies constrain the behavior of all users of an information system. In any non-trivial system, these security policies go beyond simple access control rules and must cover more complex and dynamic scenarios while providing, at the same time, a fine-grained level decision-making ability. The Usage Control model (UCON) was created for this purpose but so far integration of UCON in mainstream software engineering processes has been very limited, hampering its usefulness and popularity among the software and information systems communities. In this sense, this paper proposes a Domain-Specific Language to facilitate the modeling of UCON policies and their integration in (model-based) development processes. Together with the language, an exploratory approach for policy evaluation and enforcement of the modeled policies via model transformations has been introduced. These contributions have been defined on top of the Eclipse Modeling Framework, the de-facto standard MDE (Model-Driven Engineering) framework making them freely available and ready-to- use for any software designer interested in using UCON for the definition of security policies in their new development projects. 1. Introduction The description and analysis of security policies are essential for an organization [1]. Moreover, the lack of incorporation of security policies into the daily processes and their information systems can bring about the failure to achieve the business objectives and probably security flaws. For this reason, the SANS Institute defines a security policy as a set of security requirements or rules (i.e., access control restrictions) that must be met to achieve the business goals. To ensure the proper operation of companies, it is necessary to follow both the defined processes and the security policies that restrict potential security threatening situations that put at risk the data and the stakeholders [2]. For this reason, any information system and, especially, any Process- Aware Information Systems (PAIS) [3] must include the security policies that provide the mechanisms to achieve properly the business goals. PAIS manage the operational processes that involve software applications, the data storage, and the people that interact with the processes; thereby, these systems cannot be misaligned with the security policies. Leitner et al. [4] states that security control remains an open challenge in PAIS. Current solutions based on traditional access control models [5] fail to contemplate and evaluate the flexible and ∗Corresponding author. E-mail addresses: [email protected] (A.M. Reina Quintero), [email protected] (S. Martínez Pérez), [email protected] (Á.J. Varela-Vaca), [email protected] (M.T. Gómez López), [email protected] (J. Cabot). 1IDEA Research group: http://www.idea.us.es/. complex security policies that modern business information systems demand. These traditional access control models include Mandatory Access Control (MAC), that restrict through a set of rules the access of an object or the execution of an operation; Discretionary Access Control (DAC), where the capacity of access relies on the owner of the object; and, Role-based Access Control (RBAC) that is oriented towards roles and privileges. However, these three access control models fail to integrate sophisticated decision-making, because they focus on the request and grant the access only at request time, losing the perspective of the ongoing controls that can change over time. Moreover, these traditional access controls fail to incorporate a temporal perspective and restrictions regarding the number of uses of the resources. As a response to these limitations, the Usage Control (UCON) model [6] was proposed. UCON extends previous access controls models with the addition of the primitives that enable more complex security policies. An example of a security policy that UCON can handle, but not the previous access control models, is: the operational staff is not allowed to review more than ten loan requests in less than three days. This rule restricts the rights according to a specific period of time https://doi.org/10.1016/j.jisa.2021.103006 Journal of Information Security and Applications 64 (2022) 103006 2 A.M. Reina Quintero et al. and a number of accesses, two aspects that only can be managed with UCON. Therefore, integrating UCON in software and system design tools, including business process modeling tools such as BonitaSoft [7], jBPM [8], and Activiti [9] that currently do not support the modeling of complex security policies, as the ones enabled by UCON, would be a major step forward in the definition and implementation of secure information systems. One first attempt to deal with UCON policies was published in [10] where an extension of artifact-centric business process models to deal with partial UCON policies was proposed. However, the solution was not generic and only useful for that specific type of models and, moreover, UCON expressiveness was not completely supported, and the metamodel was not formalized. In this paper, a domain-specific language for specifying UCON policies is proposed. This language is generic and fully compliant with the UCON specification, enabling definition and integration of UCON policies in any type of model. As such, as far as we know, ours is the first proposal that presents a UCON metamodel that covers the whole access control model and that is flexible enough to be added to any modeling toolchain. In other words, our approach aims at providing MDE tools to implement the original UCON. Additionally, our approach covers not only the specification of UCON access control rules but also their enforcement by leveraging the same modeling infrastructure we used to create the language in the first place. Model-Driven Engineering (MDE) [11] promotes the rigorous use of software and systems models in all software engineering activities and also facilitates the development process, the code generation, and the integration in different environments [12,13]. Policy enforcement is explored by means of an application-independent structure based on a Policy Enforcement Point (PEP)-Policy Decision Point (PDP) architecture. This architecture is implemented by using model transformations, concretely, the ATL model transformation language and framework [14] are proposed to evaluate rules at run-time. Furthermore, to illustrate the usability of the proposed Domain-Specific Language, a complex running example that includes UCON policy rules related to both the processes and the data model has been employed. The rest of the paper is structured as follows: Section 2intro- duces the necessary concepts to understand the UCON model, the model-driven engineering, and the ATL model transformation language; Section 3introduces the running example that illustrates the need for defining policies with a UCON-based language; Section 4introduces the model-driven approach and its application to the motivating example; Section 5goes over the most relevant previous papers related to access control; and, finally, conclusions are drawn and further works are pointed out. 2. Background This section is structured as follows: Firstly, Section 2.1 introduces the main concepts behind the Usage Control Access Model (UCON). Afterwards, Section 2.2 gives a general overview of model-driven engineering and the notion of domain-specific language, and then focuses on model transformations as the tool in the model-driven field we will employ later on to provide a robust, flexible, and re-usable run-time evaluation engine for the UCON policies. But before diving into the following subsections, it is worth to remark that the word model has slightly different semantics in the field of access control and the field of model-driven engineering. While in access control, a model is a formal definition of a set of access control rules that is technology-independent of how these rules are later enforced, a model in model-driven engineering is an abstract representation of a system perspective that conforms to a specific language/metamodel [15]. Fig. 1. UCON components [16]. 2.1. The Usage Control access model (UCON) Usage Control (UCON𝐴𝐵𝐶 ) [16] is a model that goes beyond traditional access control models by inheriting all their merits and providing a finer-grained decision-making ability. The UCON model comprises three core components (i.e., subjects, objects and rights); and three additional components (i.e., authorization rules, obligations and conditions) represented in Fig. 1. Note that the core components are similar to the ones defined in traditional models, such as the RBAC model, while the additional components provide the extra decision-making ability. The components are described as follows: Core components: •Subjects are the entities that hold rights on objects. •Objects are the entities which subjects can access with certain rights. •Rights are the actions that the subjects can perform on objects. Additional components or predicates: •Authorizations (A) are predicates that have to be evaluated to decide whether the subject is allowed to execute the rights on the objects. Authorizations can be pre-authorizations (preA), that are performed before the rights are exercised, or ongoingauthorizations (onA), that are evaluated while the rights are exercised. •Obligations (B) are predicates that verify mandatory requirements that the subjects have to comply with before (pre-obligation) or during the exercise of the rights (ongoing-obligations). •Conditions (C) are predicates that evaluate environmental or system status conditions as additional obligations for the access. Subjects and Objects have attributes that represent properties or capabilities that can be used for deciding whether the subject can access the object. Attributes can be mutable or immutable. UCON𝐴𝐵𝐶 model introduces the concept of mutability which indicates whether certain attributes can be modified during the usage decision process. Note that, unlike authorizations and obligations, condition variables must be immutable. Furthermore, it also should be borne in mind that the mutability of attributes and the continuity (ongoing authorization) of an access decision are the two novel aspects that UCON𝐴𝐵𝐶 introduces in comparison with traditional control access approaches [16]. The incorporation of these new aspects implies that if an access attribute is changed while the access is in progress making the security policy not satisfied, then the granted access is revoked and the usage is terminated. Fig. 1 depicts how the usage decision functions depends on subject attributes, object attributes, authorizations, obligations and conditions. The UCON policy identifies 24 usage control models (see Table 1) that are the result of combining pre and ongoing authorizations (preA, onA), obligations (preB, onB) and conditions (preC, onC) with attribute updates that can be performed before, during or after the access. For example, a UCON rule of preA3type represents a usage control scenario where the access decision is evaluated only once before beginning the Journal of Information Security and Applications 64 (2022) 103006 3 A.M. Reina Quintero et al. Table 1 The 𝑈𝐶𝑂𝑁𝐴𝐵𝐶 models obtained from [16]. 0 (inmutable) 1 (pre-update) 2 (ongoing-update) 3 (post-update) preA ✓ ✓ ✗ ✓ onA ✓ ✓ ✓ ✓ preB ✓ ✓ ✗ ✓ onB ✓ ✓ ✓ ✓ preC ✓ ✗ ✗ ✗ onC ✓ ✗ ✗ ✗ usage. Note that traditional access control approaches can be expressed with UCON preA0and preA1(pre-authorizations without attribute update and with attribute pre-update, respectively). 2.2. Model-driven engineering Model-driven engineering (MDE) [11] promotes the rigorous use of software and systems models in all software engineering activities. A key element in any MDE approach is the choice of the right modeling languages for the task at hand. In this respect, Domain- Specific Languages (DSLs) are languages that are designed specifically for a certain domain, context, or company to ease the task of people that need to describe things in that domain. The core element of any DSL is its metamodel that defines what modeling primitives are part of the language and how they can be combined (akin to the role of grammars in programming languages). The de-facto standard for defining metamodels in practice is EMF (Eclipse Modeling Framework) [17]. Metamodels can be complemented with well-formedness rules defined in OCL (Object Constraint Language) [18] to further restrict the set of valid models allowed in the language. Once a model is defined it can be transformed into another type of model (a model-to-model transformation or M2M) or into a textual representation (model-to-text or M2T, also referred to as code-generation when the text artifact target of the transformation is a coding artifact). Model transformations are fundamental in model-driven engineering as they provide the means for automating the manipulation of models. A model to model transformation (M2M) transforms a model 𝑀𝑎conforming to a metamodel 𝑀𝑀𝑎into a model 𝑀𝑏conforming to metamodel 𝑀𝑀𝑏where 𝑀𝑀𝑎and 𝑀𝑀𝑏can be the same or different metamodels. While this kind of transformation can be implemented by using general purpose languages, model-transformation languages and frameworks exist in order to ease its specification by providing facilities to efficiently query and manipulate models. In this respect, there exist many different model transformation languages and paradigms with different features, e.g., ATL (Atlas Transformation Language) [14], ETL (Epsilon Transformation Language) [19] or QVT (Query-Views- Transformation) [20]. Due to its associated tooling and maturity, ATL is one of the most popular transformation languages among academic and industrial practitioners. Thus, ATL is the model transformation language of choice for this work but our proposal could be similarly implemented on top of the other transformation proposals listed before. In order to clarify how model transformations are specified, a simple ATL transformation module is shown in Listing 1. This example has been extracted from the ATL transformation Zoo.2It translates Class definitions to relational Table definitions. It uses the Class and Table metamodels depicted in Figs. 2a and 2b respectively. An ATL transformation (module) is composed of a set of transformation rules and helpers. Each rule describes how (part of) the target model should be generated from (part of) the source model. A helper can be seen as an auxiliary function that enables the possibility of factorizing ATL code used in different points of the transformation. Note that ATL uses OCL as its navigation and query language. 2https://www.eclipse.org/atl/atlTransformations/. In Listing 1, lines 1–2 declare the transformation name along with the input and output metamodels. This transformation contains a rule called Class2Table (lines 7 to 22) that matches every Class in the Class model to produce a Table in the output model. It does so by using a helper function that returns the integer type defined as a datatype in the class model (lines 4 and 5). Rules are mainly composed of an input pattern (line 9) and an output pattern (line 10 to 21). The input pattern filters the subset of source model elements that are concerned by the rule. The output pattern details how the target model elements are created from the input ones (here two output pattern elements are created, a table and a key column). Each output pattern element can have several bindings (lines 12, 15, 16, 19 and 20) that can be used to initialize the values of the elements in the target model. Listing 1: ATL Transformation Module Example 1module Class2Relational; 2create OUT :Relational from IN :Class; 3 4helper def :objectIdType :Relational!Type = 5Class!DataType.allInstances()−>select(e|e.name =’Integer’ ↪)−>first() ; 6 7rule Class2Table { 8from 9c:Class!Class 10 to 11 out :Relational!Table ( 12 name <−c.name, 13 -- Columns are generated from Attributes in another ↪rule 14 -- not explicitly called here ! 15 col <−Sequence {key}−>union(c.attr−>select(e|not e. ↪multiValued) ) , 16 key <−Set {key} 17 ) , 18 key :Relational!Column ( 19 name <−’objectId’ , 20 type <−thisModule.objectIdType 21 ) 22 } In our approach, model transformations feed the model transformation engine that is used as off-the-shelf access control evaluation engine [21]. Note that creating an access-control evaluation engine for a given access-control model from scratch is a complex and timeconsuming task. For further details of how model transformations supports our approach see Section 4.2. 3. Running example To introduce the scenarios where UCON is necessary and how our proposal can facilitate the description of the policies, we introduce a running example related to a customer’s loan request process [22]. The example is presented in two different, but complementary, perspectives: the activity-centric and the data perspectives. The activity-centric perspective of the process includes the activities execution flow, the actors involved, and the interactions between them. The data perspective involves the data entities and how they are related through a data model. Fig. 3 shows the activity-centric perspective by means of a business process model [23] in which three different actors are involved: the Customer pool shows how a customer requests a loan to a credit supplier and receives a notification (i.e., approved or non-approved); the Credit Supplier pool describes how the administration staff manages the loan request, obtains the acceptance report and notifies customers the decisions; and, the Operation Staff pool, that shows how they deal with the evaluation of the loan requests and generate reports. This process model is insufficient to fully depict the data exchanged in the process activities. A business process model must be supported by a proper data model [24]. Fig. 4 depicts the UML class diagram for the running example, that involves some data entities and relations not included in the process model, but necessary for the complete Journal of Information Security and Applications 64 (2022) 103006 4 A.M. Reina Quintero et al. Fig. 2. Input and output metamodels. Fig. 3. Business process model for the running example. description of the problem domain. Some entities (classes in UML terminology) of the data model are related to pools in the process (e.g., Operational Staff), others are part of the data flow of the process model (e.g., Loan Request Report), and others do not appear in the business process model (e.g., Account). The different entities and their relations (associations in UML terminology) can be constrained by a security policy. For instance, any Customer needs an account and validated credentials for the Credit Supplier before requesting a loan. Nevertheless, both process and data models alone become also insufficient to reflect certain access and usage control policies that span a single system perspective. For instance, the Customer is limited to perform a certain number of loan requests during a period of time. The enforcement of this type of access control rule needs the analysis of both the data and process aspects. To illustrate the need for this complex security polices, we define a potential ruleset for the running example. The ruleset is composed of a set of rules exemplifying the 16 types of predicates defined by the UCON model (see Table 1). The set of rights used in the ruleset are described as follows: •Request a loan: the customer sends a loan request to the credit supplier. •Review a loan request: the operational staff reviews the loan request received for the credit supplier. •Create a loan request report: the operational staff creates a report for each loan request that he/she will review. •Update account balance: the customer’s balance is updated according to the loan terms. •Send notification: the credit supplier sends a notification to the customer for each loan request. •Create a loan file: the credit supplier creates a loan file for each accepted loan request. The set of rules in the ruleset are described next. They are grouped by the type of predicate (authorization, obligation, condition). Note also that subjects (S), objects (O), and rights (R) involved in the rule have been included in order to better illustrate the rule context. •Authorization rules: –𝑝𝑟𝑒𝐴0(S: Operational Staff, O: Loan Request, R: Review a loan request): the two persons (operational staff) who review the loan request cannot be the same (Separation of Duties). –𝑝𝑟𝑒𝐴1(S: Customer, O: Loan Request, R: Request a loan): the customer is allowed to request a loan if the remuneration after costs is greater than half the remuneration. –𝑝𝑟𝑒𝐴3(S: Customer, O: Loan Request, R: Request a loan): the customer is allowed to request no more than three loans. –𝑜𝑛𝐴0(S: Customer, O: Loan Request, R: Request a loan): the customer is allowed to do a loan request while its credentials are not revoked. Journal of Information Security and Applications 64 (2022) 103006 5 A.M. Reina Quintero et al. Fig. 4. Data model for the running example. Fig. 5. UCON metamodel top elements. –𝑜𝑛𝐴1,3(S: Operational Staff, O: Loan Request Report, R: Review loan request): the operational staff is not allowed to review more than ten loan requests at the same time. –𝑜𝑛𝐴1,2,3(S: Operational Staff, O: Loan Request Report, R: Create a loan request report): the operational staff is allowed to create a new loan report if he/she has no more than five pending (i.e., non-sent) and inactive (i.e., nonrecently updated) reports. •Obligation rules: –𝑝𝑟𝑒𝐵0(S: Customer, O: Loan Request, R: Request a loan): the customer has to agree the GPDR statement before requesting a loan. –𝑝𝑟𝑒𝐵1(S: Customer, O: Loan Request, R: Request a loan): the customer has to agree the loan terms of all the customer’s loan request before requesting a loan. –𝑝𝑟𝑒𝐵3(S: Credit Supplier, O: Account, R: Update account balance): after a loan request is approved, the customer’s balance has to be updated according to the amount and costs of the loan. –𝑜𝑛𝐵0(S: Operational Staff, O: Loan Request, R: Review a loan request): the operational staff has to review a loan request while the control time system is active. –𝑜𝑛𝐵1,3(S: Task Collecting Rating Reports, O: Task Send Approved Notification, R: Send notification): the credit supplier has to ask for the pending reports to collect the rating of the loans before sending a acceptance notification. –𝑜𝑛𝐵2(S: Task Send Notification Receipt, O: Task Open Loan File, R: Create a loan file): to allow a credit supplier open a loan file, the customer has to send an acknowledgment of receipt before two days. •Condition rules: –𝑝𝑟𝑒𝐶0(S: Customer, O: Loan Request, R: Request a loan): the customer is not allowed to request a loan from a mobile phone device. –𝑜𝑛𝐶0(S: Operational Staff, O: Loan Request, R: Review a loan request): the operational staff is allowed to review a loan request during office hours (9 am–17 pm). Note that there are rules, such as 𝑝𝑟𝑒𝐴0(SoD), that could be modeled with traditional access control models, but others cannot (see, for instance, 𝑜𝑛𝐵1,3). Regarding subjects and objects, there are rules in which the subject and the object refer to entities of the data model, such as Customer and Loan Request (in 𝑝𝑟𝑒𝐴0) and others that refer to elements of the process model, as the 𝑜𝑛𝐵1,3rule. Both rules need the task context to define the predicate. Journal of Information Security and Applications 64 (2022) 103006 6 A.M. Reina Quintero et al. Fig. 6. UCON metamodel rules. Regarding the update operations, the 𝑝𝑟𝑒𝐴0,𝑜𝑛𝐴0,𝑝𝑟𝑒𝐵0,𝑜𝑛𝐵0, 𝑝𝑟𝑒𝐶0and 𝑜𝑛𝐶0predicates in the running example do not require any update on the subject’s and on the object’s attributes. For instance, the 𝑝𝑟𝑒𝐴0predicate needs to consult the loan request attributes to check its status. Other predicates imply update operations, thus, in the following we specify the update operations needed for each predicate and the attributes involved: •𝑝𝑟𝑒𝐴1: the 𝑟𝑒𝑚𝑢𝑛𝑒𝑟𝑎𝑡𝑖𝑜𝑛 attribute of the customer must be preupdated before granting the right. •𝑜𝑛𝐴1,3: while the operational staff is exercising the right, the number of loan requests reviewed must be pre-updated by adding a new one, and it must be post-updated by reducing the number of loan requests reviewed in case of revocation. •𝑜𝑛𝐴1,2,3: while the operational staff is exercising the right, the number of loan request reports created must be pre-updated, and it must be post-updated by reducing the number of loan request reports in the case of revocation. Additionally, we need to maintain indexed the less active loan request reports in each moment by on-updating the 𝑙𝑒𝑠𝑠𝐴𝑐𝑡𝑖𝑣𝑒 attribute within operational staff. •𝑝𝑟𝑒𝐵1: the customer must agree the loan terms, thereby, the 𝑙𝑜𝑎𝑛𝑇 𝑒𝑟𝑚𝑠 attribute of all the loan requests of a customer must be pre-updated and its value should be set to 𝑡𝑟𝑢𝑒 before doing the loan requests. •𝑜𝑛𝐵1,3: the customer must fill in the form with the data of the loan to be requested, the number of loan requests sent must be pre-updated by adding a new one, and it must be post-updated by reducing the number of loan requests reviewed in case of revocation. •𝑜𝑛𝐵1,2,3(Acceptance Notification and Negative Notification): the credit supplier must ask for the pending reports before sending notifications (acceptance or negative). The number of loan request reports received must be pre-updated by adding a new one, and it must be post-updated by reducing the number in the case of revocation. Additionally, we need to maintain updated the reports created in each moment by on-updating them in case of incoming new reports in the credit supplier. •𝑝𝑟𝑒𝐴3: the number of loan requests done by a customer must be post-updated before granting the right. •𝑝𝑟𝑒𝐵3: the account’s 𝑏𝑎𝑙𝑎𝑛𝑐𝑒 attribute of the customer must be post-updated after checking that the loan request is accepted. 4. Definition, evaluation and enforcement of UCON policies Integrating access-control in a given technical space requires, once a suitable access-control paradigm has been selected, the means to: (1) define correct access-control policies conforming to that selected paradigm; (2) evaluate access requests (e.g., decide whether the access is permitted or not) to protected resources with respect to the aforementioned policy; and, (3) control the access to resources so that it occurs only as the access-control policy prescribes. Providing support to the aforementioned tasks is far from being trivial. In the following, we discuss how mature MDE tools and techniques alleviate this challenge and describe a full MDE approach for the definition, evaluation and enforcement of UCON access-control policies that enables full UCON support in modeling environments. 4.1. Policy definition In order to allow the definition of UCON access control policies, we have created a Domain-Specific Language (DSL) that captures and organizes the UCON concepts as defined in [16]. In the following, we describe the abstract syntax of this DSL which we have implemented as an EMF metamodel3[17]. Note that as concrete syntax we will use off-the-shelf tree-based model editors and XMI serialization, and that execution semantics are provided by translating the access-control policies to executable model-transformations specifications as we will show later. Alternative concrete syntaxes (either textual or graphical) can be easily defined with other EMF-based tools like Xtext4or Sirius,5 highlighting once again the side benefits we get once we enable UCON to the plethora of EMF modeling tools through the definition of our DSL. The top-level elements of our UCON metamodel are depicted in Fig. 5. The root element is the Policy metaclass, that acts as a container of the five sets of elements needed to describe access-control in our context, namely: Subjects,Objects,Rights,Rules and Environment.Subject, Object and Right represent respectively, and as described in [16], the active entity which requests access, the resource being accessed, and the concrete action to be performed with the access. Subjects and 3The EMF metamodel is publicly available in https://gitlab.com/smartine/ uconmde/. 4https://www.eclipse.org/Xtext/. 5https://www.eclipse.org/sirius/. Journal of Information Security and Applications 64 (2022) 103006 7 A.M. Reina Quintero et al. Objects may have Attributes which may be mutable or not (note that for simplicity in this version of the metamodel we consider all attributes to have basic types, such as Integer or String). The Environment metaclass is a place holder used to store environmental and context attributes used by conditions. Finally, the core concept of our metamodel is that of Rule. Fig. 6 shows the elements of our metamodel devoted to rules. Access-control decisions are described in UCON as implications, meaning that granting (or revoking) a given access implies, depending on the concrete UCON model, the fulfillment of a number of predicates and the execution of update procedures. We organize these concepts by introducing the Rule metaclass, which is not explicitly defined in UCON. Rules refer to exact one Subject,Object and Right.Rules may require a certain number of UpdateOperations to be performed on attributes before (PreUpdateOperation), during (OnUpdateOperation) of after (PostUpdateOperation) the access is granted. Finally, concrete Rules (the Rule metaclass is abstract) imply the fulfillment of UsageDecision- Functions. We define 6types of Rules:AllowRule,StopRule,ObligationAllowRule, ObligationStopRule,PreConditionAllowRule, and PreConditionStopRule.AllowRule and StopRule imply the fulfillment of a pre or continuous authorization respectively (PreAuthorizations and OnAuthorizations in the metamodel). ObligationAllowRule and ObligationStopRule imply the fulfillment of a list of pre or continuous obligations respectively (represented by the list of Obligations in the PreFulfilled and OnFulfilled UsageDecisionFunctions in the metamodel). Finally, PreConditionAllowRule and PreConditionStopRule imply the fulfillment of a list of pre or continuous environmental preconditions (represented as the lists of On- Conditions and Conditions in the PreConChecked and OnConChecked UsageDecisionFunctions in the metamodel). These rules combined with the different (valid) UpdateOperations cover the 24 basic UCON models, as described in Table 1, and allow us to describe all the rules in the running example presented in Section 3. As an example, an AllowRule combined with a PostUpdateOperation permits us to define the 𝑝𝑟𝑒𝐴3rule, whereas the combination of an ObligationAllowRule with a PreUpdateOperation would permit us to define rules, such as 𝑝𝑟𝑒𝐵1. Note that UpdateOperations and UsageDecisionFunctions contain a procedure and a predicate body respectively. The procedure is used in order to calculate the value needed for the update of a given attribute (e.g., in rule 𝑝𝑟𝑒𝐴3the subject number of the loan requests is incremented) whereas the predicate is used by rules as a necessary condition for granting access (e.g., in rule 𝑝𝑟𝑒𝐴3we verify that the number of loans is not bigger than 3). Both procedures and predicates may be arbitrarily complex expressions, therefore, the metamodel is needed to integrate a sufficiently expressive language to deal with them. In that sense, we chose to use OCL as the expression language for our metamodel. OCL [18] is a general-purpose (textual) formal language adopted as a standard by the Object Management Group6used to define several kinds of expressions that complement the information of models. OCL is a typed, declarative and side-effect free specification language.7Actually, we will use OCL with a double purpose: firstly, for the definition of procedures and predicates, and secondly, as a specification language to complement our metamodel and validate conforming models, as we show in the following subsection. Listing 2shows how the proposed approach is used to model a sample of the running example presented in Section 3. Concretely, it presents (part of) the model representing the authorization rule 𝑝𝑟𝑒𝐴3: (S: Customer, O: Loan Request, R: Request loan) stating that the customer is only allowed to request up to three loans. Lines 7 to 15 6https://www.omg.org/. 7Note that for simplicity we use String attributes as place holders for expressions. In future versions we intend to link directly to the OCL metamodel expression metaclass. show the definition of two subjects, Customer and CreditSupplier, with their corresponding attributes such as accounts, loanRequests or name. A LoanRequest object is declared in lines 17 to 24, containing diverse attributes such as cost, credditSupplier and loanTerms. Line 26 shows the declaration of the RequestALoan right. Finally, in lines 28 to 39 we show the definition of the aforementioned loan request authorization rule. The rule subject, object and right, are referenced at the beginning of the rule in lines 30 to 32. Then a postUpdate operation on the number of loan requests made by the Customer is defined between lines 33 and 36. The authorization rule ends with the definition of the authorization predicate needed for the grating of the permission (lines 37 and 38). Listing 2: UCON Policy Example in XMI 1<ucon:Policy 2xmi:version=" 2.0 " 3xmlns:xmi=" http ://www.omg. org/XMI" 4xmlns:xsi=" http ://www.w3. org/2001/XMLSchema−instance" 5xmlns:ucon=" http ://www. example . org/ucon" 6xsi :schemaLocation=" http ://www. example . org/ucon ucon . ecore "> 7<subjects id=" Customer "> 8<attr ibutes name=" accounts " /> 9<attr ibutes name="customerCredentials"/> 10 <attr ibutes name="loanRequests" mutable=" true " /> 11 </ subjects> 12 <subjects id="CreditSupplier"> 13 <attr ibutes name=" id " /> 14 <attr ibutes name="name" /> 15 </ subjects> 16 17 <objects id=" LoanRequest "> 18 <attr ibutes name=" id " /> 19 <attr ibutes name=" cost " /> 20 <attr ibutes name="creditSupplier"/> 21 <attr ibutes name=" customer " /> 22 <attr ibutes name=" account " /> 23 <attr ibutes name=" loanTerms " mutable=" true " /> 24 </ objects> 25 26 <rights id="R1−RequestALoan " name=" RequestALoan " /> 27 28 <rules xsi :type="ucon: AllowRule" 29 id=" preA3 " 30 subject=" Customer " 31 object=" LoanRequest " 32 right="R1−RequestALoan "> 33 <requires 34 xsi :type=" ucon : PostUpdateOperation " 35 procedure="loanRequests−>size ()+1" 36 target=" // @subjects .0/ @attributes .8 " /> // loanRequest Attribute 37 <implies 38 predicate=" subject . loanRequests−>s iz e ( ) < 3" /> 39 </ rules> 4.1.1. Well-formedness rules Models created with our UCON metamodel will be all syntactically correct. However, not all will be semantically correct. This is so because the language used to create the metamodel is not expressive enough to specify all the details and/or because doing so would make the metamodel more complex and less usable. In order to solve this issue, we need to provide well-formedness (WFRs) rules to validate the model. We use OCL for this purpose as aforementioned. Note that OCL integrates seamlessly with (some) existing MDE tools and permits the automatic evaluation of these rules at design time in order to produce correct UCON policies. That is, once the WFRs for UCON are defined, state-of-the-art OCL tools can be used to automatically ensure designers only specify correct UCON models. Listing 3shows the set of the most important WFRs. The first invariant verifies that the update operations of a rule only updates attributes belonging to the Subject or Object of the rule. The second and third invariants verify that the policy only uses pre or post update operations for 𝑝𝑟𝑒𝐴 and 𝑝𝑟𝑒𝐵 UCON models. The fourth and fifth invariants verify Journal of Information Security and Applications 64 (2022) 103006 8 A.M. Reina Quintero et al. that update operations are not permitted for 𝑝𝑟𝑒𝐶 and 𝑜𝑛𝐶 UCON models. Invariant 6 verifies that an update operation only uses mutable attributes. Finally, Invariant 7 verifies that the environment attributes must be immutable. Listing 3: Well-formedness Rules // Invariant 1−Context Rule inv validUpdaters: subject.attributes−>union(object.attributes) −>includesAll(requires−>collect(e ↪|e.target) ) ; // Invariant 2 , 3 −Context AllowRule,ObligationAllowRule inv updateIsNotOn: not requires−>oclIsTypeOf(OnUpdateOperation) ; // Invariants 4 , 5 −Contexts PreconditionAllowRule, ↪PreconditionStopRule inv updateOperationsNotPermitted: requires−>size() =0; // Invariant 6−Context UpdateOperation inv isMutable: target.mutable; // Invariant 7−Context Environment inv inmutableAttributes: attributes−>forAll(attr |not attr.mutable) ; Additionally to well-formedness rules verifying the correctness of UCON models, we can, in the same manner, define complex domainspecific and/or policy administration rules which are not tackled in the original definition of UCON. Or even WFRs that, for instance, adapt UCON when applied to a specific domain with very particular semantics. For more information on the use of MDE and OCL for the definition and evaluation of complex access-constraints see [25] and [26]. 4.2. Policy evaluation The metamodel we have described above allows us to define accesscontrol rules that determine what subjects can do on the resources of a system. This policy must be then consulted each time an access request to a protected resource is performed in order to determine whether it is permitted or not. Thus, for the effective integration of access control in business processes, we must provide a mechanism for the automatic evaluation of access requests with respect to a given policy. However, creating an access-control evaluation engine for a given access-control model from scratch is a complex and time-consuming task. As a consequence, we have decided to use an existing model transformation engine as off-the-shelf access-control evaluation engine as proposed in [21]. In the rest of this section, we describe how to map UCON policies to model transformation rules that will then be the input of the transformation engine for access-control evaluation. Similarly to model access-control policies, a model transformation function 𝑀𝑡 ∶ {𝑆𝑜𝑢𝑟𝑐𝑒𝑀𝑜𝑑𝑒𝑙}→{𝑇 𝑎𝑟𝑔𝑒𝑡𝑀𝑜𝑑𝑒𝑙}taking as an input a source model and producing a target model can be seen as composed by rules of the form: 𝑀𝑡𝑟𝑖 ∶ {𝑀𝑎𝑡𝑐ℎ ×𝐶𝑜𝑛𝑑𝑖𝑡𝑖𝑜𝑛𝑠}→{𝑂𝑢𝑡𝑝𝑢𝑡 × 𝐵𝑖𝑛𝑑𝑖𝑛𝑔𝑉 𝑎𝑙𝑢𝑒𝑠}where a Match is a source model element, Conditions are a set of guards that must hold for the rule to fire, Output is a target model element and BindingValues are initialization values. When the element to match and the element to produce for a rule are always of the same type (in our case, and as discussed next, of type Request and Decision respectively), this function can be simplified to be 𝑀𝑡𝑟𝑖 ∶ {𝐶𝑜𝑛𝑑𝑖𝑡𝑖𝑜𝑛𝑠}→{𝐵𝑖𝑛𝑑𝑖𝑛𝑔𝑉 𝑎𝑙𝑢𝑒𝑠}. If we make that BindingValues contain the values of an access decision (e.g., {accept, deny}), we have that the evaluation of access-control rules can be seen as a specific case of model transformation where input elements are always of the same type and the output model element contains a decision value. As model transformation frameworks are mature tools with a large amount of research and development work committed to them, they are ideally placed to take over the task of evaluating access-control policies as a special case of their natural range of use. As mentioned in Section 2.2, we use ATL as our model transformation framework of Table 2 UCON policy to ATL module translation. UCON policy ATL module UCON rule ATL rule (with predicate called in guards) Attributes Helpers with context Predicates Helpers PreUpdate procedures Helpers called inside the helper representing the attribute PostUpdate procedures Helpers called on the output pattern OnUpdate procedures Delegated to enforcement environment choice due to its maturity and tooling. Additionally, ATL uses OCL as its navigation and query language, which facilitates the translation of our UCON policies to ATL. Practically, the translation of UCON policies to ATL transformations follows the translations rules described in Table 2 (note that we reuse the simple Request and Decision metamodels defined in [21] to use them as input and output models of our transformation. To the decision metamodel, we add a list of updated values for attributes). OnUpdate procedures and the corresponding revocation of permissions are delegated to the enforcement environment that will update attributes when required and then re-run the model transformation to obtain a new access decision. An example of translation from a UCON policy to an ATL model transformation specification is provided in Listing 4. Listing 4shows the ATL translation corresponding to the rule introduced in Listing 2. Lines 1 to 8 show three helpers used to rectify the loanRequest attribute, calculate the predicate and calculate the update procedure respectively. Lines 11 to 23 show the ATL rule corresponding to the authorization rule 𝑝𝑟𝑒𝐴3. It matches a subject usage request (lines 12 to 13) only when the predicate preAuth3 is true. Once the rule matches the request, it creates an access decision (lines 14 to 23) as a target model element. This access decision contains a value in the set {true, false} (lines 15 and 16) and a list of new values to updated attributes (lines 17 to 21). Listing 4: ATL UCON Policy Excerpt 1helper context Request!Subject def :loanRequests :String = 2self.getRAttributeByName(’loanRequests’) .value; 3 4helper def :preAuth3(s:Request!Subject,o:Request!Object,r ↪:Request!Right) 5:Boolean =s.loanRequests.toInteger() < 3; 6 7helper def :postUpdate(s:Request!Subject,o:Request!Object) 8:String =s.loanRequests.toInteger() + 1; 9 10 11 nodefault rule LoanRequestAuth3{ 12 from 13 s:Request!UsageRequest (thisModule.preAuth3(s.subject,s ↪.object,s.right) ) 14 to 15 t:Decision!Decision( 16 value <−true, 17 updates <−update 18 ) , 19 update:Decision!Update(-- updated values are returned ↪with the decision 20 name <−’loanRequests’ , 21 newValue <−thisModule.postUpdate(s.subject,s.object) ↪.toString() 22 ) 23 } 4.2.1. A word on performance We have chosen to use model transformations as enabling technology for the checking of UCON policies to avoid building an UCON evaluation engine from scratch. This choice is key to facilitate the bridging between UCON and MDE but it is only adequate if the transformation engine is able to answer access requests fast, so that it does not constitutes a noticeable overhead. Note that the transformation engine evaluates access requests by executing the transformations derived Journal of Information Security and Applications 64 (2022) 103006 9 A.M. Reina Quintero et al. Table 3 Evaluation times for access-request. Rules 10 50 100 500 1000 5000 10,000 Time (s) 0.1165 0.152 0.2065 0.4002 0.5946 1.2193 1.99 from the input policies as described above. Therefore, the relevant time is the execution time, as access requests need to be executed every time a permission request is issued, not the time to generate the transformations as this takes place only once during the design process. In general, model transformation engines are very efficient as there has been plenty of research efforts in optimizing them using a variety of techniques. For instance, the performance of model transformation based policies was already studied in [21] with positive results (less than 1 s for access-control policies with more than 500 rules). However, the type of policies studied were different and arguably, less complex. Thus, we have designed and conducted a performance evaluation for ATL-based UCON policies.8For the evaluation, we evaluated an access request against policies (model transformations) of different sizes, with the number of contained rules ranging from 10 to 10,000. These policies are generated synthetically but using real and valid UCON rules as a base. Note that although single organizations with large number of users and resources having a single point of control may have many rules within a single policy, 10,000 rules is well above the normal values. As an example, the maximum policy size in existing performance evaluation works is of about four thousand [27] and one thousand [28] rules respectively. We summarizes the results of the performance evaluation in Table 3. As it can be seen, the performance of the ATL engine for the evaluation of UCON policies is good. Access requests against policies containing up to 100 rules are evaluated in a fifth of a second. Evaluation time increases linearly with the size of the policies with access request taking half a second for policies of 1000 rules. Very large policies containing more that 5000 rules take more than a second for access request evaluation. Note however that as mentioned before, such policies are not common. Therefore, we can conclude that model transformation engines are a feasible implementation strategy for UCON evaluation. 4.3. Policy enforcement Once we have the means to define access-control policies and to evaluate subject access-requests to resources, we are ready to plug our access-control framework to the system to be protected. In order to do so, and having already the policy definition separated from the main application, we could use a reference monitor [29] and a Policy Enforcement Point (PEP) - Policy Decision Point(PDP) architecture. In such architecture, the PEP will capture any requests for access, and then ask the PDP to yield a decision access before granting or denying the access. We left this integration step as further work, however, we provide a succinct description on the main run-time tasks and how they may be implemented in MDE: The PDP will be mainly composed of the model transformation engine coupled with the access-control policy encoded as a model transformation specification. The PEP will consist of catching the model access and edition operation and performing a call to the PDP before allowing the access. This can be done by extending the modeling framework as it is done in [30] where so-called reactive EObjects act in this manner. 8The evaluation tests were executed on a four core Intel(R) Core(TM) i7- 8650U CPU @ 1.90 GHz running Ubuntu 20.04.2 LTS. We used ATL 4.2.0 under Eclipse Modeling Tools Version: 2020-03 (4.15.0). Other run-time UCON operations may also take advantage of existing MDE facilities, such as the revoking of permissions when attributes change. Concretely, and w.r.t. our proposed framework, OCL predicates may be incrementally re-evaluated upon attribute’s value changes as described in [31]. 5. Related work UCON and access control models have been widely studied in the literature. We classify the related works in two main categories: approaches that integrate access control models in MDE environments (Section 5.1) and approaches to provide alternative implementations and adaptations of UCON to other technical spaces (Section 5.2). 5.1. Model-driven engineering and access control models There are a plethora of access control models that are used to implement security policies, as it can be seen in the taxonomy defined in [5]. In this context, different model-driven approaches have been used to raise the level of abstraction at which these policies are defined, especially aiming at their integration in software and system development projects. Pioneer approaches were [32] and [33]. They offer the possibility of modeling (role-based) access-control policies, but they use a rather simple access-control model and do not go beyond the specification phase, i.e. evaluation of policies is not covered. Regarding the modeling of security policies, several model-driven approaches focus on different, more expressive, Domain-Specific Languages to deal with the concepts of one or more access control models in different contexts [34]. In that sense, [35–38] propose access control metamodels for web service-oriented architectures, web content management systems, distributed environments, and enterprise architecture, respectively. There are also attempts to integrate the concepts managed by different access control models in a unique metamodel. An example of this approach is [39], which proposes a metamodel integrating RBAC with other access control principles (Chinese wall, Bell LaPadula and BIBA). More focused on correctness, in Fadhel et al. [25], the authors define semantic checks to detect conflicts and inconsistencies among the policies written in the GemRBAC-DSL specification, a language to write RBAC. Additionally, there are approaches in the model-driven arena that use general purpose languages such as UML and OCL to formalize different properties of access-control paradigms such as static and dynamic Separation of Duty (SoD) [26,40]. Finally, in [41] OCL is proposed to represent UCON constraints (or predicates). They do so directly in an implicit model that integrates a mixture of UCON concepts, system state and domain concepts. Instead, our approach provides an explicit and complete UCON support to facilitate the definition of any UCON-based policy in modeling environments. Regarding the enforcement of modeled security policies, [42] proposes an enforcement framework in which policies are written in GemRBAC-DSL, which allows the specification of RBAC policies. [43] uses UML and OCL to specify RBAC polices and implements PDP as a model-driven authorization engine in the context of web services. [44] presents an approach in which RBAC policies are written in a DSL defined as an extension of UML activity diagrams. These policies are then mapped to WS-BPEL specifications to be enforced at run-time. [21] defines an approach that can handle MAC, DAC, RBAC and ABAC policies and generates a PDP specification. Finally, [45] provides a general MDE-based PEP-PDP continuity-enhanced and configurable UCON enforcement engine. With it, they also provide a metamodel, but it is specialized for enforcement and, as a consequence, it is not fully aligned with the original UCON and it does not cover explicitly concepts such as subjects, objects or rights.