Context-aware and Attribute-based Access Control Applying Proactive

Computing to IoT System

Noé Picard

, Jean-Noël Colin

and Denis Zampunieris

PReCISE Research Center, University of Namur, Belgium

FSTC, University of Luxembourg, Luxembourg

Keywords:

Internet of Things, Access Control, ABAC, Event Analysis, Proactive Computing.

Abstract:

ABAC allows for high ﬂexibility in access control over a system through the deﬁnition of policies based on

attribute values. In the context of an IoT-based system, these data can be supplied through its sensors connected

to the real world, allowing for context-awareness. However, the ABAC model alone does not include proposals

for implementing security policies based on veriﬁed and/or meaningful values rather than on raw data ﬂowing

from the sensors. Nor does it allow to implement immediate action on the system when some security ﬂaw is

detected, while this possibility technically exists if the system is equipped with actuators next to its sensors.

We show how to circumvent these limitations by adding a proactive engine to the ABAC components, that

runs rule-based scenarios devoted to sensor data pre-processing, to higher-level information storage in the PIP,

and to real-time, automatic reaction on the system through its actuators when required.

1 INTRODUCTION

Access control is an important part of today sys-

tems. Whether it is about physical access control or

software access control, it has become an essential

and critical element for most businesses. Over the

years, multiple models have emerged, like the rela-

tively recent model called Attribute-based access con-

trol (ABAC). The concept is not especially innova-

tive, but with the rise of Internet of Things (IoT) sys-

tems, the ABAC model could turn out to be very in-

teresting. In fact, IoT sensors allow for monitoring

and collecting data about the environment on which

access control might apply. Moreover, IoT actuators

provide a way for the system to interact with the phys-

ical world. With all the data that such a system can

provide, the ABAC policies could only be enhanced

(Rath and Colin, 2017).

However, some concerns arise when one tries to

apply those two concepts together. To make the

data coming from the sensors available to the ABAC

model architecture, a gap between two components

has to be ﬁlled, as we will demonstrate in Section 3,

and no straightforward solution could be found. Ide-

ally, the envisioned system would also interact with

the surrounding environment. Still, how to make this

interaction easier without implementing a completely

new system? These are the issues that we want to ad-

dress with the help of proactive computing. We intro-

duce a way to use the proactive computing paradigm,

through a proactive engine, to enhance the ABAC

model with an IoT system.

The rest of this paper is structured as follows. In

Section 2, the access control part is explained along

the ABAC model. Section 3 describes the conse-

quences of applying access control to an IoT sys-

tem. Section 4 explains how the proactive comput-

ing makes this application easier. The resulting ar-

chitecture, which derives from the ABAC model, is

described in Section 5. To illustrate how the proactive

engine would work in a such case, the Section 6 pro-

vides a direct use case example. Section 7 describes

how it can be extended to real working systems. Fi-

nally, Section 8 completes this paper with our conclu-

sions.

2 ATTRIBUTE-BASED ACCESS

CONTROL

Access control is used to deﬁne what a subject can

do or which resources it can access. Several models

for access control have been proposed in the literature

like, e.g., discretionary access control, mandatory ac-

cess control or role-based access control. In this pa-

Picard, N., Colin, J. and Zampunieris, D.

Context-aware and Attribute-based Access Control Applying Proactive Computing to IoT System.

DOI: 10.5220/0006815803330339

In Proceedings of the 3rd International Conference on Internet of Things, Big Data and Security (IoTBDS 2018), pages 333-339

ISBN: 978-989-758-296-7

 2019 by SCITEPRESS – Science and Technology Publications, Lda. All rights reser ved

333

per, we are concerned with the Attribute-Based Ac-

cess Control (ABAC) model. For an introduction to

ABAC, see for example (Hu et al., 2014).

The main goal of ABAC is to provide high ﬂexi-

bility in access control. For instance, it considers that

access control does not always only concern the iden-

tity and related roles of the subject trying to access a

