ArticlePDF Available

Abstract and Figures

Large-scale model-driven system engineering projects are carried out collaboratively. Engineering artefacts stored in model repositories are developed in either offline (checkout–modify–commit) or online (GoogleDoc-style) scenarios. Complex systems frequently integrate models and components developed by different teams, vendors and suppliers. Thus, confidentiality and integrity of design artefacts need to be protected in accordance with access control policies. We propose a secure collaborative modelling approach where fine-grained access control for models is strictly enforced by bidirectional model transformations. Collaborators obtain filtered local copies of the model containing only those model elements which they are allowed to read; write access control policies are checked on the server upon submitting model changes. We present a formal collaboration schema which provenly guarantees certain correctness constraints, and its adaption to online scenarios with on-the-fly change propagation and the integration into existing version control systems to support offline scenarios. The approach is illustrated, and its scalability is evaluated using a case study of the MONDO EU project.
This content is subject to copyright. Terms and conditions apply.
Softw Syst Model (2019) 18:1737–1769
https://doi.org/10.1007/s10270-017-0631-8
SPECIAL SECTION PAPER
Enforcing fine-grained access control for secure collaborative
modelling using bidirectional transformations
Csaba Debreceni1,2·Gábor Bergmann1,2·István Ráth1·Dániel Varró1,2,3
Received: 18 March 2017 / Revised: 27 September 2017 / Accepted: 5 November 2017 / Published online: 21 November 2017
© The Author(s) 2017. This article is an open access publication
Abstract Large-scale model-driven system engineering
projects are carried out collaboratively. Engineering arte-
facts stored in model repositories are developed in either
offline (checkout–modify–commit) or online (GoogleDoc-
style) scenarios. Complex systems frequently integrate mod-
els and components developed by different teams, vendors
and suppliers. Thus, confidentiality and integrity of design
artefacts need to be protected in accordance with access
control policies. We propose a secure collaborative mod-
elling approach where fine-grained access control for models
is strictly enforced by bidirectional model transformations.
Collaborators obtain filtered local copies of the model con-
taining only those model elements which they are allowed
to read; write access control policies are checked on the
server upon submitting model changes. We present a formal
Communicated by Dr. Jörg Kienzle and Alexander Pretschner.
The original version of this article was revised due to a retrospective
Open Access order.
BCsaba Debreceni
debreceni@mit.bme.hu
Gábor Bergmann
bergmann@mit.bme.hu
István Ráth
rath@mit.bme.hu
Dániel Varró
varro@mit.bme.hu
1Department of Measurement and Information Systems,
Budapest University of Technology and Economics, Magyar
tudósok krt. 2, Budapest 1117, Hungary
2MTA-BME Lendület Research Group on Cyber-Physical
Systems, Budapest, Hungary
3Department of Electrical and Computer Engineering, McGill
University, Montreal, Canada
collaboration schema which provenly guarantees certain cor-
rectness constraints, and its adaption to online scenarios with
on-the-fly change propagation and the integration into exist-
ing version control systems to support offline scenarios. The
approach is illustrated, and its scalability is evaluated using
a case study of the MONDO EU project.
Keywords Collaborative modelling ·Secured views ·
Access control ·Online collaboration ·Offline collaboration ·
Bidirectional model transformation
1 Introduction
1.1 Collaborative modelling in MDE
The adoption of model-driven engineering (MDE) by sys-
tem integrators (like airframers or car manufacturers) has
been steadily increasing in the recent years [55], since it
enables to detect design flaws early and generate various
artefacts (source code, documentation, configuration tables,
etc.) automatically from high-quality system models.
The use of models also intensifies collaboration between
distributed teams of different stakeholders (system integra-
tors, software engineers of component providers/suppliers,
hardware engineers, certification authorities, etc.) via model
repositories, which significantly enhances productivity and
reduces time to market. An emerging industrial practice of
system integrators is to outsource the development of various
design artefacts to subcontractors in an architecture-driven
supply chain.
Collaboration scenarios include traditional offline collab-
orations with asynchronous long transactions (i.e. to check
out an artefact from a version control system and commit
local changes afterwards) as well as online collaborations
123
Content courtesy of Springer Nature, terms of use apply. Rights reserved.
1738 C. Debreceni et al.
with short and synchronous transactions (e.g. when a group
of collaborators simultaneously edit a model, similarly to
well-known online document/spreadsheet editors). Several
collaborative modelling frameworks (like CDO [49], EMF-
Store [50]) exist to support such scenarios.
However, such collaborative scenarios introduce signifi-
cant challenges for security management in order to protect
the intellectual property rights (IPR) of different parties. For
instance, the detailed internal design of a specific compo-
nent needs to be hidden to competitors who might supply
a different component in the overall system, but needs to
be revealed to certification authorities in order to obtain air-
worthiness. Large research projects in the avionics domain
(like CESAR [12]orSAVI[1]) address certain collaborative
aspects of the design process (e.g. by assuming multiple sub-
contractors), but security aspects are restricted to that of the
system under design.
An increased level of collaboration in a model-driven
development process introduces additional confidentiality
challenges to sufficiently protect the IPR of the collabo-
rating parties, which are either overlooked or significantly
underestimated by existing initiatives. Even within a single
company, there are often teams with differentiated responsi-
bilities, areas of competence and clearances. Such processes
likewise demand confidentiality and integrity of certain mod-
elling artefacts.
1.2 Problems of coarse-grained access control
Existing practices for managing access control of models
rely primarily upon the access control features of the back-
end repository. Coarse-grained access control policies aim
to restrict access to the files that store models. For instance,
EMF models can be persisted as standard XMI documents,
which can be stored in repositories providing file-based
access and change management (as in SVN [2], CVS [24]).
Fine-grained access control policies, on the other hand, may
restrict access to the model on the row level (as in relational
databases) or triple level (as in RDF repositories). Unfortu-
nately, coarse-grained security policies are captured directly
on the storage (file) level often result in inflexible fragmen-
tation of models in collaborative scenarios.
To illustrate the problem of coarse-grained permissions,
let us consider two collaborators, SW Provider1and
HW Supplier1having full control over their model (frag-
ment). Now if HW Supplier1intends to share part of their
model with SW Provider1, then either they need to grant
access to the entire model (which would mean losing the
confidentiality of certain intellectual properties), or split their
model into two files and give access to only one fragment.
For each additional actor SW Provider2, the same argument
applies; in the end, a collaboratively developed system model
would end up being split into several fragments.
Fig. 1 Problem with file-level access control
Even in the simple case depicted in Fig. 1, the model
needs to be split into two files (Model Fragment1and
Model Fragment2) and access needs to be granted separately
for each file when a SW Provider1and a HW Supplier1col-
laborates. When a new collaborator, SW Provider2, joins in
the future who is allowed to partially read all two existing
fragments, each model fragment needs to be divided at least
in two. In this example, 5 fragments are required: one that can
be read by both SW Provider1SW Provider2, one accessi-
ble to HW Supplier2SW Provider2and three more private
model fragments for the three collaborators. If additional col-
laborators join the collaboration, the number of fragments has
to be increased further.
As a result, coarse-grained access control can lead to
significant model fragmentation, which greatly increases the
complexity of storage and access control management. In
industrial practice, automotive models may be split into more
than 1000 fragments, which poses a significant challenge
for tool developers. Some model persistence technologies
(such as EMF’s default XMI serialization) do not allow model
fragments to cyclically refer to each other, putting a stricter
limit to fragmentation. Hence, MDE use cases often demand
the ability to define access for each object (or even each
property of each object) independently.
Furthermore, coarse-grained access control lacks flexibil-
ity, especially when accessing models from heterogeneous
information sources in different collaboration scenarios. For
instance, they disallow type-specific access control, i.e. to
grant or restrict access to model elements of a specific type
(e.g. to all classes in a UML model), which are stored in
multiple files.
On the other hand, fine-grained access control necessi-
tates to assign access rights to each model element.Asthe
size of the model grows, these permissions or restrictions can-
not be set and maintained manually for each individual model
element, but a systematic assignment technique is needed.
1.3 Goals
The main objective of the paper is to achieve secure collab-
orative modelling with fine-grained access control, by using
123
Content courtesy of Springer Nature, terms of use apply. Rights reserved.
Enforcing fine-grained access control for secure collaborative modelling using bidirectional… 1739
advanced model transformation techniques, while relying
upon existing storage back ends to follow current industrial
best practices. In particular, we aim to address the following
high-level goals (refined later into technical goals in Sect. 2):
G1 Fine-grained Access Control Management
to enforce read and write permissions of users separately
to each model object, attribute or reference.
G2 Secure and Versatile Offline Collaboration
where each collaborator can work with a model frag-
ment filtered in accordance with read permissions and
processed using off-the-shelf MDE tools (e.g. editor,
verifier). A user may be disconnected from any server
or access control mechanism and then submit (commit)
his updated version in the end.
G3 Secure and Efficient Online Collaboration
where multiple users can view and edit a model hosted
on a server repository in real time while imposing
different read and write permissions. Small changes per-
formed by one collaborator are quickly and efficiently
propagated to the views visible to other users, without
reinterpreting the entire model.
G4 General Collaboration Schema
that is adaptable for online and offline scenario defining
workflows of a server and multiple clients to handle
fine-grained access control management.
1.4 Contributions
In this paper, we define an approach for secure collabora-
tive modelling using bidirectional model transformations to
derive filtered secure views for each collaborator and to prop-
agate changes introduced into these views back to a server.
Our approach is uniformly applicable to support both online
and offline collaboration scenarios, and it enforces fine-
grained access control policies for each collaborator during
the derivation of views and the back-propagation of changes.
We formalize the collaboration schema using communi-
cating state machines and provide formal proofs for certain
correctness criteria using the FDR4 tool [30]. The schema
is integrated into existing version control systems using hook
programs triggered by repository events to support offline
collaborative scenarios, whereas a prototype tool of online
collaboration is also realized on the top of Eclipse RAP [51].
Finally, a detailed scalability evaluation is carried out
using models from the Wind Turbine Case Study of the
MONDO European FP7 project, which serves as a motivat-
ing example for the paper.
This paper is an extension of [8,18] by providing (1) an
in-depth precise specification of the bidirectional transforma-
tion as well as the collaboration scheme, (2) further technical
details on its realization for both offline and online collabo-
Fig. 2 Simplified metamodel of wind turbine controllers
rative scenarios and (3) an extended scalability evaluation of
our approach now also covering the offline scenario.
1.5 Structure
Rest of the paper is organized as follows. Our motivating
example is detailed, and the challenges are introduced in
Sect. 2. Section 3defines how models can be decomposed
into individual assets and introduces the rules that assign read
and write permissions to assets. In Sect. 4, we overview our
bidirectional model transformation for access control, while
Sect. 5describes our secure collaboration schema and proves
its correctness. In Sect. 6, we give a brief overview on how
to adapt this collaborative modelling schema to online and
offline scenarios. Section 7describes the evaluation of our
approach, and related work is overviewed in Sect. 8. Finally,
Sect. 9concludes our paper.
2 Case study
2.1 Modelling language
Our approach will be illustrated using a simplified version
of a modelling language for system integrators of offshore
wind turbine controllers, which served as one of the case
studies of the MONDO EU FP7 project [4]. The metamodel,
defined in Ecore [52] and depicted in Fig. 2, describes how
the system builds up from modules (Module) providing and
consuming signals (Signal) that send messages after a spe-
cific amount of time defined by the frequency attribute.
Modules are organized in a containment hierarchy of com-
posite modules (Composite) shipped by external vendors
(vendor attribute), and ultimately containing control unit
modules (Control) responsible for a given type of physical
device (such as pumps, heaters or fans: FanControl,Heater-
Control,PumpControl, respectively) with specific cycle
priorities (cycle attribute). A documentation is attached to
each signal (documentation attribute) to clarify its respon-
123
Content courtesy of Springer Nature, terms of use apply. Rights reserved.
1740 C. Debreceni et al.
Fig. 3 Sample wind turbine instance model
sibilities. Some of the signals are treated as confidential
intellectual property (ConfidentialSignal).
The design of wind turbine control units requires special-
ized knowledge. There are three kinds of control units, and
each kind can only be modified by specialist users with the
appropriate qualification: fan,heater and pump control engi-
neers.
A sample instance model containing a hierarchy of 3
Composite modules with 4 Control units as submod-
ules, providing 6 Signals altogether where two of them
are Confidential Signals, is shown in Fig. 3. Boxes
represent objects (with attribute values as entries within the
box and their types shown as labels on the tops). Arrows
with diamonds represent containment edges, while arrows
without diamonds represent cross-references.
2.2 Security requirements
Specialists are not allowed to modify (and in some cases,
read) parts of the model. For this purpose, the following secu-
rity requirements are stated for control unit specialists:
R1 Each group of specialists shall be responsible for a spe-
cific kind of control unit (owned control units).
R2 Specialists shall see only those signals that are within
the scope for their owned control units, i.e. signals pro-
vided by a module that is either (a) a composite that
directly contains an owned control unit, or (b) any sub-
module (including the owned control unit) contained
transitively in such a composite.
R3 Specialists shall be able to modify signals provided by
their owned control units.
R4 Specialists shall observe which modules consume sig-
nals provided by their owned control units.
R5 Specialists shall see the vendor attributes in an obfus-
cated form.
R6 Specialists must not see confidential signals.
2.3 Usage scenarios
The system integrator company is hosting the wind turbine
control model on their collaboration server, where it is stored,
versioned, etc. There are two ways for users to interact with
it.
Online collaboration. A group of users may participate in
online collaboration, when they are continuously connected
to the central repository via an appropriate client (e.g. web
browser). Each user sees a live view of those parts of the
model that he is allowed to access. Changes need to be
propagated on-the-fly between the views of users in short
transactions. These transactions contain each modification
such as create, update, delete or move. Finally, the collabo-
ration tool has to reject a modification immediately when it
violates a security requirement.
The users can modify the model through their client, which
will directly forward the change to the collaboration server.
The server will decide whether the change is permitted under
write access restrictions. If it is allowed, then the views of all
connected users will be updated transparently and immedi-
ately, though the change may be filtered for them according
to their read privileges.
Offline collaboration. In case of offline collaboration, when
connecting to the server, each user can download a model file
containing those model elements that he is allowed to see.
The user can then view, process, and modify his downloaded
model file locally. The model can be developed with unmodi-
fied off-the-shelf tool that need not be aware of collaboration
and access control. After the modification, the changes will
be uploaded to the server in a long transaction.
2.4 Challenges
Deriving from the goals stated in Sect. 1.3, we identify the
following challenges.
C1 Fine-grained Access Control of Model Artefacts.
To meet G1, the approach must enforce to allow or
deny model access separately for individual model
elements.
C2.1 Model Compatibility.
To meet G2 in offline collaboration scenario, the
approach must be able to present the information
available to a given user as a self-contained model,
in a format that can be stored, processed, displayed
and edited by off-the-shelf modelling tools.
123
Content courtesy of Springer Nature, terms of use apply. Rights reserved.
Enforcing fine-grained access control for secure collaborative modelling using bidirectional… 1741
C2.2 Offline Models.
To meet G2 in an offline collaboration scenario, the
approach must be able to present only the avail-
able information to a given user without maintaining
connectivity with any central server or authority
responsible for access control.
C3.1 Incrementality.
To meet G3 in an online collaboration scenario, the
approach must be able to process model modifica-
tions initiated by a user and apply the consequences
to the views available to other users without re-
processing the unchanged parts of the model.
C4.1 Correctness Criteria.
To meet G4, the approach must define the correct-
ness criteria of the collaboration schema and prove
their fulfilment.
C4.2 Adaptability.
To meet G4, the approach must realize the collabo-
ration schema both in offline and online scenarios.
3 Access control of models
3.1 Modelling preliminaries
In order to tackle challenges C1.1 and C2.1, we first analyse
how models can be decomposed into individual assets for
which access can be permitted and denied, and under what
conditions a filtered set of such assets can be represented as
a model that can be processed by standard tools.
For the purposes of access control, a model is conceived
as a set of elementary model assets.AnAsset is an entity that
the access control policy will protect. Generally, models can
be decomposed into object, reference and attribute assets.
Definition 1 Object assets are pairs formed of a model ele-
ment with its exact class for each model element object;
ObjectAsset =object,type
Definition 2 Reference assets are triples formed of a source
object, a reference and the referenced target object, for each
containment link and cross-link between objects;
ReferenceAsset =objects,reference,objectt
Definition 3 Attribute assets are triples formed of a source
object, an attribute and a data value, for each (non-default)
attribute value assignment;
AttributeAsset =object,attribute,value
Definition 4 Models are triples formed of a set of object,
reference and attribute assets.
M={ObjectAssset},{ReferenceAsset},{AttributeAsset}
Note that there can be multi-valued attributes and ref-
erences in certain modelling platforms (e.g. EMF), where
an object is allowed to host multiple attribute values (or
reference endpoints) for that property. For such properties,
each entry at a source object will be represented by separate
attribute (or reference) assets.
Example 1 ObjectAsset(o1,Composite)is an object asset,
AttributeAsset(o10,cycle,low)is an attribute asset and
ReferenceAsset(o2,consumes,o12)is a reference asset in
our running example (depicted in Fig. 3).
3.2 Consistency of models
An arbitrary set of model assets does not necessarily consti-
tute a valid model; there may be consistency rules imposed
on the assets by the modelling platform to ensure the integrity
of the model representation and the ability to persist, read and
traverse models. Challenge C2.1 requires that filtered models
must be synthesized as a set of model assets compatible with
all consistency rules of the underlying modelling platform.
Object Existence. Attributes and references imply that
the objects involved exist, having a type compatible with
the type of the attribute or reference.
Containment Hierarchy. In modelling languages that
have a notion of containment, certain references are
denoted as containment types realizing a containment
hierarchy of objects. This hierarchy implies a contain-
ment forest of all objects. Therefore, objects must either
be root objects of the model, or be transitively contained
by a root object via a chain of objects that are all existing.
(Modelling languages that do not have containment are
of course also supported, with all objects considered root
objects.)
Opposite Features. There are opposite references defined
as a pair of references where the existence of a relation
depends on its pair. For reference types having an oppo-
site, reference assets of the two types exist in symmetric
pairs.
Multiplicity Constraints. The number of reference assets
for a given reference of an object needs to satisfy the
multiplicity constraints.
We distinguish these low-level internal consistency rules
from high-level, language-specific well-formedness con-
straints. Well-formedness constraints (also known as design
rules or consistency rules) define additional restrictions to the
metamodel that the instance models need to satisfy. These
types of constraints are often described using OCL [40]. The
difference between the two concepts is that violating the lat-
123
Content courtesy of Springer Nature, terms of use apply. Rights reserved.
1742 C. Debreceni et al.
ter kind does not prevent a model from being processed and
stored in a given modelling technology. Thus, only internal
consistency is required for access control.
3.3 Model obfuscation
Obfuscation is defined as the process of “making something
less clear and harder to understand, especially intention-
ally” [48]. The first purpose of obfuscation in programming
was to distribute C sources in an encrypted way to prevent
access to confidential intellectual property in the code [33].
A model obfuscation takes a model as input and yields
another model as output where the structure of the model
remains the same but data values (such as names, identifiers
or other strings) are altered. Two data values that were iden-
tical before the obfuscation will also be identical after it, but
the obfuscated value computed based on a different input
string will be completely different. Moreover, all the altered
values can be reverted by the original owner of the model
using a private key.
In the context of access control, obfuscation can be applied
to data values of attribute assets. An obfuscated data describe
its presence in the model (e.g. the value of an object’s attribute
is not empty), but the real content of that asset remains hid-
den.
Definition 5 The obf function takes a data Val ue and a Seed
as inputs and maps the value to (
Val u e ). The Obf 1function
is the inverse of obf which returns the original data if the same
Seed is used.
obf :: (Val u e ,Seed)
Val u e
obf1:: (
Va l u e ,Seed)Val u e
Example 2 In our example, the security requirement R5 pre-
scribes to obfuscate the vendor attribute Aof object root that
may become “oA3DD43CF5” in the views.
3.4 Access control rules and permissions
Our fine-grained access control policy has to assign permis-
sions separately for each model asset. In case of a large
model, there can be thousands of assets where it is tedious
to manually assign permissions one by one. Therefore, the
policies are constructed from a list of access control rules,
each of which controls the access to a selected set of model
assets by certain users or groups, and may either allow or
deny the read and/or write operation.
Definition 6 An access control rule (ac-rule) defines a par-
tial function that applies judgements (allow, obfuscate, deny)
to specify the privileges of a certain user Users for an oper-
ation type (read or write) on a given subset of assets.
let Op =[read,write]
let Judgement =[allow, obfuscate, deny]
ac-rule :: Assets ×Op ×Users Judgement
Definition 7 An access control policy defines an effective
permission function (permissionEff) derived from a list of
access control rules that applies judgements (allow, obfus-
cate, deny) for both operation types (read and write) of each
assets in the context of a certain user Users
permissionEff :: Asset ×Op ×Users Judgement
To manage the challenge C2.1, it is necessary to elimi-
nate inconsistencies introduced by access control rules.In
addition, these access control rules can be contradictory
as one access control rule might grant a permission for a
given part of the model, while another rule may deny it
at the same time. Hence, the effective permission function
(permissionEff) needs to derive a consistent and conflict-
free set of judgements. Our previous work [9,18] describes
the effective permission calculation in more detail, but here
we give a brief overview on conflict resolution, permission
dependencies and outline some reconciliation strategies as
well.
Conflicts. Conflicting policy rules can be resolved by assign-
ing priorities to each rule. Hence, the rules with higher
priority override the other rules.
Sanity. The sanity of the policy implies that a user should
not be allowed to write values and model assets that are not
readable to them. Therefore without effective read permis-
sion, write permission is automatically denied as well, even
if there are no rules to deny the write permissions.
Read dependencies. Read permissions may depend on per-
missions on other model assets.
If a model element is unreadable, its incoming and outgo-
ing references and its attributes shall not be readable either,
otherwise the set of readable assets would not form a self-
consistent model.
In modelling platforms (such as EMF) with a notion of
containment between objects, readable objects cannot be
contained in unreadable objects (as the latter do not exist
in the front model); this needs to introduce a new container
for the orphan object (e.g. promoting it to a top-level object of
the model). Alternatively, this implies that an object hidden
from the front model will hide the entire containment subtree
rooted there (this latter choice is used in the case study).
123
Content courtesy of Springer Nature, terms of use apply. Rights reserved.
Enforcing fine-grained access control for secure collaborative modelling using bidirectional… 1743
Write dependencies. Write permissions likewise have depen-
dencies on other model assets.
In general, creating/modifying/removing references
between objects requires a writable source object and a read-
able target object, but some modelling platforms including
EMF have bidirectional references (or opposites), for which
internal consistency dictates that the target object must be
writable as well.
A metamodel may constrain a reference (or attribute) to be
single-valued; assigning a new target to the reference would
automatically remove the old one, so a user can only be
allowed the former write operation if they are allowed the
latter.
Similarly, removing an object from the model implies
removing all references pointing to it, and all objects con-
tained within it.
Example 3 An access control policy is set up to meet the
security needs of the running example introduced in Sect. 2.2.
A possible permission function (permissionEff) is visualized
in Fig. 4. For instance, Pump Control Engineershavefull
access to PumpControl objects and their provided Signals
(squares marked with bold borders and blue headers); how-
ever, they cannot access ConfidentialSignal objects (squares
with dashed borders). The rest of the objects are readable, but
not writable by this group of users (squares with thick borders
and orange headers). If an object is only required to pre-
serve read dependencies, its identifier is obfuscated (marked
with “O” letter in a square next to the attribute) and all other
attributes remain hidden (“H” letter in the square). Finally,
bold edges are writable by the engineers, i.e. the writable sig-
nals (s2,s5) can be removed from their container, or new
signals can be created under the writable controls (ctrl2,
ctrl4); thick edges represent readable references (in this
example, these are required mostly to preserve containment
hierarchy); and the rest of the dashed edges are hidden from
the engineers.
4 Bidirectional model transformation for access
control management
4.1 The access control lens
Due to read access control, some users are not allowed to
learn certain model assets. This means that the complete
model (which we will refer to as the gold model) differs
from the view of the complete model that is exposed to a
particular user (the front model).
In theory, access control could be implemented without
manifesting the front model, by hiding the entire gold model
behind a model access layer that is aware of the security
policy and enforces access control rules upon each read
(a)
(b)
(c)
Fig. 4 Effective permissions of the example, afan control engineer, b
heater control engineer, cpump control engineer
123
Content courtesy of Springer Nature, terms of use apply. Rights reserved.
1744 C. Debreceni et al.
and write operation performed by the user. However, chal-
lenge C2.1 requires users to access their front models using
standard modelling tools; moreover, while challenge C2.2
requires that in the offline collaboration scenario, they can
“take home” their front model files without being directly
connected to the gold model. In order to meet these goals,
we propose to manifest the front models of users as regu-
lar stand-alone models, derived from a corresponding gold
model by applying a bidirectional model transformation.
In the literature of bidirectional transformations [21], a
lens (or view update) is defined as an asymmetric bidirec-
tional transformation relation where a source knowledge base
(KB) completely determines a derived (view) KB, while the
latter may not contain all information contained in the for-
mer, but it can still be updated directly. The two operations
of crucial importance in realizing a lens relationship are the
following:
Get obtains the derived KB from the source KB that
completely determines it, and
PutBack updates the source KB, based on the derived
view and the previous version of the source (the latter is
required as the derived view may not contain all infor-
mation).
The bidirectional transformation relations between a gold
model (containing all assets) and a front model (containing
a filtered view) satisfies the definition of a lens. The Get
process applies the access control policy for filtering the gold
model into the front model. The PutBack process takes a
front model updated by the user and transfers the changes
back into the gold model.
Definition 8 The Get process derives the front model from
the gold model in accordance with the read permissions.
Get :: (MG,permissionEff)MF
Definition 9 The PutBack process enforces the write per-
missions and derives the updated gold model from the
modified front model and the original version of the gold
model.
PutBack :: (M
F,MG,permissionEff)M
G
The lens concept is illustrated in Fig. 5. Initially, the Get
operation is carried out to obtain the front model for a given
user from the gold model. Due to the read access control
rules, some objects in the model may be hidden (along with
their connections to other objects); additionally, some con-
nections between otherwise readable objects may be hidden
as well; finally, some attribute values of readable objects
may be omitted, obfuscated or hidden altogether. If the user
Fig. 5 Secure access control by bidirectional lenses
subsequently updates the front model, the PutBack opera-
tion checks whether these modifications were allowed by the
write access control rules. If yes, the changes are propagated
back to the gold model, keeping those model elements that
were hidden from the user intact (preserved from the previous
version of the gold model).
Write access control checks are performed by the Put-
Back operation as they (a) may prevent a user from writing
to the model, and (b) access control rules need to be evaluated
on the gold model.
Access control rules cannot be evaluated directly on the
front model since only the gold model contains all infor-
mation. Thus, write access control can only be enforced by
taking into account the gold model as well. Therefore, write
access control must be combined with the lens transforma-
tion. In particular, PutBack must check write permissions,
and fail (by rolling back any effects of the commit or oper-
ation) if a certain modification cannot be applied to the gold
model.
Example 4 In our running example, the original model
(Fig. 3) acts as the gold model containing all the informa-
tion. The Get transformation applies the permissions and
produces a front model for each specialist. In Fig. 4, each
front model consists of
the objects with bold or solid borders;
the references with solid lines;
but the objects and references with dashed borders and
lines are removed, whereas the attributes marked with
an “O” in a square are obfuscated;
an “H” in a square are removed.
When a PumpControlEngineer tries to modify the frequency
of the signal s3 from 6 to 10, the PutBack operation is
responsible for declining this change as the access control
rules deny the modification (the signal s3 is readable but not
writable).
123
Content courtesy of Springer Nature, terms of use apply. Rights reserved.
Enforcing fine-grained access control for secure collaborative modelling using bidirectional… 1745
On the other hand, if a PumpControlEngineer tries to mod-
ify the frequency of the signal s2 from 29 to 17, the PutBack
operation propagates the change back to the gold model (the
signal s2 is writable) by identifying the signal s2 in the gold
model and setting its frequency attribute.
4.2 Transformation design
Both Get and PutBack are designed as rule-based model
transformations [16]. In the terminology of model transfor-
mation, gold and front models act as the source and target
models, respectively.
To address challenge C3.1, the transformations need to be
reactive and incremental computations in the online collab-
oration scenario.
Reactive transformations [7] follow an event-driven
behaviour where the events are triggered by model manipula-
tions such as creation/modification/deletion of model assets.
The transformation observes these events and reacts to them.
Incrementality [16] means that there is no need to re-
execute the whole transformation upon a small change
introduced into the model. Source incrementality is the prop-
erty of a transformation that only re-evaluates the modified
parts of the source model. Target incrementality means that
only the necessary parts of the target model are modified by
the transformation, and there is no need to recreate the new
target model from scratch.
Definition 10 A transformation rule rule is associated with
aprecondition Preconditions,anaction Actions
(parametrized by a match of the precondition) and a numer-
ical priority Pvalue.
rule =(precondition,action,P)
Definition 11 A transformation Tconsists of a set of trans-
formation rules ({rule1,rule2...rulen}) that a transformation
engine TEexecutes to incrementally derive an updated target
model M
Tfrom a source and target model MS,MT.
T={rule1,rule2...rulen}
TE:: (MS,T,MT)M
T
Transformation execution repeatedly fires the rules as fol-
lows:
1. finds all the matches of rule preconditions of all rules (this
set of matches is efficiently and incrementally maintained
during the transformation),
2. selects a match from the rule with the highest priority,
3. executes the action of the rule along that match;
The loop terminates when there are no more precondition
matches.
According to the process Get and PutBack of the lens,
we define TGet and TPutBack transformations, respectively.
These transformations consist of four groups of transfor-
mation rules based on its direction (Get,PutBack) and
whether it adds or removes assets from the model (additive,
subtractive):
In case of Get process:
Additive adds assets to MFif no corresponding assets are
present in MG
Subtractive removes assets from MFif no corresponding
assets are present in MG
In case of PutBack process:
Additive adds assets to MGif no corresponding assets are
present in MF
Subtractive removes assets from MGif no corresponding
assets are present in MF
All four groups consist of one rule for each kind of model
asset; in the context of this paper, we distinguish 3 kinds of
model assets (see Sect. 3.1); this makes twelve transforma-
tion rules altogether, described in the tables of “Appendices A
and B”.
The preconditions require to initialize correspondence
between front and gold models. For that purpose, we intro-
duce a trace function.
Definition 12 The trace function is responsible for associat-
ing two object assets with each other:
trace :: (ObjectAsset(oG,t)) ObjectAsset(oF,t)
We select three example transformation rules listed in
Table 1to describe the key concept of how the access control
is managed.
Additive Get Object rule
(ruleAdditive Get Object)
The additive rule of TGet related to object assets is respon-
sible for propagating object addition from the gold model
MGto the front model MF. A change is recognized in the
precondition which selects pairs of ObjectAsset(oG,t)and
ObjectAsset(oF,t)as follows: an ObjectAsset(oG,t)in the
gold model that has no corresponding ObjectAsset(oF,t)
in the front model, but it should be readable according
to the permissionEff. The action part will create a new
ObjectAsset(oF,t)and establish a correspondence relation
between these two objects.
Example 5 Asystem administrator who has access to the
original gold model (depicted in Fig. 3) adds a new signal
object sNGunder the heater control unit ctrl3. This change
123
Content courtesy of Springer Nature, terms of use apply. Rights reserved.
1746 C. Debreceni et al.
Tabl e 1 Additive Get and Subtractive PutBack rules
rule Additive Get Object Priority 4
Precondition :: (MG(OAG,RAG,AAG), MF(OA F,RAF,AAF), permi ssi onEff)→{ObjectAsset}2
{ObjectAsset(oG,t), ObjectAsset(oF,t)|ObjectAsset(oG,t)OAG,permissionEff (ObjectAsset(oG,t), read)= deny,
ObjectAsset(oF,t)OA F:trace(ObjectAsset(oG,t)) =ObjectAsset(oF,t), t=t}
Action
OAF:= OAF∪{ObjectAsset(oF,t)},trace(ObjectAsset(oG,t)) := ObjectAsset(oF,t)
rule Additive Get Attribute Priority 5
Precondition :: (MG(OAG,RAG,AAG), MF(OA F,RAF,AAF), permi ssi onEff)→{AttributeAsset}
{AttributeAsset(oF,attr,v
)|AttributeAsset(oG,attr,v)AA G,permissionEff(AttributeAsset(oG,attr,v),read)= deny,
ObjectAsset(oF,t):ObjectAsset(oF,t)AAF,trace(ObjectAsset(oG,t)) =ObjectAsset(oF,t), AttributeAsset(oF,attr,v
):
v=v, permissionEff(AttributeAsset(oG,attr,v),read)=allow
obf (v ), permissionEff(AttributeAsset(oG,attr,v),read)=ob f uscat e ,AttributeAsset(oF,attr,v
)AAF}
Action
AAF:= AA F∪{AttributeAsset(oF,attr,v
)}
rule Subtractive PutBack Object Priority 3
Precondition :: (MG(OAG,RAG,AAG), MF(OA F,RAF,AAF), permi ssi onEff)→{ObjectAsset}
{ObjectAsset(oG,t)|ObjectAsset(oG,t)OAG,permissionEff (ObjectAsset(oG,t), read)= deny,
ObjectAsset(oF,t):trace(ObjectAsset(oG,t)) =ObjectAsset(oF,t), t=t}
Action
If permi ssi onEff(ObjectAsset(oG,type), write)= deny then
OAG:= OA G\ObjectAsset(oG,t), trace\ObjectAsset(oG,t)|trace(ObjectAsset(oG,t)) =ObjectAsset(oF,t)else
needs to be propagated to the front models as the new signal
should be at least readable (also writable for Heater Control
Engineers).
TGet transformation will be executed between MGand
the front model of Pump Control Engineer Mpump
F(depicted
in Fig. 4c). The precondition of the ruleAdditive Get Object
selects the ObjectAsset(sNG,Signal)as it has no corre-
sponding ObjectAsset(sNF,Signal)in the front model. The
action part creates ObjectAsset(sNF,Signal)and traces
it back to ObjectAsset(sNG,Signal). Exactly the same
sequence happens in case of the front model of Fan Con-
trol Engineer M fanF(depicted in Fig. 4a).1
Additive Get Attribute rule
(ruleAdditive Get Attribute)
The additive rule of TGet related to attribute assets is
responsible for propagating data value insertion on the gold
model MGto the front model MF. The precondition of the
ruleAdditive Get Attribute selects AttributeAsset(oG,attr,v)
in the gold model that has no corresponding Attribute
Asset(oF,attr,v
)in the front model, but it should be read-
able according to the permissionEff.Thevalueofvis
calculated in accordance with its read permission (potentially
in an obfuscated form).
1ruleAdditive Get Reference takes care of the containment reference
between sNGand ctr l3.
Example 6 The system administrator modifies the frequency
attribute of s1Gfrom 30 to 15. This change needs to be prop-
agated to the front models.
1) TGet will be executed between MGand the front model of
Pump Control Engineer Mpump
F(depicted in Fig. 4c). The
precondition of the ruleAdditive Get Attribute selects the
s1Fobject from the front model attribute frequency
and value 15 as AttributeAsset(s1F,frequency,15)
does not exist, but it should be readable in Fpump.The
action part adds the AttributeAsset(s1F,frequency,15)
to Mpump
F.2
2) TGet will be executed between MGand the front model
of Fan Control Engineer Mfan
F(depicted in Fig. 4a). But
now, the precondition has no match as s1 is not readable
inMfan
F
Subtractive PutBack Object
(ruleSubtractive PutBack object)
The subtractive rule of TPutBack related to object assets
is responsible for propagating object asset removals from
the front model MFto the gold model MG. A deletion
2Similarly, ruleSubtractive Get Attribute will handle the removal of the
previous attribute asset AttributeAsset(s1F,frequency,30)before the
addition.
123
Content courtesy of Springer Nature, terms of use apply. Rights reserved.
Enforcing fine-grained access control for secure collaborative modelling using bidirectional… 1747
is recognized in the precondition as follows: there is an
ObjectAsset(oG,t)in the gold model that has no correspond-
ing ObjectAsset(oF,t)in the front model. The action part
checks the write permissions of ObjectAsset(oG,t).Ifthe
removal of the asset is denied, TPutBack terminates after a
rollback. Otherwise, it removes the selected object asset.
Example 7 APump Control Engineer removes ctrl1Fobject
from his front model Mpump
F(depicted in Fig. 4c). This change
needs to be propagated be to the gold model; thus, Put-
Back transformation will be executed between Mpump
Fand
the gold model MG(depicted in Fig. 4c). The precondition
of the rule selects ObjectAsset(ctr l1G,FanControl).Inthe
action part, the rule realizes that the permissions do not allow
to delete ctr l1 object; thus, the transformation terminates and
rejects the change.
To sum up, Get is responsible for enforcing read permis-
sions in front models, while PutBack takes care of write
permissions. If any write permission is violated, the trans-
formation terminates and the front model (target)isreverted
to its original state.
4.3 Discussion and analysis
In the following paragraphs, we analyse and discuss proper-
ties of the lens transformations.
First, in Sect. 4.3.1, we state the properties that the lens
transformations are expected to exhibit. In Sect. 4.3.2,we
state and discuss an important assumption that will be vital
to proving the aforementioned properties in “Appendix C”.
Finally, in Sect. 4.3.3 we will turn our attention to deviations
of the technical realization from the ideal formulation.
4.3.1 Desirable properties of the transformation
In the following, we present a number of properties that the
lens transformations would be desirable to exhibit. We first
state these desirable properties and then discuss them indi-
vidually in subsequent sections to find which ones are met
under which conditions by the presented transformations.
Transformation Property 1 (Termination) Given a pair
of starting models, Get and PutBack shall both terminate
after a finite number of rule executions.
Transformation Property 2 (Confluence) Given a pair of
starting models and running the transformation to comple-
tion, the terminal state of both Get and PutBack shall be
independent from the chosen execution order of rule appli-
cation, i.e. both Get and PutBack define a deterministic
function.
Transformation Property 3 (Confidentiality) Get shall
yield a front model that contains exactly those assets that
are visible according to effective read permissions.
Transformation Property 4 (Integrity) PutBack shall su-
ccessfully accept a modified front model if and only if its
differences from the original front model do not violate effec-
tive write permissions.
Transformation Property 5 (GetPut) PutBack shall be a
no-op when applied on the front model directly returned by
Get, i.e. if the user makes no changes, the gold model shall
not be updated.
Transformation Property 6 (PutGet) Get shall be a no-
op when applied on the gold model previously updated by
a successful PutBack (from the same front), i.e. if the gold
model has not changed, the front model shall not be updated.
Transformation Property 7 (PutPut) A user applying a
sequence of successful PutBack operations (and changing
the front model inbetween) should have the same ultimate
effect on the gold model as applying only the last one.
The first few properties (Properties 1,2) are generally
expected of most rule-based model transformations, in order
to define an actual deterministic transformation function.
Then Properties 3and 4state the security-specific require-
ments.
Next, Properties 5and 6pertain specifically to bidirec-
tional transformations and are widely promoted (see e.g. [21,
46], also [25] specifically for security views) as very impor-
tant “well-behavedness” properties that users of bidirectional
transformations would most certainly expect. They enable
the lens transformations to truly realize an updateable view.
Finally, Property 7provides even stronger predictability
guarantees, but is often considered very restrictive and there-
fore optional in the literature. A benefit of this law is that
user modifications are undoable, i.e. the original state of the
system (incl. gold model) can be restored when a change to
the from model is reverted. On the other hand, it might unfor-
tunately disallow certain sensible extensions, an example for
which we include below.
As introduced in [9], a possible sample refinement of the
write permission levels could be {deny <dangle <allow}.
Cross-references with write permission level dangle cannot
be normally modified by the user, but they can be removed
as the side effect of deleting the source or target object of
the reference (if that deletion is permitted). Unlike the usual
allowed write permission, dangle does not imply the read-
ability of the asset, so this kind of deletion is possible even
if the cross-link is not visible to the user. Imagine a trace-
ability link that points from a hidden part of the model to
a visible object; the difference between assigning deny or
dangle is that the target object cannot be deleted by the
user in the former case, while its deletion would be allowed
(with an invisible side effect of removing the traceability
link) in the latter case. These dangle semantics can be sim-
ilarly extended to attributes or contained objects that might
123
Content courtesy of Springer Nature, terms of use apply. Rights reserved.
1748 C. Debreceni et al.
be attached as (invisible or read-only) tags to objects; they
must not be modified by the user, but will be removed along
with the object they are attached to if the object is deleted. It
is easy to see that (a) such a feature would be quite useful in
many practical applications of the approach presented in the
paper, yet (b) Property 7will not hold, as undoability is lost
when dangling links/attributes/objects are removed.
4.3.2 Regularity of policy
Constant complement [5], a common strategy for proving
desirable properties of secure views, involves partitioning
the data into a readable part and the so-called complement.
This partitioning can be used, for example, to verify whether
PutBack (translator in the terminology of [5]) may possibly
change the complement (which would violate Property 7).
Similarly, correctness proofs can benefit from applying a sec-
ond kind of partitioning [25] into a writable and endorsed part
of the model.
Unfortunately, these partitioning schemes do not apply
perfectly to our approach for the simple reason that a single
asset might move from one partition to another as the model
evolves—in fact even during the execution of PutBack.This
is due to the fact that our approach is more powerful: we do
not consider explicit access control attributes of assets, but
rather derive effective permissions from policy rules based
on arbitrary model queries (over the gold model) that can take
into account the wider context of assets; thus, it is possible
to change the effective permissions for a given asset (even
without directly changing the asset itself). Therefore, we first
make the following assumption and then discuss violating
cases separately:
Assumption 1 (Regularity) For any transformation run,
there exists a constant permission set for all assets (i.e. a
constant partitioning of assets based on permission levels)
so that effective permissions will always evaluate to results
consistent with this fixed permission set when they are eval-
uated during the run (i) as a condition excluding activations
of higher-priority rules, or (ii) as a precondition to an indi-
vidual rule to be executed, when higher-priority rules have
already been found to have no matches, (iii) as a condition
for rejecting disallowed write attempts, or (iv) to determine
termination.
Note that Assumption 1does not require that the actual
effective permissions (as evaluated following the policy by
the appropriate algorithms [9,18]) remain entirely constant
that would not be feasible. For example, if a user creates a
new model element, the corresponding asset propagated to
the gold model by PutBack would only evaluate as writeable
once it exists in the first place. What is actually required is that
permissions are not allowed to flip-flop; i.e. a transformation
should never observe a particular asset change its effective
permissions if the transformation has already acted upon the
old value of the effective permissions. This condition is met
in the previous example, as we can include the newly created
asset in the constant permission set as writeable: the asset
did not exist in the gold model before its creation, so no
rules would have ever observed it as an existing but non-
writeable asset; as far as the rules are concerned, the asset
could have always been listed as writeable in the permission
set.
Get leaves the gold model, and thus, the effective per-
missions unchanged, so Assumption 1holds trivially. For
PutBack, however, it is possible to come up with scenar-
ios where Assumption 1is violated. One of these cases
is privilege escalation, where a user can make a change
somewhere in the model that would grant them addi-
tional read or write privileges somewhere else that they
did not previously have (even though those assets existed
before). The other case is lockout, where a user can make
a change that will have the side effect of losing their
read or write access on some assets (even though those
assets continue to exist). We believe both of these cases are
likely symptoms of defective policy definition, and a sys-
tem can only be considered secure and reliable if it does not
exhibit these behaviours (or only in a very controlled man-
ner).
Therefore, in the proofs for the properties of Sect. 4.3.1,
we consider Assumption 1to hold and apply partitioning-
based arguments partly similar to those in [5,25]. This
limitation to the case with regularity is, on one hand, nec-
essary to prove the properties stated earlier (the exception
is Property 1; the transformations will be shown to ter-
minate regardless whether regularity holds). On the other
hand, the limitation is prudent for the above-listed rea-
sons of security. Finally, the limitation is also feasible,
as it is fairly easy to screen changes during PutBack
and reject them if they lead to either privilege escalation
or lockout. Static analysis of policy definitions regard-
ing their susceptibility to these problems is left as future
work.
Now we are ready to sketch conditional proofs for each of
the listed properties to hold for the transformations induced
by rule sets in “Appendices Aand B”; the proof sketches are
found in “Appendix C”.
4.3.3 Realization in EMF
We realized the presented lens transformation in the Eclipse
Modelling Platform (EMF) [52]. Instead of approaches
specifically designed for easy specification of bidirectional
transformations, the unidirectional and reactive VIATRA
framework [54] has been chosen for its (a) target-incremental
transformations and (b) source-incremental model queries to
define rule preconditions.
123
Content courtesy of Springer Nature, terms of use apply. Rights reserved.
Enforcing fine-grained access control for secure collaborative modelling using bidirectional… 1749
The presented transformation rules, as well as the
proof sketches, are formulated on technology-independent
models defined as a set of model assets. Actual
model representations—EMF in our case—expose an
object-oriented API instead. Therefore, we have imple-
mented a relational model wrapper layer that exposes the
contents of the model through a writeable API as a set of
model assets (essentially tuples). This abstraction, however,
is incomplete: the underlying object-oriented model struc-
ture (i) may not be compatible with all set operations and (ii)
may allow a given set of operations only in certain sequences.
The transformation must enforce these constraints.
The first problem occurs if adding or removing a model
asset would violate the internal consistency (see Sect. 3.1)
of the model; this is avoided by the consistency property of
effective permission function in such a way that both Get
and PutBack would only attempt valid changes to the front
and gold models, respectively.
The second problem occurs if valid changes are attempted
in the wrong order, e.g. if a reference asset is only deleted
after deleting the object asset for one of the endpoints. By
choosing the transformation rule priorities accordingly, the
object, attribute and reference rules are ordered in a way that
avoids violating these kinds of constraints in all but one cases.
The remaining case is object containment, e.g. a child object
cannot be added to the model before its container object is
created. This depends on the ordering of two instances of
the object rule and thus cannot simply be expressed using
rule-level fixed priorities. To solve this problem, the rela-
tional model wrapper temporarily allows “unrooted” model
objects detached from the model. Note that the EMF API
itself allows the existence of such detached model objects,
and they are just not treated as part of the model (resource
set) by default, which our model wrapper needs to circum-
vent.
As a further effect of this abstraction layer, there is a
genuine loss of information: the ordering of multi-valued
collections is not preserved in the relational representation.
See Sect. 6.3.2 for discussion.
As a slight technical hurdle, the EMF-based query engine
of VIATRA, in charge of interpreting the query-based secu-
rity policy, is not actually capable of evaluating permission
queries on assets that are non-existent in the gold model. A
workaround is applied in practice to the additive PutBack
attribute rule (the only rule where this is relevant, due to
obfuscation), which we omit here.
Finally, we note that in order to simplify the language
of the discussion, we have informally described assets as
potentially being contained in both the gold and front
models. Since a single EMF object is contained in at
most one model, it would be more precise to say that
the two models contain disjoint assets that are related
by the equivalence induced by the trace function (see
Sect. 4.2).
5 Collaboration scheme
To satisfy our goal G4, a general collaboration scheme
is required including the bidirectional lens transformation
between a server and several clients to enforce access con-
trol policies correctly.
The server stores the gold models and clients can down-
load their specific front models. Modifications, executed by
a client, can be submitted to the server and downloaded by
the other clients. These are the basic actions that nowadays,
a version control system (VCS) should provide to a user. In
case of various implementations, these actions may be called
differently (e.g. checkout,update,commit in SVN or clone,
pull,push in Git).
According to the basic actions supported by any VCS, we
define the basic operations of the collaboration scheme as
follows:
Checkout downloads the model from the server side to
the workspace of a specific client who initiated the oper-
ation.
Update retrieves the model changes from the server side
to the workspace of a specific client who initiated the
operation.
Commit propagates the changes of a specific client to the
server side.
5.1 Formalization of the collaboration
Figures 6and 7describe the behaviour of collaboration
scheme as state machines for the server and the client.
A state machine consists of states (represented by boxes)
and transitions (denoted by directed edges) between states.
Each state machine has an initial state (denoted by arrow
from a black circle) and a current state that specifies the
system at a certain time.
The system can accept input events and send output events
during its process (denoted by labels on the edges where “?”
and “!” mean receiving and sending a certain event, respec-
tively, following process-algebraic notation). In the concept
of collaboration, each event is assigned to a collaborator
using “.” symbol after the name of event, e.g. input.x/output.y
means that the collaborator xinitiates an input and the tran-
sition produces an output to the collaborator y. A transition
will be executed immediately when its input event arrives
and during the execution it produces its output event.
Compound state (visualized as boxes containing other
states) refines the behaviour of a given state by defining its
own state machine where only one state can be active.
123
Content courtesy of Springer Nature, terms of use apply. Rights reserved.
1750 C. Debreceni et al.
Fig. 6 State machine of the collaboration server
Orthogonal regions (divided by dashed borders) separate
the behaviour of independent states, and they are processed
concurrently. In each region, only one state can be active at
a time.
Two state machines can synchronize on events sending by
one and received by the other one.
Server (Fig.6). Its state machine has three orthogonal regions
to handle the commit,update and checkout requests concur-
rently.
Checkout and Update. In case of receiving checkout and
update requests, our approach rejects them when a user
has no access to the model itself3by sending an access-
Denied eventfollowedbyafailure event. Otherwise, a
success event is sent.
Upon an update request, it is also checked, whether the
client’s model is up to date, and then, an upToDate event
is produced followed by a success event.
3Note that we make a distinction between a user having no access to
a model at all, and a user having access to the model, but nothing is
readable in it.
Commit. The process of receiving commit requests con-
sists of Idle,Locked,Synchronization and Unlock
hierarchical states:
Idle state accepts commit requests from any collab-
orator. It produces an accessDenied event when the
user has no access to the model, or a needToUpdate
event when the user needs to update his/her model
locally to be able to commit the modifications. Both
eventsarefollowedbyafailure event. Otherwise, the
system locks the model to prevent concurrent pro-
cessing any other commit requests and activates the
Locked state.
Locked state executes the TPutBack in the name of
the commit owner (x) and rejects the commit requests
from any collaborator (y) by sending an otherCom-
mitUnderExecution event with a failure event. After
the execution of the transformation, a policyViolated
event is sent to x, if the changes violated the access
control policy and the system steps to Unlock state.
Otherwise, a putback event leads the system to the
Synchronization state.
Synchronization state is responsible for sending
the success event to the owner of the commit and
123
Content courtesy of Springer Nature, terms of use apply. Rights reserved.
Enforcing fine-grained access control for secure collaborative modelling using bidirectional… 1751
Fig. 7 State machine of the collaboration client
executing TGet to propagate the changes to other
collaborators (denoted by output event get for all col-
laborator except the owner of the commit in the state
Sync). Then, systems move forward to the Unlock
state.
Unlock state is responsible for unlocking the model
in all cases (unlock event). If the system is led to
this state after a policy violation, the state produces
afailure event before the unlock. It also rejects any
other commit request by sending an otherCommitUn-
derExecution event with a failure event.
Client (Fig. 7). Its state machine cooperates with the server
using the sending and receiving events that (i) trigger an
operation (commit,update,checkout); (ii) indicate failures
(needToUpdate); and (iii) indicate server responses (success,
failure). It consists of Checkout,Idle and Update hierar-
chical states:
Checkout State. First, the clients need to checkout their
models represented by sending a checkout event in the
Checkout state. Based on the received server response,
the clients can move to Idle state.
Idle State. In Idle state, clients can commit or update
their changes by sending commit or update events. All
the events produced by the server can be received, but
only the needToUpdate event restricts the behaviour of
the client by moving to Update state.
Update State. The clients need to initiate an update
request by sending a update event to be able to commit
their changes again.
5.2 Correctness criteria
To address the challenge C4.1, we describe the correctness
criteria that the collaboration scheme needs to satisfy:
Criterion 1. The scheme needs to be deadlock free
(i.e. all the locks need to be unlocked during a commit
operation).
Criterion 2. The scheme needs to be livelock free (i.e.
all the operations need to finish at some point and lead
the scheme to an idle state).
Criterion 3. Commit operation shall be rejected, while
another commit is under execution.
Criterion 4. Commit operation shall propagate the
changes to all collaborators.
Criterion 5. Clients need to initiate an update operation
when it is required by the server.
Note that Criterion 1. and Criterion 2. are required
to ensure that the collaboration can run without any man-
ual intervention. Criterion 3. declines overwriting changes
without notification of a commit happened previously. Cri-
terion 5. enforces the clients to avoid conflicting commits.
5.3 Proof of correctness
In accordance with challenge 4.1, we formalized our col-
laboration scheme as communicating sequential processes
(CSP) [44,45] described in “Appendix D” to prove its correct-
ness. CSP is a formal specification language of concurrent
programs or systems where the communications and inter-
actions are presented in an algebraic style.
The Server and Clients processes define the behaviour of
exactly 1 server and nclients, respectively. The collabora-
tion is specified as a concurrent execution (denoted by ||)of
the server and clients where the processes synchronize on a
given set of events SyncEvents:{commit, update, checkout,
accessDenied, policyViolated, needToUpdate, failure,
success}.
Collaboration =Server||SyncEvents Clients[1..n]
For the analysis, we used the FDR4 tool [30] to evaluate
assertions over certain properties of the processes.
123
Content courtesy of Springer Nature, terms of use apply. Rights reserved.
1752 C. Debreceni et al.
Criteria 1. and 2. require the entire collaboration pro-
cess (Collaboration) to be deadlock and livelock free.
To check these properties, the :[dea dlock f ree]and :
[diver gence f ree]built-in structures are used, respectively.
assert Collaboration :[deadl ock f r ee](1)
assert Collaboration :[diver gence f ree](2)
The rest of the criteria requires to evaluate whether the
process formally refines a certain event sequence according
to the CSP models, namely the traces and failures models.
For that purpose, we use the T:and F:structures, respec-
tively, where
PT:<a,b,c>means that process Pmust be able to
perform the ordered sequence of the events a,b,cand
only these events.
PF:<a,b,c>means that process Pmust not be able
to refuse to perform the ordered sequence of events a,b,
cwithout performing any other event.
To check the remaining criteria, we introduce the ¬sym-
bol to negate assertions; the \symbol that hides events
from the process and Edenotes the events provided by all
processes. The combination of these symbols allows us to
evaluate the processes in the context of certain event, e.g.
P\(E∩{a,b,c})means that all events are hidden from the
process Pexcept a,band c.
Criterion 3. includes that after executing a TPutBack,
another TPutBack cannot be executed without unlocking the
model.
assert Server \(E∩{unlock,putback})(3)
¬T:<putback.x,putback.y>
x,yInt,x= y
Criterion 4. requires to execute TGet for all collabora-
tors other than the owner of the commit after a successfully
executed TPutBack but before unlocking the model. As we
start the synchronization with collaborator 1, and then 2, it
implies that the collaboration scheme needs to execute it to
the last collaborator, namely n.
assert Server \(E∩{get.n,put back,unlock})(4)
T:<putback.x,get.n,unlock.x>
x,NInt,x= n
To satisfy Criterion 5., after a commit operation rejected
by the server with a need to update message, the client (i)
cannot commit again and (ii) must be able to initiate update
operation:
Tabl e 2 Results of the assertion in FDR4 tool
Assertions States Transitions time (s)
189,233 227,591 0.44
289,233 227,591 0.51
3452 1121 0.13
4417 1071 0.42
510 11 0.12
610 11 0.12
assert Clients \(E∩{commi t,update,needT oU pd ate})
(5)
¬T:<commi t .x,need T oU pda te.x,commit.x>
assert Clients \(E∩{commi t,update,needT oU pd ate})
(6)
F:<commi t .x,need T oU pda te.x,update.x>
xInt
As in the assertions we hide several events, the FDR4 tool
was able reduce the state space and the transitions that needs
to be traversed.
We evaluated the assertions4for n=5 users. The results
are presented in Table 2. To check deadlock and livelock
properties, all the events and states are required. Hence, the
tool traversed almost 90,000 states and 230,000 transitions to
prove these properties. To verify the rest of the assertions, at
most 500 states and 1100 transitions were enough to traverse.
All the assertions are evaluated within less than 0.51 seconds
and none of them failed.
According to the results, we state that our collaboration
scheme for access control management satisfies the correct-
ness criteria.
6 Realization of Collaboration Scheme5
In accordance with challenge 4.2, our goal is to provide tool
support for enforcing fine-grained model access control rules
in offline and online scenario realizing the introduced collab-
oration scheme (see Sect. 5).
6.1 Offline collaboration
In the offline scenario, models are serialized (e.g. in an XMI
format) and stored in a version control system (VCS). Users
4The complete formal specification is available at: http://goo.gl/
pJzIX1.
5Source codes and more details are at https://tinyurl.com/
sosym-access-control-source.
123
Content courtesy of Springer Nature, terms of use apply. Rights reserved.
Enforcing fine-grained access control for secure collaborative modelling using bidirectional… 1753
Fig. 8 The MONDO offline collaboration server: architecture
work on local working copies of the models in long transac-
tions called commits. The goal of our approach is to manage
fine-grained access control on the top of existing security
layers available in the VCS.
6.1.1 Realization
The concept of gold and front models is extended to the
repository level where the two types of repositories are called
gold and front repositories as depicted in Fig. 8.Thegold
repository contains complete information about the gold
models, but it is not accessible to collaborators. Each user
has a front repository, containing a full version history of
front models. New model versions are first added to the front
repository; then changes introduced in these revisions will be
interleaved into the gold models using PutBack transforma-
tion. Finally, the new gold revision will be propagated to the
front repositories of other users using Get transformation.
As a result, each collaborator continues to work with a ded-
icated VCS as before; thus, they are unaware that this front
repository may contain filtered and obfuscated information
only.
Existing access control mechanisms (such as firewalls)
are used to ensure that the gold model is accessible to supe-
rusers only, and each regular user can only access their own
front repository. These regular users can use any compatible
VCS client to communicate with their front repository, being
unaware of collaboration mechanisms in the background.
This scheme enforces the access control rules even if
users access their personal front repositories using standard
VCS clients and off-the-shelf modelling tools. Nevertheless,
optional client-side collaboration tools may still be used to
improve user experience, e.g. for smart model merging [19],
user-friendly lock management [13] or preemptive warning
about potential write access violations that greatly enhances
the usability and applicability of the offline scenario.
6.1.2 Realization of the collaboration scheme
In the current prototype, our collaboration scheme is realized
by extending an off-the-shelf VCS server, namely Subver-
sion [2]. Subversion provides features of the collaboration
scheme by default:
File- level access control
is responsible for sending accessDenied event to the col-
laborators whenever their access is denied for a certain
file (which contains models).
Version control
allows to the users to download the files by sending a
checkout event, submit their changes by sending a commit
event and update the files by sending an update event.
Version check
checks the version of the files and sends upToDate the col-
laborators whether the files are already up-to-date upon
an update or sends needToUpdate event they need to
update upon a rejected commit.
File- level locking
allows users to lock files by sending a lock event and
reject commits initiated by other users. They can also
remove their locks by sending an unlock event.
Handling Multiple Requests
allows users to initiate multiple requests simultaneously
that the server can accept.
Final Notification
notifies the users about the result of their requested oper-
ations by sending a success or a failure event.
As checkout and update operations of the collaboration
scheme are fully handled by Subversion, we need to integrate
the TPutBack and TGet into the commit operation to enforce
fine-grained access control and propagate the changes.
Hooks are programs triggered by repository events such
as lock,unlock or commit. The hook may be set up to be trig-
gered before such an event (with the possibility of influencing
its outcome, e.g. cancelling it upon failure) or directly after-
wards (when the event is guaranteed to have happened). The
following hook programs will be executed upon a commit
operation.
Pre-Commit Hook. TPutBack is invoked by pre-commit hook
executing when a user attempts to commit a new revision of
a model Mr
F(new revision rof a model MF). This hook per-
forms the following steps to enforce access control policies
corresponding to Fig. 9:
1. Parent revision Mr
Fof Mr
Fis identified.
2. Revision Mr
Fis traced to the corresponding revision MR
G
in the gold repository.
3. The hook attempts to put a file-level lock to MGin the
gold repository.
123
Content courtesy of Springer Nature, terms of use apply. Rights reserved.
1754 C. Debreceni et al.
Fig. 9 Pre-commit hook at the front repository
(a) If the locking attempt fails, the hook terminates send-
ing an otherCommitUnderExecution event.
(b) Otherwise, the lock on MGis activated by sending a
lock and the hook continues its process.
4. TPutBack is executed between Mrq
Fand MR
Gin the gold
repository, in order to reflect the changes performed in
the new commit.
(a) If the TPutBack detects any attempts to perform model
modifications violating write permissions, then the
commit process to the front repository terminates by
sending a policyViolated event.
(b) Otherwise, the commit is deemed successful, and
MR
Gis committed to the gold repository (with meta-
data such as committer name and commit message
copied over from the original front repository com-
mit).
5. Finally, the hook finishes successfully and let the VCS
server to handle the request.
Post-Commit Hook. TGet is invoked by post-commit hook
synchronizing all front models Mr
Fwith the new revision
of gold model MR
G. This hook is triggered after a commit of
MR
Gfinished successfully at the gold repository and performs
the following steps correspond to Fig. 10 to propagate the new
changes.
1. Parent revision MR
Gof MR
Gis identified.
2. The hook iterates over each front repository and execute
the following steps. If the commit to the gold repository
is initiated by a front repository, then the originating front
repository will be skipped.
(a) Revision MR
Gis traced to the corresponding front revi-
sion Mr
Fin the front repository.
Fig. 10 Post-commit hook at the gold repository
(b) TGet is executed between MR
Gand Mr
Fin order to
reflect the changes performed in the commit. If Mr
F
does not exist, it is handled as an empty model.
(c) New revision of the model Mr
Fis commited to the
front repository (with metadata such as committer
name and commit message copied over from the orig-
inal front repository commit).
3. The hook removes the lock from MR
Gby sending an
unlock event.
4. Finally, it finishes successfully and lets the VCS server
to handle the request.
6.1.3 Discussion
It is worth discussing the following properties of the offline
collaboration framework.
Generality. Our solution is general and adaptable to any VCS
that supports checkout,update,commit operations (maybe
they are named differently).
Server Response. Users get response to their commit right
after the collaboration server attempts to propagate back the
changes to the gold repository. If any access control rule
is violated, the pre-commit hook fails. At the last phase
of pre-commit, the VCS declines the commit action to the
gold repository, if any modified files are locked on the gold
repository. Hence, the hook failsagain and prevent the VCS-
specific file-level locks. In contrast, if everything goes well,
the users do not need to wait for synchronizing with the
remaining front repositories.
Multiple Models in a Commit. A single commit may update
several models at once. In this case, the hooks are invoked
for each model in the commit.
Non-blocking Commit. Commit operation does not block
update and checkout operations as previous versions still
readable in the front repositories.
123
Content courtesy of Springer Nature, terms of use apply. Rights reserved.
Enforcing fine-grained access control for secure collaborative modelling using bidirectional… 1755
Models stored among other project files. Our solution
supports storing models along with non-model files in the
repositories. The hooks can be parameterized with file exten-
sions to determine whether a file needs to be handled as a
model. When a file is not a model, it is simply copied from
the gold repository to the front repositories.
Correspondence Relation. It is a challenging task to identify
the correspondences between model assets of the front and
gold models, where the models are stored independently as
it is addressed in C2.2.
Our approach currently uses specific attributes to provide
permanent identifiers. Such a permanent identifier is pre-
served across model revisions and lens mappings and can
therefore be used to pre-populate the object correspondence
relation. In our running example, each object has a unique id
attribute. Note that unlike EMF, some modelling platforms
(e.g. IFC [32]) automatically provide such permanent iden-
tifiers.
While requiring permanent identifiers is a limitation of
the approach, it is only relevant for modelling platforms that
do not themselves provide this kind of traceability, and only
in the offline collaboration scenario. Being able to identify
model objects is a relatively low barrier for modelling lan-
guages; e.g. the original wind turbine language includes a
unique identifier for all model objects.
Authorization Files We have taken the design decision that
the authorization files are stored and versioned in the same
VCS as the models. Thus, policy files may evolve naturally
along with the evolution of the contents of the repository.
Policy files are writable by superusers only, but readable
by every user; this means that offline clients may evaluate
security rules on their offline copies themselves. Note that
we do not believe that this openness of the security policy
causes major security concerns, as security by obscurity is not
good security principal. In any way, names and parameters of
security rules should not themselves contain sensitive design
information.
6.2 Online collaboration
In the online scenario, several users can simultaneously dis-
play and edit the same model with short transactions by using
a web-based modelling tool where changes are propagated
immediately to other users during collaborative modelling
sessions. In contrast to the offline scenario, where users
manipulated local copies of the models, models are kept in
a server memory and users access the model directly on the
server. The goal of our approach in accordance with C3.1
is to incrementally enforce fine-grained model access con-
trol rules and on-the-fly change propagation between view
models of different users.
Fig. 11 Overview of online collaboration
6.2.1 Technical realization
During a collaborative modelling session, a model kept in
server memory for remote access may also be called a white-
board depicted in Fig. 11. The collaboration server hosts a
number of whiteboard sessions, each equipped with a gold
model. Each user connected to a whiteboard is presented
with their own front model, connected to the gold model
via a lens relationship. The front models are initially created
using Get. If a user modifies their front model, the changes
are propagated to the gold model using PutBack and prop-
agated further to the other front models using Get again. In
case of online collaboration, these lens operations are contin-
uously and efficiently executed as a live transformation [16];
thus, users always see an up-to-date view of the model during
the editing session.
Similarly to modern collaborative editing tools (such as
Google Sheets [15]), whiteboards can be operated transpar-
ently: whenever the first user attempts to open a given model,
a new whiteboard is started; subsequent users opening the
model will join the existing whiteboard. When all users have
left, the whiteboard can be disposed. The model may be per-
sisted periodically, or on demand (“save button”). The session
manager component enables collaborators to start, join or
leave whiteboard sessions and persist models to disc.
6.2.2 Realization of the collaboration scheme
To achieve challenge 4.2, we need to discuss how the online
collaboration realizes the collaboration scheme.
1. The checkout operation is equivalent to joining the white-
board session for the first time, except it requires to
execute TGet that achieves the front model on which the
new user can work.
123
Content courtesy of Springer Nature, terms of use apply. Rights reserved.
1756 C. Debreceni et al.
2. The update operation is equivalent to refresh the browser
on client side. Via web-based technologies, the collabora-
tion framework notifies and forces the clients’ browsers
to refresh when new changes are introduced into their
front models. However, manual refresh usually results in
an upToDate event, except when the notification and the
manual refresh initiated at the same moment.
3. The commit operations are initiated right after users
apply modifications on their front models. Other clients
need to wait (receiving otherCommitUnderExecution
event) until the commit finishes, including the execu-
tion of PutBack and all Get processes to propagate
the changes. After a successful commit, clients receive
notification to force them to initiate and update. When a
policyViolated event occurs, the change is immediately
rolled back at the initiator’s front model.
6.2.3 Discussion
It is worth discussing the following properties of the online
collaboration framework.
Conflicts Handling. As the online collaboration operates
with short transactions, it has only a small chance that con-
flict occurs during the session (e.g. a collaborator modifies an
object that is deleted by another collaborator and the propaga-
tion of the deletion is under execution). However, if a conflict
araises, it is resolved by accepting the remote changes. It also
implies that the latter changes will be lost.
Blocking Checkout and Update. Version numbers are not
considered in online collaboration and only one gold model
exists during a session. Hence, checkout and update opera-
tions need to wait until the commit operation finishes if these
operations were initiated during the execution of a commit.
Prototype User Interface. An initial user interface is imple-
mented as a proof of concept, depicted in Fig. 12, that uses
the editors automatically generated from EMF metamodels6
which also provides similar modelling environment as the
desktop Eclipse IDE. This prototype tool is to demonstrate
how to adapt rule-based access control with bidirectional
lenses to the online collaboration scenario. We strongly
believe that several other existing tools such as GenMy-
Model [3,49,50] can easily adapt our solution.
Correspondence Relation. In the online case, the gold and
its front models are initiated for a collaboration session. Dur-
ing a session, these models are stored in the memory and
there is no need to reload any of them. Correspondences
established during TGet can be used through the online
collaboration. Hence, there is no limitation about the mod-
els (unlike in the offline case, where unique identifiers are
required).
6EMF and RAP integration: https://wiki.eclipse.org/RAP/
EMF_Integration.
Fig. 12 User interface for online collaboration prototype
Integration with Offline Collaboration. Models and autho-
rization files can be persisted to an underlying gold repository
provided by a VCS. The online collaboration tool can access
them using checkout/update/commit commands. However,
if file-level conflicts occur in the underlying VCS, they will
need specific user interfaces to resolve them. Instead, we
decided that new whiteboard sessions put file-level locks on
the resources related to the models to prevent conflicts in the
VCS upon persisting.
6.3 Assumptions and limitations
6.3.1 Feedback on write access control
As discussed before, the means of write access control is
the following. In the offline case, the server rejects unautho-
rized modifications only when the user finally submits them.
In the online case, PutBack is a live transformation, and
it can immediately reject non-compliant changes. (Note that
rejected write attempts offer a side channel through which
some information on the hidden parts of the gold model
may be gained. While it is besides the point here, policy
designers are advised to take such unintended effects into
account.)
It can be frustrating and unproductive for users to learn
about their insufficient permissions by trial and error. This
is especially true in the offline case, where the feed-
back only arrives when modifications are actually com-
mitted. In a better system, write restrictions would be
readily available to the user; advanced modelling tools may
even incorporate this information into their model nota-
tion, e.g. to visually show read-only parts of the model as
frozen.
123
Content courtesy of Springer Nature, terms of use apply. Rights reserved.
Enforcing fine-grained access control for secure collaborative modelling using bidirectional… 1757
However, such a tight feedback loop in the offline case
would either require nonstandard communication channels
(with their own security risks) to disclose the evaluated
permission sets with the client, or alternatively additional
computations such as client-side approximation of the pol-
icy queries based on the incomplete information in the front
model. Proposing a satisfactory solution is left as future work,
e.g. by elaborating initial ideas of [13].
6.3.2 Ordered lists
In EMF, some multi-valued references and attributes are
ordered lists. Model assets introduced in Sect. 3.1 collec-
tively represent all knowledge contained in an EMF model
except for ordering information. Thus, the lack of ordered
lists is a limitation of the proposed solution. The core reason
is that there is no unique way to provide PutBack for ordered
lists that have been filtered; therefore, such a lens would nec-
essarily violate at least Property 7and undoability. Finding an
acceptable resolution of the problem (e.g. imposing a limita-
tion that, for each user, ordered lists must be read-only unless
entirely visible) is left as future work. For now, the proposed
solution works properly for unordered collections.
6.3.3 Central authority
Note that both G2 and G3 assume a central repository (owned
by, for example, a system integrator) where the entire model
is available. In a more general case, no single entity would
be in possession of complete knowledge. There is an alge-
bra [21] for combining lens transformations in various ways,
suggesting a promising path for addressing this issue in future
research. However, such a distributed scenario is out of scope
for this paper; we address the centralized case, which is by
far the most common in access control approaches used in
model repositories.
7 Evaluation
We have carried out a scalability measurement in both offline
and online scenario over the Wind Turbine Case Study [4]of
the MONDO FP7 project. We state the following research
questions in the evaluation:
Online Collaboration
Q1 Is the change propagation is incremental as it is
requested in challenge C3.1?
Q1.1 How scalable is our approach to increasing
model size?
Q1.2 How scalable is our approach to increasing
number of active users?
Fig. 13 Modified metamodel of wind turbine
Offline Collaboration
Q2 What is the overhead of using query-based access
control over an existing VCS?
Q2.1 How scalable is our approach to increasing
model size?
Q2.2 How scalable is our approach to increasing
number of front repositories?
Q2.3 How scalable is our approach to increasing size
of committed changes?
Finally, Sect. 6.3 will discuss limitations of our solution.
7.1 Scalability evaluation
7.1.1 Measurement setup
For the measurement, we used the simplified metamodel of
Fig. 2depicted in Fig. 13 which has slight modifications. The
control unit types were abstracted to a string attribute, with
Kdifferent permitted values to provide Kdifferent specialist,
and the attributes of signals are removed. The corresponding
access control rules are similar to our motivating example
Sect. 2, with one specialist engineer for each control unit type
(each having five access control rules dedicated to them) and
an additional system administrator user who has read and
write permission for the entire model. This means altogether
K+1 users and 5K+5 access control rules as it is shown
in Fig. 14.
Measurements were performed with gold instance mod-
els of various size. The model of size Mcontains a root
Composite object, which contains Mcopies of the struc-
ture depicted in Fig. 15. This means 1 +Mcomposite
modules, 2Mcontrol units, 8Msignals where 3Mof them
are confidential and 14M+Mreferences where 4 Mof them
are consumes cross-references. The copies are not completely
identical: the vendor attributes are set to a different value in
each copy, and type and cycle attributes of control units
were chosen randomly from their respective ranges with uni-
form distribution. However, special care was taken to ensure
that all control unit types must occur at least once; this also
implies 2MK.
123
Content courtesy of Springer Nature, terms of use apply. Rights reserved.
1758 C. Debreceni et al.
Fig. 14 Users and active user in the measurement setup
Fig. 15 Core structure of synthesized models
The measurement was performed with UKspecialist
users and the system administrator being present (thus in total
U+1 front models).
Online case. To test the incremental behaviour of the lens
transformation addressed by Q1, we measured the time it
took the system administrator to perform a complex model
manipulation operation on his front model and to propagate
the changes to the front models of all users who can see it. The
measured complex operation is a signal reversal (depicted
in Fig. 16), which reverts the direction of a communication
channels by changing the provides and consumes to the oppo-
site.
We have selected this representative operation since (a) it
involves adding and removing cross-references and a rear-
rangement of the containment hierarchy; (b) it does not
change the size of the model and thus introduces no bias
of this kind; (c) the change is noticeable by all users that can
see at least one of the involved modules in their front mod-
els; and (d) every access control rule in the policy (except for
hiding the vendor attribute) plays a role in determining the
impact of the change.
Offline case. The measurement focuses on the overhead
of the collaboration framework required for propagating a
change in the front model addressed by Q2. We measured
Fig. 16 Signal reversal operation
Fig. 17 Signal addition operation
the time it took a specific specialist to (1) propagate several
number of complex model manipulation operation on her
front model to the gold model and (2) from the gold model to
the remaining front models of all users who can see the effect
of the changes. The former describes the response time that
a user has to wait for receiving the result (success/failure) of
her commit, while the latter is the propogation time to prop-
agate changes to the other front repositories. The measured
complex operation is a signal addition (depicted in Fig. 17),
which adds a new signal under the root object.
We have selected this representative operation since (a) it
demonstrates that any number of new changes can be intro-
duced into the model; (b) it increases the model size but
always with constant-size addition; (c) all the users can see
the change in their front model; and (d) every access con-
trol rule in the policy (except for hiding the vendor attribute)
plays a role in determining the impact of the change.
Hardware Configuration All the measurements7executed
on a personal computer8with maximum a 7GB of Java heap
size.
7.1.2 Measurements of online case
In the model size scalability series, we used
fixed number of K=50 control unit types and U=10
present collaborators
with increasing size of the model ranging from M=50
to M=700 (7701 objects, 10,500 references)
In the active users scalability series, we used
fixed number of K=100 control unit types and model
of size M=200 (2301 objects, 3100 references),
7Raw data and reproduction instructions at https://tinyurl.com/
sosym-access-control.
8CPU: Intel Core i7-4700MQ@2.40GHz, MEM: 8GB.
123
Content courtesy of Springer Nature, terms of use apply. Rights reserved.
Enforcing fine-grained access control for secure collaborative modelling using bidirectional… 1759
0
2
4
6
8
10
12
14
50 76 100 126 150 176 200 300 400 500 600 700
Runme (ms)
Model Size (M)
Fig. 18 Average execution time of an online signal reversal (increasing
model size)
0
50
100
150
200
250
300
2 5 10 25 50 75 100
Runme (ms)
# of acve users
Fig. 19 Average execution time of an online signal reversal (increasing
the number of active users)
with the increasing number of specialist collaborators
joining the session ranging from U=2toU=100.
For accuracy, 100 reversal operations were carried out and
their execution times averaged in a single run; we have plotted
the median execution time of 10 runs, excluding 2 warm-up
runs, with 1 standard deviation error bars.
The results of the model size scalability series are shown
in Fig. 18 addressing Q1.1. The cost of performing a single
reversal model manipulation is low and seems to be inde-
pendent from the model size. This confirms that we have
achieved incrementality where computation cost is depen-
dent on the size of the change, but not on the size of the
entire model.
The results of the active users scalability series are shown
in Fig. 19 addressing Q1.2. It is apparent that when very few
users join the session, most signal reversals are not visible to
any user other than the principal engineer, but as more and
more specialist users join the session, the number of active
users starts to dominate the cost of model manipulation.
Asymptotically, the cost of model manipulation is propor-
tional to the average number of front models it is propagated
to.
Note that it has only a small chance that users concurrently
modify their front model as we mentioned in Sect. 6.2.3,but
in that case the operations which arrive later to the server
will be rejected. Hence, concurrent modifications have no
additional effect on the performance.
7.1.3 Measurements of offline case
In the model size scalability series, we used
fixed number of K=100 control unit types, Fr =20
front repositories and Ch =10 changes,
where the model is increased from M=100 to M=
6000 (34,001 objects, 45,000 references).
In the number of front repository scalability series, we used
fixed number of K=100 control unit types, model of
size M=800 (8801 objects, 12,000 references) and
Ch =10 changes,
where the number of front repositories is increased from
Fr =5toFr =100.
In the change size scalability series, we used
fixed number of K=100 control unit types, model of
size M=400 and Fr =20 front repositories,
where the number of introduced changes is increased
from Ch =10 to Ch =1000.
The measurements were executed 10 times with 2 warm-
up execution in separate JVM, and the results show the
median of the measured values.
The charts represent the entire transformation time including
the following tasks: (1) loading the EMF models, (2)initial-
izing the lens by building the correspondence tables, (3)
loading the additional files such as rules and queries, (4)
executing the transformation and (5) finally serializing the
results as a committable new version of the models.
The lower part of the bars (denoted by checkered blue
background) represents response time including the Put-
Back phase of the transformation. This is the delay experi-
enced by committing users before they receive their response
from the server so that they can continue their work. The
upper part of the bars (in solid blue colour) visualizes prop-
agation time of the changes to synchronize with the rest of
the front repositories (this happens asynchronously from the
point of view of the committing user).
The results of model size scalability series are shown in
Fig. 20 addressing Q2.1. In case of the largest model, users
should wait at most 10 seconds to commit their changes in
addition to the default execution time of a commit in the
version control system. Response time grows linearly with
the size of the model, while synchronization is nonlinear to
the model size.
The results of number of front repository scalability series
are shown in Fig. 21 addressing Q2.2. In case of our spe-
cial signal addition change, all front repositories had to be
updated to propagate the changes and the same number of
123
Content courtesy of Springer Nature, terms of use apply. Rights reserved.
1760 C. Debreceni et al.
0
20
40
60
80
100
120
100 200 300 400 500 600 700 800 2000 4000 6000
Execution Time (sec)
Model Size (M)
Increasing Model Size (Ch: 10, Fr: 20)
Response Time Propagation Time
Fig. 20 Average execution time of an offline signal addition (increas-
ing model size)
0
20
40
60
80
100
5 102030405060708090100
Execuon Time (sec)
No. of Front Repositories (Fr)
Increasing Front Repositories (M: 800, Ch: 10)
Response Time Propogaon Time
Fig. 21 Average execution time of an offline signal addition (increas-
ing number of front repositories)
0
5
10
15
20
25
10 20 50 100 150 200 400 1000
Execuon Time (sec)
No. of Changes (Ch)
Increasing Change Size (M: 800, Fr: 20)
Response Time Propogaon Time
Fig. 22 Average execution time of an offline signal addition (increas-
ing number of changes)
modification had to be executed on those front models. The
results clearly show that the execution time grows linearly to
the number of front repositories to which the change has to
be propagated.
The results of the third series are shown in Fig. 22 address-
ing Q2.3. It shows that loading the models and building the
correspondence table dominate the execution time in case of
small changes. However, the execution time grows linearly
with the size of changes in case of large commits (e.g. from
1000), for the sole reason that the resulting model size itself
is increased due to the addition of so many new signals.
7.1.4 Discussion on performance findings
As seen from the measurements, the overhead on the com-
mit time experienced by a committer in the offline scenario is
manageable, but can easily reach several seconds for larger
models with tens of thousands of elements. This time is
still significantly shorter than typical build and test execu-
tion times in continuous integration solutions, so our access
control service is unlikely to form the bottleneck of devel-
oper productivity. Note that while the implementation of our
prototype could certainly be improved, it will always have
an overhead that is at least proportional to the model size,
since the entire new model file has to be read and processed
upon each commit (no matter how small the change within
that model). This is a characteristic of file-based offline col-
laboration (required to meet goal G2).
One way to get around this limitation is to use online
collaboration instead, where the execution time overhead
on model modification is very low, even for a few dozen
simultaneous collaborators. This can be seen as a space-time
trade-off, as online collaboration uses in-memory mod-
els, putting a limit on the amount of online sessions and
participants that a given server can support. We therefore
recommend the adaptation of online collaboration whenever
possible for models that are currently under very active devel-
opment, and using the file-based offline interface for other
cases, such as accessing rarely updated models, old revisions,
side branches, and of course for working on a disconnected
computer.
8 Related work
In this section, we collect the state-of-the-art approaches for
specifying and enforcing fine-grained access control over
various technological domains, and compare it to our solu-
tion.
8.1 Fine-grained policies in various domains
8.1.1 File-based access control
Traditional version control systems (like CVS, SVN) and file
sharing technologies adopt file-level access policies, which
are clearly insufficient for fine-grained access control speci-
fications.
Off-the-shelf file systems typically require resources (files
and folders) to be explicitly labelled with permissions that
take the form of an Access Control List (ACL), or the simpli-
fied form user/group/other flags. An ACL consists of entries
regarding which user/subject is granted or denied permission
for a given operation.
File-based solutions can be directly applied to MDE, but
cannot provide fine-grained access control, where differ-
ent parts of a model file have different permissions. Our
policies are fine-grained, use implicit rules (so that model ele-
ments do not have to be explicitly annotated with permission
123
Content courtesy of Springer Nature, terms of use apply. Rights reserved.
Enforcing fine-grained access control for secure collaborative modelling using bidirectional… 1761
flags, which is difficult to manually maintain as the model
evolves) and respect internal consistency (such as permission
dependencies of cross-references), all the while being more
flexible [18] in the conflict resolution method.
8.1.2 Access control in RDF triple/quad stores
Graph-based access control is a popular strategy for many
triple and quad stores (4store [29], Virtuoso , IBM DB2)
developed for storing large RDF data. User privileges can
be granted to for each named graph, while access control
is actually checked when issuing a SPARQL query. Denial
of access for a graph filters the query results obtained from
this specific graph. Data access in AllegroGraph [26] can be
controlled on the database or catalogue level (coarse-grained)
as well as on the graph and triple level (fine-grained), while
Stardog only allows database-level access control.
Similarly to our approach, fine-grained access control is
discussed in [20] using graph queries as preconditions of
rules to select certain assets on which the permissions need
to be enforced. The major difference is that we apply queries
in an MDE environment (this has very important implications
relative to RDF, see Sect. 3.1), and we also provide offline
collaboration.
In the Oracle Database Semantic Technologies [41],
access control is carried out by default on the model (graph)
level. Furthermore, it can be configured on the triple (row)
level, which is implemented by query rewriting. In this case,
the definition of access control policies is based on so-called
match and apply (graph) patterns, where the former identifies
the type of access restriction, while the latter injects access
control-specific constraints to the query.
Another access control technique is called label based
security, which offers (1) triple-level control using (a hierar-
chy of) sensitivity labels attached to each triple, and (2) RDF
resource-level access control for subject/predicate/object.
Explicit data access labels are implemented in [41] and are
generalized into abstract tokens and operators in [42].
8.1.3 Access control for XML documents
A number of standards such as XACML [31](OASIS
standard) provide fine-grained access control for XML doc-
uments. These types of documents are similar to models in a
way that they consist of nodes with attributes that may contain
other nodes. XACML provides several combining algorithms
to select from contradicting policies. In [27], fine-grained
access control is formalized using XPath for XML docu-
ments, which claims that the visibility of a node depends on
its ancestors; thus, when a node is granted access, then access
is also granted to its descendants. However, other dependen-
cies are not discussed related to XML Documents.
Similarly to our approach, a dedicated policy language is
used by [38], from which a lens is automatically generated
to enforce access control for XML documents. In addition
to the attributes and context of the assets (XML nodes), the
XQuery-based policy can take into account external (subject
or context) attributes as well. As it is not an MDE approach,
there is no treatment of cross-references. There is no dis-
cussion of internal consistency either (see Sect. 3.2), except
for the containment hierarchy, which is relevant for XML
as well. Finally, there is no discussion of the challenges of
online and offline collaboration.
8.1.4 Access control in collaborative modelling
environments
Currently, fine-grained access control is not considered in
the state-of-the-art tools of MDE such as MetaEdit+[53],
VirtualEMF [14], WebGME [36], EMFStore [50], GenMy-
Model [3], Obeo Designer Team [39], MDEForge [6]orthe
tools developed according to [28]. See also the broader sur-
vey in [43].
The generic framework CDO [49] (used, for exam-
ple, in [39]) provides both online collaboration and role-
based access control with type-specific (class, package and
resource-level) permissions, but no facility for instance-level
access control policy specifications. However, there is a plug-
gable access control mechanism that can specify access on
the object level; it should be possible to integrate fine-grained
solutions such as the currently proposed system.
The collaborative hardware design platform Vehicle-
FORGE stores their model in graph-based databases and has
an access control scheme TrustForge [17] that uses an imple-
mentation of KeyNote [10] trust management system. This
system is responsible for evaluating the request addressed to
the database, which can be configured in various ways. It sup-
ports unlimited permission levels, and it is also able to handle
consistency constraints by adding them as assertions. Con-
flict resolution strategies are not discussed. AToMPM [47]
provides fine-grained role-based access control for online
collaboration; no offline scenario or query-based security is
supported, though. Access control is provided at elementary
manipulation level (RESTful services) in the online collab-
oration solution of [23].
8.2 Access control enforcement
8.2.1 Access control using model transformation
Closest to our approach, [37] uses model transformations to
build infrastructures that can manage access control policies
written in any policy language. It means that their approach
takes a policy model as input and derives transformation rules
to enforce read and write permissions. To compare it to our
123
Content courtesy of Springer Nature, terms of use apply. Rights reserved.
1762 C. Debreceni et al.
solution, we use elementary model transformation rules that
take the effective permissions as input, instead of integrating
the permissions into our rules.
8.2.2 Model-driven security
Model-based techniques have also been used for access con-
trol purposes. In [34], similarly to our solution, access control
is enforced at runtime by program code that has been auto-
matically generated from a model-based specification, which
captures both system and security policy descriptions. This
technique can provide runtime checks only on single enti-
ties by using the guarded object design pattern. A similar
approach is suggested by [11], which specifies access control
policies by OCL. Although this idea enables the formulation
of queries that involve several objects, the efficient checking
of these complex structural queries highly depends on the
algorithmic experience of the system designer due to the fact
that OCL handles model navigation in an imperative style, in
contrast to declarative graph patterns, where several sophis-
ticated pattern matching algorithms are readily available.
The book chapter [35] about model-driven security pro-
vides a detailed survey of a wide range of MDE approaches
for designing secure systems, but does not cover the security
of the MDE process itself.
8.2.3 Access control using bidirectional programming
Bidirectional programming (BP) is an approach for defining
lenses concisely, e.g. by only specifying one of Get and
PutBack, and deriving the other. Such lenses can be directly
applied for read filtering. However, [25] demonstrates that
conventional BP is not sufficient for write access control.
It also proposes such an integrity-preserving BP extension,
focusing on string transformations (and therefore not directly
applicable in MDE). There is no notion of access control
policy either, so the security engineer has to develop their
own lens transformation to implement access control.
9 Conclusion and future work
In this paper, we aimed to uniformly enhance secure col-
laborative modelling by using fine-grained access control
policies uniformly for online and offline collaboration sce-
narios. Each collaborator can access a dedicated copy of the
model in accordance with read permissions of the policy.
Moreover, bidirectional transformations are used to synchro-
nize changes between different collaborators and check that
write permissions are also respected.
We illustrated our techniques in the context of a Wind Tur-
bine Case Study from the MONDO European project, which
was also used to assess scalability with models of increas-
ing size, increasing change introduced by collaborators and
increasing number of collaborators. In case of online col-
laboration, the results were promising with close to instant
propagation of changes and checking of write permissions.
In case of offline collaboration, the results show that the
response time is acceptable and the overhead is less than
10 additional seconds for the largest model).
As future work, we would like to (i) address the limita-
tions presented in Sect. 6.3, (ii) investigate the possibilities
of building correspondence relations between the original
model and filtered copy of it dedicated to a certain collab-
orator and (iii) realize our collaboration scheme with other
frameworks (e.g. Git, GenMyModel) and with support for
continuous integration and review/change request manage-
ment systems.
Acknowledgements This paper is partially supported by the EU Com-
mission with project MONDO (FP7-ICT-2013-10), no. 611125., the
MTA-BME Lendület 2015 Research Group on Cyber-Physical Systems
(LP-2015-12) and NSERC RGPIN-04573-16. The second author was
supported by the János Bolyai Research Scholarship of the Hungarian
Academy of Sciences.
Open Access This article is distributed under the terms of the Creative
Commons Attribution 4.0 International License (http://creativecomm
ons.org/licenses/by/4.0/), which permits unrestricted use, distribution,
and reproduction in any medium, provided you give appropriate credit
to the original author(s) and the source, provide a link to the Creative
Commons license, and indicate if changes were made.
123
Content courtesy of Springer Nature, terms of use apply. Rights reserved.
Enforcing fine-grained access control for secure collaborative modelling using bidirectional… 1763
AGET Transformation rules
rule Subtractive Get Reference Priority 1
Precondition :: (MG(OAG,RAG,AAG), MF(OA F,RAF,AAF), permi ssi onEff)→{ReferenceAsset}
{ReferenceAsset(sF,ref,tF)|ReferenceAsset(sF,ref,tF)RAF,
ObjectAsset(sF,ts)OA F,ObjectAsset(tF,tT)OA F:trace(ObjectAsset(sG,ts)) =ObjectAsset(sF,ts),
trace(ObjectAsset(tG,tt)) =ObjectAsset(tF,tt),ReferenceAsset(sG,ref,tG):ReferenceAsset(sG,ref,tG)RAG
permissionEff(ReferenceAsset(sG,ref,tG), read)= deny}
Action
RAF:= RA F\{ReferenceAsset(sF,ref,tF)}
rule Subtractive Get Attribute Priority 2
Precondition :: (MG(OAG,RAG,AAG), MF(OA F,RAF,AAF), permi ssi onEff)→{AttributeAsset}
{AttributeAsset(oF,attr,v
)|AttributeAsset(oF,attr,v
)AAF,ObjectAsset(oF,t):ObjectAsset(oF,t)OA F
ObjectAsset(oG,t):ObjectAsset(oG,t)OAG,tr ace(ObjectAsset(oG,t)) =ObjectAsset(oF,t), AttributeAsset(oG,attr,v) :
v=v, permissionEff(AttributeAsset(oG,attr,v),read)=allow
obf (v ), permissionEff(AttributeAsset(oG,attr,v),read)=ob f uscat e ,AttributeAsset(oG,attr,v)AA G}
Action
AAF:= AA F\{AttributeAsset(oF,attr,v
)}
rule Subtractive Get Object Priority 3
Precondition :: (MG(OAG,RAG,AAG), MF(OA F,RAF,AAF), permi ssi onEff)→{ObjectAsset}
{ObjectAsset(oF,t)|ObjectAsset(oF,t)OA F,ObjectAsset(oG,t):trace(ObjectAsset(oG,t)) =ObjectAsset(oF,t), t=t
permissionEff(ObjectAsset(oG,t), read)= deny}
Action
OAF:= OAF\{ObjectAsset(oF,t)},trace\ObjectAsset(oG,t)|trace(ObjectAsset(oG,t)) =ObjectAsset(oF,t)
rule Additive Get Object Priority 4
Precondition :: (MG(OAG,RAG,AAG), MF(OA F,RAF,AAF), permi ssi onEff)→{ObjectAsset}2
{ObjectAsset(oG,t), ObjectAsset(oF,t)|ObjectAsset(oG,t)OAG,permissionEff (ObjectAsset(oG,t), read)= deny,
ObjectAsset(oF,t)OA F:trace(ObjectAsset(oG,t)) =ObjectAsset(oF,t), t=t}
Action
OAF:= OAF∪{ObjectAsset(oF,t)},trace(ObjectAsset(oG,t)) := ObjectAsset(oF,t)
rule Additive Get Attribute Priority 5
Precondition :: (MG(OAG,RAG,AAG), MF(OA F,RAF,AAF), permi ssi onEff)→{AttributeAsset}
{AttributeAsset(oF,attr,v
)|AttributeAsset(oG,attr,v)AA G,permissionEff(AttributeAsset(oG,attr,v),read)= deny,
ObjectAsset(oF,t):ObjectAsset(oF,t)AAF,trace(ObjectAsset(oG,t)) =ObjectAsset(oF,t), AttributeAsset(oF,attr,v
):
v=v, permissionEff(AttributeAsset(oG,attr,v),read)=allow
obf (v ), permissionEff(AttributeAsset(oG,attr,v),read)=ob f uscat e ,AttributeAsset(oF,attr,v
)AAF}
Action
AAF:= AA F∪{AttributeAsset(oF,attr,v
)}
rule Additive Get Reference Priority 6
Precondition :: (MG(OAG,RAG,AAG), MF(OA F,RAF,AAF), permi ssi onEff)→{ReferenceAsset}
{ReferenceAsset(sF,ref,tF)|ReferenceAsset(sG,ref,tG)RAG,permi ssi onEff(ReferenceAsset(sG,ref,tG), read)= deny,
ObjectAsset(sG,ts), ObjectAsset(tG,tt):trace(ObjectAsset(sG,ts)) =ObjectAsset(sF,ts),
trace(ObjectAsset(tG,tt)) =ObjectAsset(tF,tt),ReferenceAsset(sF,ref,tF):ReferenceAsset(sF,ref,tF)RAF}
Action
RAF:= RA F∪{ReferenceAsset(sF,ref,tF)}
123
Content courtesy of Springer Nature, terms of use apply. Rights reserved.
1764 C. Debreceni et al.
BPUTBACK Transformation rules
rule Subtractive PutBack Reference Priority 1
Precondition :: (MG(OAG,RAG,AAG), MF(OA F,RAF,AAF), permi ssi onEff)→{ReferenceAsset}
{ReferenceAsset(sG,ref,tG)|ReferenceAsset(sG,ref,tG)RAG,permi ssi onEff(ReferenceAsset(sG,ref,tG), read)= deny,
ObjectAsset(sG,ts), ObjectAsset(tG,tt):trace(ObjectAsset(sG,ts)) =ObjectAsset(sF,ts),
trace(ObjectAsset(tG,tt)) =ObjectAsset(tF,tt),ReferenceAsset(sF,ref,tF):ReferenceAsset(sF,ref,tF)RAF}
Action
If permi ssi onEff(ReferenceAsset(sG,ref,tG), write)= deny then RAG:= RAG\ReferenceAsset(sG,ref,tG)else
rule Subtractive PutBack Attribute Priority 2
Precondition :: (MG(OAG,RAG,AAG), MF(OA F,RAF,AAF), permi ssi onEff)→{AttributeAsset}
{AttributeAsset(oG,attr,v)|AttributeAsset(oF,attr,v
):
ObjectAsset(oF,t):ObjectAsset(oF,t)OA F,trace(ObjectAsset(oG,t)) =ObjectAsset(oF,t),
v=v,permissionEff(AttributeAsset(oG,attr,v),read)=allow
obf 1(v ), permissionEff(AttributeAsset(oG,att r,v),read)=obf u scate ,AttributeAsset(oG,attr,v)AAG}
Action
If permi ssi onEff(AttributeAsset(oG,attr,v),write)= deny then AAG:= AAG\AttributeAsset(oG,attr,v)else
rule Subtractive PutBack Object Priority 3
Precondition :: (MG(OAG,RAG,AAG), MF(OA F,RAF,AAF), permi ssi onEff)→{ObjectAsset}
{ObjectAsset(oG,t)|ObjectAsset(oG,t)OAG,permissionEff (ObjectAsset(oG,t), read)= deny,
ObjectAsset(oF,t):trace(ObjectAsset(oG,t)) =ObjectAsset(oF,t), t=t}
Action
If permi ssi onEff(ObjectAsset(oG,type), write)= deny then
OAG:= OA G\ObjectAsset(oG,t), trace\ObjectAsset(oG,t)|trace(ObjectAsset(oG,t)) =ObjectAsset(oF,t)else
rule Additive PutBack Object Priority 4
Precondition :: (MG(OAG,RAG,AAG), MF(OA F,RAF,AAF), permi ssi onEff)→{ObjectAsset}2
{ObjectAsset(oF,t), ObjectAsset(oG,t)|ObjectAsset(oF,t)OA F,ObjectAsset(oG,t):trace(ObjectAsset(oG,t)) =ObjectAsset(oF,t)}
Action
OAG:= OA G∪{ObjectAsset(oG,t)}
If permi ssi onEff(ObjectAsset(oG,t), write)= deny then trace(ObjectAsset(oG,t)) := ObjectAsset(oF,t)else
rule Additive PutBack Attribute Priority 5
Precondition :: (MG(OAG,RAG,AAG), MF(OA F,RAF,AAF), permi ssi onEff)→{AttributeAsset}
{AttributeAsset(oG,attr,v)|AttributeAsset(oF,attr,v
)AAF,ObjectAsset(oF,t):ObjectAsset(oF,t)AA F
ObjectAsset(oG,t):ObjectAsset(oG,t)OAG,tr ace(ObjectAsset(oG,t)) =ObjectAsset(oF,t), AttributeAsset(oG,attr,v) :
v=v,permissionEff(AttributeAsset(oG,attr,v),read)=allow
obf 1(v ), permissionEff(AttributeAsset(oG,att r,v),read)=obf u scate ,AttributeAsset(oG,attr,v)AAG}
Action
AAG:= AAG∪{AttributeAsset(oG,att,v)}
If (permissionEff(AttributeAsset(oG,att ,v),write)=deny)then
rule Additive PutBack Reference Priority 6
Precondition :: (MG(OAG,RAG,AAG), MF(OA F,RAF,AAF), permi ssi onEff)→{ReferenceAsset}
{ReferenceAsset(sG,ref,tG