ment through the sensors and the actuators. But there
is no way to be able to interact synchronously with
the environment just by using ABAC. One might say
that there is the mechanism of obligations, defined in
XACML as operations that should be performed by
the PEP when they are returned alongside the autho-
rization decision. But this only allows the PEP to have
an effect on the environment when a subject tries to
access a resource, not when something has changed
within the environment.
4 PROACTIVE COMPUTING AT
HELP
Before talking about how to address the limits laid
down in Section 3.2, using proactive computing, let
us first introduce it. In an article, Tennenhouse estab-
lished theoretically the basics of proactive computing
(Tennenhouse, 2000). He described it in regards with
his vision of the future of computing, namely the tran-
sition from “human-centered to human-supervised (or
even unsupervised) computing”. In other words,
human-centered computing can be referenced as in-
teractive computing, where a system being used by a
user is locked to wait for user actions. However, with
proactive computing, the human is no longer placed
in the loop, but above it.
4.1 Proactive Engine
At the University of Luxembourg, Zampunieris D.
and his team had developed a proactive engine that
follows the premises of proactive computing as de-
scribed by Tennenhouse: “working on behalf of, or
pro, the user, and acting on their own initiative”.
Without entering too much in the detail of the imple-
mentation, there are some key concepts to understand.
The engine is a Rule-running system (RRS), it ex-
ecutes rules at a certain frequency. With the concepts
of Rule, one can create a Scenario which is a dynamic
set of rules obeying some path.
Furthermore, a Rule is the basic element in the en-
gine and it can be subdivided in five stages. (1) The
first one is called Data acquisition. It is during this
stage that all the data, necessary to the proper exe-
cution of the following stages, is gathered. (2) The
activation guards stage acts like a trigger for the third
and fourth stages. It can be any type of boolean ex-
pression. (3) The purpose of the third stage, Condi-
tions, is to offer the possibility to perform more in-
depth tests on the context. (4) To effectively do some-
thing, there is the Actions phase, which provides a lot
of freedom as well as power, given that the system is
implemented in the Java programming language. (5)
Finally, the Rule Generation step concludes the exe-
cution of a rule and allows the creation of other rules,
or to clone itself to stay in the system.
To store the rules to be executed at each iteration
(or at a further one if it is impossible to execute all
of them in one iteration), the engine relies on a FIFO
queue. For more information about the other aspects
of the engine, see (Zampunieris, 2006).
4.2 Make the Combination Easier
In the Section 3.2, we laid down some limits of the
ABAC model, especially when it is applied to an IoT
system. These can be easily taken away using a proac-
tive engine in an effective way. In fact, a proactive en-
gine could fill the gap between an ABAC architecture
and an IoT system.
On the one hand, there is the concern about the
way to make attribute values, coming from sensors
data, available to the PDP. Of course, it is the purpose
of the PIP to make those available, but as stated be-
fore, it is just an interface between some data sources
and the PDP. The idea is to use some rules (ideally
multiple scenarios) to supply a particular source hold-
ing sensors data. But it would not just be raw data,
as it is possible to implement scenarios that some-
how (see Section 6 for an example) analyze, compute,
combine, etc. this data. Therefore, we can assure a
certain coherence and completeness in what we store
as attributes.
Before going further, note that the scenarios must
not be mistaken with Artificial Intelligence (AI),
those are predefined, nevertheless they can be multi-
ple and complex. Their sequencing is decided over a
period of time based on the events that have occurred.
Then, on the other hand, proactive computing
helps a lot when it is necessary to react on the actua-
tors of the IoT system. Like before, specific scenarios
could stay tuned for new events that require action(s)
and react as quickly as possible.
5 ENHANCED ABAC MODEL
ARCHITECTURE
To better understand how a proactive engine can han-
dle his two main tasks (assigned in Section 4.2), this
section explains the logical architecture that we came
up with. In the Figure 1, there are 3 important parts:
the access control part, the proactive engine and the
IoT system.
Context-aware and Attribute-based Access Control Applying Proactive Computing to IoT System
335