resource. Indeed, additional information could inﬂu-

ence the access decision like the current state of the

subject, its actions or the environment. These data

are referenced as attributes in the ABAC terminology

and attributes are the building blocks of access con-

trol policies. Within those policies, attributes can be

combined in complex expressions.

2.1 ABAC Model Architecture

The underlying architecture to the ABAC model is

generally composed of three main components. The

Policy Enforcement Point (PEP) protects the services,

data, etc. on which access control is required. When

a subject wants to access a resource, the PEP inter-

cepts this request and translates it in an authorization

request understandable by the Policy Decision Point

(PDP).

The PDP is at the core of the architecture as is the

component that takes the ﬁnal decision (Deny/Permit)

regarding a request. This node often relies on two

sub-components. One is the Policy Repository Point

(PRP) which is responsible for making policies avail-

able to the PDP. The other one is the Policy Admin-

istration Point (PAP) that acts as the interface for sys-

tem administrators that allows them to create, edit or

delete policies.

Finally, the Policy Information Point (PIP) allows

the PDP to retrieve the current attribute values that are

needed for the computation of the policies. The rest

of this paper is mainly concerned by discussions and

proposals around the PIP.

2.2 XACML Standard

XACML (OASIS Standard, 2013) stands for eXten-

sible Access Control Markup Language. It has been

created as a standard by deﬁning a language and a

protocol to convey information about access control.

It is mainly based on ABAC, but it can also be spe-

cialized for other access control models like RBAC.

The XACML language gives the possibility to deﬁne

policies using XML notations. The standard proposes

a computation model to evaluate policies against ac-

cess requests which is based on the ABAC architec-

ture described in Section 2.1.

3 APPLYING ACCESS CONTROL

TO IoT

One of the strengths of ABAC is the possibility to use

a set of multiple and diverse attributes in the policies.

It is even more interesting if this set can be supplied

with data from an IoT system, because it can provide

lots of information through its sensors connected to

the real world.

3.1 Main Beneﬁts from this

Combination

As a simple example, one could think of a room

equipped with connected sensors that monitor tem-

perature, humidity, presence, and so on in the room.

If we store the data received by those devices in a

database available through the PIP, then we could

write XACML policies that allow or not the access to

the room (supposing that there are also connected ac-

tuators that (un)lock the room doors, see Section 3.2

and 4) that rely on the current contextual information

in the room.

A second additional beneﬁt is the possibility to

control how the database behind the PIP is supplied

with ﬂows of data. In XACML, there is no recom-

mended way to implement this database, so it allows

us to imagine a solution that processes the data com-

ing from the sensors before to store information in

the PIP. This way, by avoiding to use raw values from

the sensors that may not be relevant and/or by aggre-

gating several values into upper-level data, we could

enhance the coherence and the pertinence of the at-

tributes available to the set of policies.

3.2 Limits in Its Implementation

While ABAC offers great extensibility and ﬂexibility

compared to other access control models, developers

will face some of its limits when it comes to imple-

ment it in a real-world system.

For instance, knowing how to ﬁll the attribute val-

ues backing up the PIP might be as simple as inserting

information in a database, but who is responsible to

collect and store the data? It is not really a limit of the

ABAC model that we underline here, as it takes into

account the diversity of the attributes sources behind

the PIP by using it as an interface between the sources

and the PDP. But the concern is that if we heavily

base the access policies on environmental attributes,

it might be cumbersome to implement systems that

ﬁll the sources of the PIP.

Also, assuming one is using ABAC with an IoT

system, it surely desires to interact with the environ-

SPBDIoT 2018 - Special Session on Recent Advances on Security, Privacy, Big Data and Internet of Things

334

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, deﬁned 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 ﬁrst 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 ﬁve stages. (1) The

ﬁrst 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 ﬁll 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 Artiﬁcial Intelligence (AI),

those are predeﬁned, 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, speciﬁc 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

Figure 1: Enhanced ABAC model architecture.

