Conference PaperPDF Available

The security framework of Fed4IoT



The high number of IoT devices, and also their availability through the Internet, has made the topic of IoT virtualisation an emerging topic, which has gained a lot of interest from both academia and industry points of view. Fed4IoT is an H2020 EU-JPN Research Project, whose aim is precisely this one. Nevertheless, security, and more specifically authorisation or access control is a fundamental aspect that must be addressed, motivated by the increase of threats and attacks that the IoT domain has suffered. In this paper we propose the use of a distributed authorisation mechanism based on DCapBAC technology, to specifically deal with the IoT virtualisation aspect, in the scope of this project. This technology has proven its validity in the IoT domain because of its distributed nature and the flexibility of their authorisation policies.
The Security Framework of Fed4IoT
Pedro Gonzalez-Gil
Dept. Ingeniería de la Información y
las Comunicaciones
Murcia, Spain
Antonio F. Skarmeta
Dept. Ingeniería de la Información y
las Comunicaciones
Murcia, Spain
Juan Antonio Martinez
Odin Solutions
Alcantarilla (Murcia), Spain
The high number of IoT devices, and also their availability through
the Internet, has made the topic of IoT virtualisation an emerging
topic, which has gained a lot of interest from both academia and
industry points of view. Fed4IoT is an H2020 EU-JPN Research
Project, whose aim is precisely this one. Nevertheless, security, and
more specically authorisation or access control is a fundamental
aspect that must be addressed, motivated by the increase of threats
and attacks that the IoT domain has suered. In this paper we
propose the use of a distributed authorisation mechanism based on
DCapBAC technology, to specically deal with the IoT virtualisation
aspect, in the scope of this project. This technology has proven its
validity in the IoT domain because of its distributed nature and the
exibility of their authorisation policies.
Security and privacy Domain-specic security and pri-
vacy architectures.
iot, security, privacy, aaa
ACM Reference Format:
Pedro Gonzalez-Gil, Antonio F. Skarmeta, and Juan Antonio Martinez. 2020.
The Security Framework of Fed4IoT. In CCIoT’ 20: Workshop on Cloud Con-
tinuum Services for Smart IoT Systems, June 03–05, 2018, Waseda Univer-
sity, Tokyo, JP. ACM, New York, NY, USA, 6 pages.
The goal of Fed4IoT is to decouple developers from providers in the
IoT realm. It does so by virtualizing physical things, sensors, actua-
tors and other data sources by means of its virtualizing architecture:
]. It allows owners of heterogeneous IoT infrastructures to
share them with many IoT application developers, which can sim-
ply rent the Virtual Things and the IoT Brokers their applications
In such a scenario, with many more actors and with the mind
of further monetizing existing architectures by renting virtualized
Permission to make digital or hard copies of all or part of this work for personal or
classroom use is granted without fee provided that copies are not made or distributed
for prot or commercial advantage and that copies bear this notice and the full citation
on the rst page. Copyrights for components of this work owned by others than ACM
must be honored. Abstracting with credit is permitted. To copy otherwise, or republish,
to post on servers or to redistribute to lists, requires prior specic permission and/or a
fee. Request permissions from
CCIoT’ 20, November 16, 2020, Waseda University, Tokyo, JP
©2020 Association for Computing Machinery.
ACM ISBN 978-1-4503-XXXX-X/18/06.. . $15.00
parts of it, the case of security becomes even more important. ABAC
strategies have proved to be good candidates to express the nely
grained policies required for similar scenarios.
In this paper, we present the security architecture of VirIoT. It is
based on the DCapBAC [
] access control framework, a exible and
performant verson of the Attribute-Based Access Control (ABAC)
strategy, that relies on XACML for policy denition and evalua-
tion, that decouples the authorization request from the access to
the resource. It does so by utilizing an intermediary element; the
Capability Token, which enables the enforcement of policies in the
Policy Enforcement Point, without the need of access to the Policy
Decission Point, making the system more reliable, performant and
scalable; attributes especially well suited in the IoT Scenario.
The Cloud business has led in the past few years, to the massive
outsourcing of the IT infrastructures of many big capital compa-
nies. This rising trend and increase in both demand and available
services, has lead to another interesting market opportunity: IoT
Cloud Services. This way, many internet-capable small devices, can
be easily deployed everywhere for tasks such as equipment control
and resource tracking, without having to face the initial investment
in data handling infrastructure and communications.
2.1 IoT Cloud Services
IoT applications have sophisticated requirements in terms of coor-
dination across connected objects and cross-compatibility against
multiple clouds and networks. It is needless to say that these are
complex matters, that are ideal candidates to be addressed by spe-
cialized IoT platforms oered by a plethora of vendors and ICT
giants. From Intel IoT platform or Bosch IoT Cloud, passing through
systems integrators like IBM Watson IoT, to Google Cloud IoT, AWS
IoT and Microsoft Azure IoT, companies and individuals searching
for an IoT solution, have plenty to choose from.
All of the aforementioned IoT Cloud Services have similar ar-
chitectures. Usually, the rst layer begins with the phisical “Thing”
layer, followed for an “Edge” layer (being more or less explicity
depending on the specic technology), followed by a “Cloud” layer
and ending with a “Data” layer.
Again, in all of those IoT Cloud Services, the user is invited to
bring his/her own set of sensors and actuators to the vendor ar-
chitecture, where they are oered with many functions to analyse
data, integrate devices and inspect the resulting data via automated
dashboards. Together with those, usually come improved secu-
rity, scalability to the edge of billios of sensors and data messages,
exible deployment strategies and tools and SDKs for application
CCIoT’ 20, November 16, 2020, Waseda University, Tokyo, JP Gonzalez-Gil et al.
2.1.1 Dierences with Fed4IoT. The previously mentioned plat-
forms, mainly oer Cloud Services for the customer’s IoT devices,
extending their potential at a relatively low cost. Fed4IoT VirIoT,
instead, focuses on oering things as-a-service. With that, the de-
sired outcome is to acquire control of the ever-growing number
of devices already deployed in the eld and virtualising them. In
doing so, an scalable layer of horizontally share-able IoT resources
can be supplied to customers.
Another dierence brought by our focus on
is the adoption of the exible and standardized NGSI-LD data model,
based on property graphs, as the internal format for all IoT data.
This allows us to integrate information from an object or dierent
linked objects, coming from data sources owned and maintained by
heterogeneous and unrelated parties. Put in simple words, Thing
virtualization allows us to personalize, transform and translate data
from real Things, into objects that can be shared, used in novel
applications and rented by customers, creating a new, extended
market for those devices.
2.2 IoT Platforms and Brokers
IoT systems can be generally described as a set of interconnected
devices, handled by an IoT software platform. At the core, such
platforms usually rely on IoT Brokers: components exposing IoT data
and services of the conected devices though unied APIs and data
models. The usual ow of information in such Brokering scenarios
is that devices publish their data to the Broker, which in turn sends
it to the interested subscribers.
Two dierent IoT platforms have attracted much attention by
industry and academia alike, thanks to the endorsement received so
far by standardization bodies and industry. These two platforms are
oneM2M [
], and FIWARE [
]. Actually, a third IoT platform is
currently emerging, stemming from the FIWARE NGSI standard [
, thanks to the eort made by the ETSI ISG CIM workgroup,: NGSI-
LD [
]. This new standard is more powerful and exible, allowing
not only the description of context entities but also to dene rela-
tionships between them, by leveraging the JSON-LD (for Linked
Data) ability to express semantic information together with data.
2.2.1 NGSI-LD. Of special interest for this work, NGSI-LD [
] is
both an information model and an API. Currently being standard-
ized by the ETSI Industry Specication Group on cross-cutting
Context Information Management (ETSI ISG CIM), the Fed4IoT
project is actively contributing to its development.
NGSI-LD information model is a meta-model with three main
concepts: entities,properties and relationships. The assumption is
that the world consists of entities, which can be physical objects
like a car or a building, but can also be more abstract things like a
company or the coverage area of an WLAN access point. Entities
are identied via URI and type (e.g. a car of type
, with
identier urn:ngsi-ld:Vehicle:A4567).
Entities have properties, e.g. a
or a
, as well
as relationships to other entities (e.g.
Furthermore, properties and relationships can be annotated by
properties and relationships themselves, making for a powerful
and expressive tool capable of capturing a Property Graph, whose
concepts and relations are represented by the UML diagram in
Figure 1.
Figure 1: NGSI-LD concepts and relations.
Finally, in addition to the meta model, NGSI-LD denes a cross-
domain model, dening some geographic and temporal properties
(among other things) and providing the anchor for other ontologies
to be linked from/to NGSI-LD.
Cloud Computing decouples infrastructure providers from applica-
tion providers. The huge proliferation of web, mobile and machine-
to-machine applications is undeniably an eect of this decoupling.
Small/medium sized application providers can give vent to the
invention of new applications by being free from the burden of
maintaining and implementing complex ICT infrastructures; thanks
to Cloud Computing they can rent them.
While current IoT platforms focus on driving the data from the
origin to the destination, current Cloud Computing decouples in-
frastructure providers from application providers, by using a pool
of real ICT devices (servers, network switches, storage, etc.) to oer
virtual machines with congurable virtual hardware and operating
system (OS). Fed4IoT wants to bring a similar infrastructure/ap-
plication providers decoupling to the world of IoT, by introducing
“Virtual Things”. This parallelism is better captured in Figure 2, de-
picting the IoT virtualization paradigm that we are promoting.
Real ICT
Tenant Tenant
Cloud Provider
IoT Virtualization
Figure 2: IoT virtualization paradigm.
3.1 VirIoT
Fed4IoT system architecture, named the
platform, uses a
federated pool of
Real Things
(i.e. sensors and actuators), oering
Virtual Silos
(similar to a virtual-machine), containing a set of
congurable Virtual Things (similar to virtual hardware) and an
IoT Broker, exposing their data to the user. Virtual things emulate
The Security Framework of Fed4IoT CCIoT’ 20, November 16, 2020, Waseda University, Tokyo, JP
Real Things, processing data exchanged with real IoT devices, made
available through dierent infrastructure providers. The
is the piece of software responsible for the processing/virtual-
ization performed, and can connect with Real Things via dierent
technologies, such as:
, as well as
simple MQTT.
Things Virtual
data of real
data of
Virtual Things
IoT Broker
Bob's Real
Figure 3: vThings and vSilos.
Figure 3 shows an example of Virtual Things and Virtual Silos,
in which face detection and person counting applications (among
others) are featured. Virtual Silos are isolated environments, dedi-
cated to running applications for a specic tenant. Tenants can add
data coming from the platform’s Virtual Things, to his Virtual Silo.
Collectively, this data is exposed to the external world through a
broker technology of choice (an example of such could be MQTT
and FIWARE Orion Broker).
Figure 4: VirIoT system Architecture.
Figure 4 shows a broader view of the full VirIoT system architec-
ture, in which the two remaining central components of the system
are depicted: the
Master Controller
and the internal communica-
tions Pub/Sub System.
The Master-Controller is the main element of the VirIoT control
plane: manages deployment, conguration and delivery of new
components in the system, following requests from administrator
and tenants. To that end, it uses an underlying cloud/edge platform,
oering containers-as-a-service, such as Kubernetes. All system
state information, about Virtual Silos, Virtual Things, ThingVisors,
2" me t a ":{
3vT h in g in f o ,su ch as v Th i ng i de n ti f ie r ,
4we th er it is an a ct uat or ,etc...
6" da t a ":{
8NG SI -L D En t it y 1,
9NG SI -L D En t it y 2,
10 ..
11 ]
12 }
13 }
Figure 5: Structure of the neutral-format messages
etc. is stored in a System Database, making the Master Controller a
stateless component.
Internal communications in VirIoT, are split into control plane
and data planes, both of which are based on MQTT protocol. The
reasons behind this architectural decision are manifold, one of the
most important being that there are implementations of MQTT
that support clustering (e.g. VerneMQ), a feature that suits the dis-
tributed cloud/edge infrastructure of VirIoT. The data format of
choice for the internal communications in VirIoT, coined “
” in the project, is based on the NGSI-LD data-model, mak-
ing it easy to translate to/from the dierent formats used by IoT
Brokers and Sensors respectively. Figure 5 represents the basic
structure of a neutral-format message.
Lastly, the System vSilo (depicted in Figure 4)is a special kind of
Virtual Silo, owned by the administrator of the VirIoT platform. It
contains all of the data produced by the platform and its mission is
to make it accessible to external systems that may want to connect
with VirIoT, eectively enabling the federation of VirIoT systems.
Security is a dimension of paramount importance, and as such has
been considered in the Fed4IoT project. As a start point, we need
to take into consideration that we are dealing with an architecture
which has many external interaction points, being:
: receives data from providers, transform and
push them into the federated architecture. They can send
commands to data root domain too.
Virtual Silo
: receives the updated information from ThingVi-
sors and transform it again according to the end-user needs.
It can also send commands back to the ThingVisors, upon
tenant request.
: oers an API to deploy and congure
the system.
System Silo
: supports external communications (e.g. with
other platforms, for federation).
4.1 Distributed Capability-Based Access
Control (DCapBAC)
DCapBAC is the access control mechanism proposed in our architec-
ture. It supports the management of certicates, authentication and
CCIoT’ 20, November 16, 2020, Waseda University, Tokyo, JP Gonzalez-Gil et al.
authorization processes. It also oers benets in terms of distributed
management and suports delegation and traceability, among others.
DCapBAC integrates both an Identity Manager (
), and the
eXtensible Access Control Markup Language (
) framework.
The IdM is responsible for storing the identities that can interact
with the system as well as its related attributes; which dene that
identity, such as name, email, organisation or roles (to name but a
few). Later, XACML, thanks to its nely-grained dened policies
and its processing model (which describes how to evaluate access
request according to the previously dened policies) will use those
attributes during the authorization evaluation process in order to
emit a verdict.
The main advantage presented by DCapBAC, is that it decouples
the authorisation process into two dierent phases: one for request-
ing access control to a specic resource, and another for accessing
it. In this manner, after the requesting phase, the user or service
receives authorisation in the form of a Capability Token (
). This
CT, which has a limited life-span, is used during the access phase.
4.1.1 Identity Manager. The Identity Manager (IdM) is implemented
by FIWARE’s Keyrock General Enabler. It oers a complete API
for authentication, based on the OAuth 2.0 protocol (described in
the RFC6749 standard). This protocol supports several methods
for a client application to acquire an access token, including Au-
thorization Codes and user/password schemes among others. An
access token can later be used to authenticate requests to API end-
points. An example of such, could be the specic API endpoint
of the VirIoT Master-Controller. Following, a list of the dierent
methods of authentication oered is included for completeness:
Authorization Code
, for apps running on a web server.
The client will redirect the user to the authorization server,
and then the user will be asked to login to the authorization
server for client approval.
, for logging in with the traditional username and
password scheme.
Client credential
, the simplest of all of the OAuth 2.0
grants, this grant is suitable for machine-to-machine authen-
tication where a specic user’s permission to access data is
not required.
Refresh token
, the access token eventually expires; how-
ever, some grants respond with a refresh token which enables
the client to get a new access token without requiring the
user to be redirected.
The IdM provides functionalities to achieve access within the
system, and to manage access privileges. Specically, the Keyrock
Identity Manager implementation denes the following actors and
. Any signed-up user who is able to identify itself with
an email and password. Users rights can be assigned individ-
ually, or by group.
. Any application consisting of a set of micro-
. A group of users who can be assigned a
series of rights. Altering the rights of the organization aects
the access of all users of that organization. Users within an
organization can either be members or admins. Admins are
able to add and remove users from their organization, while
members merely inherit the roles and permissions of an
organization. This allows each organization to be responsible
for their members and removes the need for a super-admin
to administer all rights.
. A role is a descriptive bucket for a set of permissions.
A role can be assigned to either a single user or an organi-
zation. A signed-in user gains all of the permissions from
all of her own roles plus all of the roles associated with her
. An ability to do something on a resource (e.g.
API endpoint) within the system.
. After a user has supplied her username
and password, the server returns an access-token in
As authentication’s example, Figure 6 shows a curl request for
obtaining an access-token via the
header, by per-
forming a username and password authentication. This request re-
turns a response with status 201 and the
containing the string representing the access-token.
1curl -iX POST 'https:/ / < ID M > :443/v1/ a ut h / to k en s '\
2-H 'C o nt en t - T yp e :a p pl i c a ti o n / j so n '\
3-d '{
4" na m e ":" user1@fed4i ot . o r g ",
5"password":"f ed 4i o t "
Figure 6: IDM authentication request
4.1.2 Authorisation. A classical DCapBAC scenario like that of Fig-
ure 7, showcases an entity (subject) willing to access a resource (e.g.
an API endpoint) of another entity (target). Usually, a third party
(issuer) generates a token for the subject specifying the privileges
that it has been given. Then, when the subject attempts to access
a resource hosted in the target, it attaches the token which was
generated by the issuer. Following, the target evaluates the token,
and grants access to the resource. Finally, the subject which wishes
to access certain information from the target, sends the token to-
gether with the request and the target device that receives such
token evaluates the validity of such request based on the token and
user information, acting as a Policy Enforcement Point (
). This
simplies the access control mechanism, and it is a relevant feature
in IoT scenarios, since complex access control policies are not re-
quired to be deployed on end devices, greatly improving system
performance and reliability.
4.1.3 VirIoT integration. Figure 8 shows the integration of this
access control technology to the VirIoT platform.
In a schematic way DCapBAC’s components are as follows:
Security enablers
based on XACML framework: Policy
Administration Point (PAP) and Policy Decission Point (PDP).
They manage access control policies, and decide who can
access a resource and what actions can be performed over it.
Policies are represented as triplets (subject, resource, action).
The Security Framework of Fed4IoT CCIoT’ 20, November 16, 2020, Waseda University, Tokyo, JP
Figure 7: DCapBAC scenario.
Capability Manager
Capability Token
). It takes
care of:
Access to authentication component to validate authenti-
cation token (returned by IdM).
Access to XACML framework for validating authorization
This component generates an authorization token, named
Capability Token, which is then required to access the re-
, which validates the authorisation. Before per-
forming any action the PEP-Proxy carries out validation, and,
if validation is passed, it then forwards the command/mes-
sage to the Master-Controller.
Under this scheme, tenants (or even administrators), in order
to interact with VirIoT for conguration (e.g. create a vSilo, add
a vThing, etc.) or maintenance purposes, go through the Identity
Manager (IdM) and DCapBAC components, rather than directly
accessing the Master-Controller API. The PEP_proxy has full sys-
tem administration rights, and directly interacts with the Master-
Controller, based on the request characteristics and whether they
are allowed according to the CT.
Figure 8: Security Relationships Components.
The sequence diagrams that follow, show the whole interaction
that a user/service must perform, in order to be granted access to a
specic REST resource of the Master-Controller API. After an au-
thentication process (Figure 9), the User receives an authentication
token. This must be later introduced in the authorisation query,
addressed to the Capability Manager (Figure 10). This component
is responsible for translating this request to XACML, and route it to
the XACML-PDP component. It validates the XACML authorisation
query by checking its stored XACML policy les. If a matching
policy is found, then the XACML-PDP will issue a positive verdict,
which is received by the Capability Manager. This, in turn, gener-
ates an authorisation token, called Capability Token which is sent
to the User.
Figure 9: Authentication.
Figure 10: Authorisation.
This Capability Token must accompany the query (Figure 11)
issued to the system, so that the PEP_Proxy can verify that the
query issued by the User is granted. This process is done without
querying any other third party, so it is a straightforward task. After
validating the query, the PEP_Proxy will forward the query to the
Master-Controller and later will forward back the response to the
As PEP_Proxy request example, Figure 12 shows how to access
the resource, using a curl request, through the
through the Capability Manager request. This request will return
the response of the specic Master-Controller API.
The use of Attribute-Based Access Control has proven a reliable and
expressive way of dening policies access control in information
systems. This is also the case for the VirIoT architecutre of the
Fed4IoT Project, where access to the Master Controller can be
CCIoT’ 20, November 16, 2020, Waseda University, Tokyo, JP Gonzalez-Gil et al.
Figure 11: Data access.
1cu r l -i X <a c ti o n > <'peppro xy endpoint ><resource >'
2-H 'x_auth_token :<capability_token >'\
3-d '. .. '
Figure 12: PEP_Proxy request - accessing to specic API
successfully controlled by the application of DCapBAC, successuly
decoupling the evaluation of the access request to a resource, from
the actual enforcement, by means of a Capability Token, that can
be evaluated in the Policy Enforcement Point without the need of
any further contact with the Policy Decision Point.
This approach, not only oers the added expressiveness of ABAC
for dening policies, but it also improves on performance and scal-
ability, becoming a great solution for highly dynamic and quickly
growing IoT scenarios. In this paper we have shown the dierent
steps required for the authentication, authorization and access to
resources of the Master Controller (main control point of the ViRIot
architecture) required by DCapBAC, and the integration of the
dierent elements of DCapBAC in the Fed4IoT architecture.
This work is supported in part by H2020 EU-JP Fed4IoT project(,
EU contract 814918)
[n.d.]. ETSI GS CIM 009. Context Information Management (CIM): NGSI-LD API.
[2] [n.d.]. FIWARE home page. https://www.
[3] [n.d.]. OMA, Open Mobile AllianceTM.
Soumya Kanti Datta, Amelie Gyrard, Christian Bonnet, and Karima Boudaoud.
2015. oneM2M architecture based user centric IoT application development. In
Future Internet of Things and Cloud (FiCloud), 2015 3rd International Conference on.
Andrea Detti, Giuseppe Tropea, Giulio Rossi, Juan A. Martinez, Antonio F.
Skarmeta, and Hidenori Nakazato. 2019. Virtual IoT systems: Boosting iot in-
novation by decoupling things providers and applications developers. Global IoT
Summit, GIoTS 2019 - Proceedings (2019), 1–6.
José L Hernández-Ramos, Antonio J Jara, Leandro Marín, and Antonio F Skarmeta.
2013. Distributed Capability-based Access Control for the Internet of Things.
Journal of Internet Services and Information Security (2013).
Hyuncheol Park, Hoichang Kim, Hotaek Joo, and JaeSeung Song. 2016. Recent
advancements in the Internet-of-Things related standards: A oneM2M perspective.
ICT Express (2016).
... Tenants can control and see only their vSilos, while the administrator can enrich the portfolio of vSilos and ThingVisors that the platform can offer. Finer access control schemes can be placed on top of the basic one as discussed in [29]. ...
Full-text available
Many cloud providers offer IoT services that simplify the collection and processing of IoT information. However, the IoT infrastructure composed of sensors and actuators that produces this information remains outside the cloud; therefore, application developers must install, connect and manage the cloud. This requirement can be a market barrier, especially for small/medium software companies that cannot afford the infrastructural costs associated with it and would only prefer to focus on IoT application developments. Motivated by the wish to eliminate this barrier, this paper proposes a Cloud of Things platform, called VirIoT, which fully brings the Infrastructure as a service model typical of cloud computing to the world of Internet of Things. VirIoT provides users with virtual IoT infrastructures (Virtual Silos) composed of virtual things, with which users can interact through dedicated and standardized broker servers in which the technology can be chosen among those offered by the platform, such as oneM2M, NGSI and NGSI-LD. VirIoT allows developers to focus their efforts exclusively on IoT applications without worrying about infrastructure management and allows cloud providers to expand their IoT services portfolio. VirIoT uses external things and cloud/edge computing resources to deliver the IoT virtualization services. Its open-source architecture is microservice-based and runs on top of a distributed Kubernetes platform with nodes in central and edge data centers. The architecture is scalable, efficient and able to support the continuous integration of heterogeneous things and IoT standards, taking care of interoperability issues. Using a VirIoT deployment spanning data centers in Europe and Japan, we conducted a performance evaluation with a two-fold objective: showing the efficiency and scalability of the architecture; and leveraging VirIoT's ability to integrate different IoT standards in order to make a fair comparison of some open-source IoT Broker implementations, namely Mobius for oneM2M, Orion for NGSIv2, Orion-LD and Scorpio for NGSI-LD.
Full-text available
Internet of Things (IoT) devices are likely to be developed by using different technologies and standards. Such IoT devices are being deployed in large numbers in various domains; thus, collaboration between standards bodies to provide interoperability is a key to the success of IoT. This paper describes a recent effort in oneM2M to broaden the IoT ecosystem. Semanticsenabled IoT platforms allow IoT devices to understand the meaning of IoT data in a standard way. oneM2M interoperability specifications guarantee that IoT devices from different vendors can communicate with each other. Additionally, an interworking framework bridges different IoT technologies.