5.1 Comply with the Standard

The access control part is delimited by the XACML

context frame. It follows the architecture described

in 2.1, the PDP receive the authorization requests and

deliver the decisions. To do so, it retrieves the poli-

cies applicable to the current request and evaluates

them. If the policies contains references to attributes

not available in the direct context – which will be al-

most always the case because we want to rely exclu-

sively on environmental attributes, the PDP asks the

PIP for the corresponding values.

Note that the PEP component is intentionally not

represented on the Figure 1, because usually there will

be several of them and it can be in many forms and at

different places across a system.

5.2 Enhanced Proactive Engine

The proactive engine described in Section 4.1 lacks

of one important feature: the communication with the

IoT system. Therefore, we chose to implement along-

side the engine a MQTT broker. MQTT (Message

Queuing Telemetry Transport) is a protocol based on

the Publish-subscribe pattern, where senders do not

know who they are sending messages to, but instead,

publish messages on topics. Similarly, the receivers

express their interest for a certain topic without know-

ing anything about the senders. For detailed informa-

tion about the MQTT protocol, see (OASIS Standard

Incorporating Approved Errata 01, 2015). In this way,

a rule inside the engine can subscribe to a certain topic

and thereby listen for new messages. This speciﬁc

type of rule has a buffer where the messages can pile

up to be processed afterwards.

Moreover, the proactive engine is connected to a

database, implicitly represented by the PIP on the Fig.

1. This allows any rule to insert or retrieve data from

it. The schema of the database is left to the devel-

opers, as it depends on the type of the information

contained in the MQTT messages, and therefore the

type of the sensors used.

5.3 Collect Data and Act on the

Environment

The ﬁnal important part is the IoT system (composed

of sensors and actuators). As hinted in Section 5.2,

the sensors can send their data (using speciﬁc topics)

to the MQTT broker embedded in the proactive en-

gine. The other way around, for actuators to receive

commands, the rules can also send messages through

the broker.

6 USE CASE EXAMPLE

To illustrate how our architecture works, this section

includes a straightforward example. Consider a sim-

ple server room equipped with temperature sensors

and a system to cool the place that we can utilize as

an actuator. The scenario – from the proactive engine

point of view – represented at the Figure 2 will moni-

tor the temperature and take actions.

The sensors send their data to the topics

sensors/temperature/X, where X is the identiﬁca-

tion number of the sensor. A rule in the proactive

engine, named SENSORS

TEMPERATURE

MONITORING

for example, could subscribe to the topic ﬁlter

sensors/temperature/+, meaning that this rule

SPBDIoT 2018 - Special Session on Recent Advances on Security, Privacy, Big Data and Internet of Things

336

SENSORS

TEMPERATURE

MONITORING

messages.size

TEMPERATURE

MAD

TEMPERATURE

COMPARE

TEMPERATURE

PIP

ACTUATOR

ADJUST

AIR

COOLING

TEMPERATURE

ABNORMAL

VALUES

ALERT

[> 2]

[== 2][== 1]

Figure 2: Use case example - Scenario structure.

will receive data from all temperature sensors. This

rule will always analyse the latest twenty messages re-

ceived, by clearing its messages buffer in the actions

step if necessary. If the messages buffer is empty, the

rule is not activated. If it has been, it creates other

rules according to the number of messages. Note that

this rule has a speciﬁc type or class inside the engine,

we could call it a MQTT rule. This type of rule is au-

tomatically cloned in the queue in order to always lis-

ten for new MQTT messages. The following pseudo

code describes its logic:

data acquisition: /

activation guards:

messages.size() > 0

conditions: /

actions:

if (messages.size() > N

TEMPERATURES

TAKEN

)

messages.subList(0, (messages.size() -

1) - N

TEMPERATURES

TAKEN).clear()

tempsToAnalyze = messages

rules generation:

if (getActivated())

size = tempsToAnalyze.size()

if (size = 1)

createRule(new TEMPERATURE

PIP(

tempsToAnalyze.get(0)))

else if (size = 2)

createRule(new TEMPERATURE

COMPARE(

tempsToAnalyze))

else

createRule(new TEMPERATURE

MAD(

tempstoanalyze))

From the SENSORS

TEMPERATURE

MONITORING

rule, there is one of the three following rules created.

If only one message was received, the created one is

the TEMPERATURE

PIP rule. Its purpose is to store in

the PIP the temperature value passed as a param-

eter. To do so, it veriﬁes if it is necessary to store

the value, i.e. if the difference between the current

stored value in the PIP and the value to store is greater

than a particular constant (MINIMUM

DELTA). If not,

the rule is not activated and nothing is stored. More-

over, if the difference is greater than another constant

(MAXIMUM

DELTA) and that the last temperature up-

date in the PIP was close enough, the value is consid-

ered as abnormal and a counter is incremented. This

rule is an example of how the proactive engine can

solve the ﬁrst limit presented in Section 3.2. In the

ﬁnal step, the rule ACTUATOR

ADJUST

AIR

COOLING

is created to take actions on the environment through

the cooling system by triggering some actuators.

data acquisition:

previousTemp = getPip().getTemperature()

lastTempUpdate = getPip().

getLastTemperatureUpdate()

activation guards: /

conditions:

Math.abs(currentTemp - previousTemp) >

MINIMUM

DELTA

actions:

if ((lastTempUpdate + INTERVAL) >

currentTime() && Math.abs(currentTemp

- previousTemp) > MAXIMUM

DELTA)

getEngineDB().

incrementAbnormalTemperature

ValuesCounter()

getPip().updateTemperature(temperature)

rules generation:

createRule(new ACTUATOR

ADJUST

AIR

COOLING

(temperature))

The rule ACTUATOR

ADJUST

AIR

COOLING ad-

justs the air-cooling system according to the

temperature value passed as parameter. Here, one

can observe that this rule solves the second problem

Context-aware and Attribute-based Access Control Applying Proactive Computing to IoT System

337

developed in Section 3.2 by acting on the environ-

ment.

data acquisition: /

activation guards: /

conditions: /

actions:

if (temperature < LIMIT

MIN) {

setAirCoolingLevel(AirCoolingLevel.LOW)

} else if (temperature > LIMIT

MAX) {

setAirCoolingLevel(AirCoolingLevel.HIGH)

} else {

if ((temperature - LIMIT

MIN) <= 2) {

setAirCoolingLevel(AirCoolingLevel.LOW

)

} else if (Math.abs(temperature -

LIMIT

MAX) <= 2) {

setAirCoolingLevel(AirCoolingLevel.

HIGH)

} else {

// Between LIMIT

MIN and LIMIT

MAX

setAirCoolingLevel(AirCoolingLevel.

MODERATE)

}

rules generation: /

The rule TEMPERATURE

COMPARE is created by the

rule SENSORS

TEMPERATURE

MONITORING when the

messages buffer has a size of 2. It compares two tem-

peratures values passed as arguments. If the differ-

ence between the two is not too high, the mean is

store. But it can also increment the abnormal value

counter if this difference is in fact too high.

When there are strictly more than 2 messages in

the buffer, it is the rule TEMPERATURE

MAD that is cre-

ated. This one uses a statistics measure called Me-

dian Absolute Deviation (MAD) to detect any abnor-

mal value. If one is actually detected, as before, a

counter is incremented.

These two last rules create the TEMPERATURE

PIP

when it is necessary to store a temper-

ature value in the PIP. Finally, the rule

TEMPERATURE

ABNORMAL

VALUES

ALERT is al-

ways present in the engine queue, because it watches

over the abnormal value counter and generates an

alert if this counter exceeds some threshold.

7 INNOVATIVE, PROACTIVE,

ABAC-BASED SECURITY

The example in Section 6 might seem simplistic, but

it was essential to introduce and illustrate the main

idea of this paper. However, it does not represent all

the extent of the model that we developed. In fact, ex-

tending it to a real working system is achievable and

has been already performed in a controlled testbed.

At the University of Luxembourg, a simulator rep-

resenting the IoT system of a “modular data center”

had been conceived to test a proactive engine with

multiple scenarios. It was mainly simulating the sen-

sors and the actuators of the system, to provide a kind

of sandbox in order to experiment with the proactive

engine. The results were conclusive, and prove that

the engine could work on larger system, due to its

ability to run several scenarios in parallel, in order to

handle multiple sensors and actuators.

More globally, the advantages of our enhanced

ABAC-based security model become clearer: First,

as seen in Section 6, the proactive engine can take

the role of ﬁlling automatically the PIP with sensors

data. The access policies can be more abstract, that is

to say the data stored as an attribute could have been

pre-processed, thus it is not necessary to be burdened

with low-level data in those policies. Secondly, the

actuators can be triggered spontaneously by the sce-

narios, all it requires is implementing rules that inter-

act with any of the actuators. Moreover, the coher-

ence of attributes can also be insured if the scenarios

are well-deﬁned. Finally, another key aspect is the

separation of concerns that allows the division in sce-

narios. With this concept it is possible to focus on one

type of data or actuators at a time, which also allows

a better maintainability and extendability.

8 CONCLUSIONS

Attribute-based access control applied to IoT system

can theoretically make a powerful combination. To

make it concrete, two limits were encountered: how to

effectively link the sensors data with attribute values

in the PIP and how to automatically and immediately

act on the environment when it is needed. In order

to overcome these, the proactive computing paradigm

reﬂected in a proactive engine turned out to be an

ideal choice.

With the concept of proactive scenario, we

showed how to provide data coming from the sensors

as a source of attributes for the ABAC model. More-

over, in these scenarios, the data can be pre-processed

and not just be raw values that a sensor provides,

hence allowing higher level data as attributes. Equally

important is the ability to take actions on the environ-

ment by sending commands from the proactive engine

to the IoT actuators.

This way of doing can be applicable to large sys-

SPBDIoT 2018 - Special Session on Recent Advances on Security, Privacy, Big Data and Internet of Things

338

tems with numerous sensors and actuators, as the en-

gine can run multiple and complex scenarios in paral-

lel, without performance issues. We believe that this

new application of proactive computing opens some

promising road towards taking full advantage of the

ABAC model and the Internet of Things at the same

time.

REFERENCES

Hu, C. T., Ferraiolo, D. F., Kuhn, D. R., Schnitzer, A., San-

dlin, K., Miller, R., and Scarfone, K. (2014). Guide

to Attribute Based Access Control (ABAC) Deﬁnition

and Considerations. Special Publication (NIST SP) -

800-162.

OASIS Standard (2013). eXtensible Access Con-

trol Markup Language (XACML) Version 3.0.

http://docs.oasis-open.org/xacml/3.0/

xacml-3.0-core-spec-os-en.html.

OASIS Standard Incorporating Approved Errata 01

(2015). MQTT Version 3.1.1 Plus Errata 01.

http://docs.oasis-open.org/mqtt/mqtt/v3.

1.1/mqtt-v3.1.1.html.

Rath, T. M. A. and Colin, J. N. (2017). Adaptive Risk-

aware Access Control Model for Internet of Things. In

Proceedings of the International Workshop on Secure

Internet of Things, in conjunction with Esorics2017,

Oslo.

Tennenhouse, D. (2000). Proactive Computing. Communi-

cations of the ACM, 43(5):43–50.

Zampunieris, D. (2006). Implementation of a Proactive

Learning Management System. In Proceedings of "E-

Learn - World Conference on E-Learning in Corpo-

rate, Government, Healthcare & Higher Education",

pages 3145–3151.

Context-aware and Attribute-based Access Control Applying Proactive Computing to IoT System

339