Page 87 - ITU Journal Future and evolving technologies Volume 2 (2021), Issue 5 – Internet of Everything

ITU Journal on Future and Evolving Technologies, Volume 2 (2021), Issue 5

way to connect COG‑LO applications, platforms (e.g., SIoT, intelligently select candidate objects, then contact the
smart road infrastructure) and various data sources etc., Cognitive Advisor to receive updated plans for the
on the grounds of the abstraction, adaptation and com‑ vehicles involved and inally initiate the negotiation
munication features of the MSB. The central point of the orchestration.
solution is its ability to continuously process streams of
events and to orchestrate upon event receipt the opera‑ 3.4 Security, privacy and trust
tions that should be carried out, by which entities and in
which order. The MSB as the core communication module of the sys‑
The data low management and orchestration solution of tem, enables access to both internal and external services
the COG‑LO system is based on the Apache NiFi integra‑ and information through a uni ied interface. In this con‑
tion platform [25]. Apache NiFi offers a visual command text, the mechanisms for security, privacy and trust cover
and control centre for designing, testing, deploying and all respective technologies, notably access and usage con‑
monitoring data lows. trol, cryptography and trust infrastructure. Speci ically,
In order to integrate heterogeneous data sources, the fol‑ COG‑LO provides a solution for identity management of‑
lowing data lows types have been speci ied: fering standard‑based means for authenticating COG‑LO
actors; a policy‑based access and usage control frame‑
• Pre‑Flow: transforms COG‑LO domain requests to work for regulating the circulation and usage of informa‑
data source speci ic requests. tion. It additionally provides an architecture with a stan‑
dard set of components, such as Policy Administration
• Post‑Flow: transforms the responses received by the
data sources from the data source‑speci ic model to Point (PAP), Policy Decision Point (PDP), Policy Informa‑
the COG‑LO domain model. tion Point (PIP) and Policy Enforcement Point (PEP) for
evaluating access control policies.
• Handler‑ low: handles domain requests as they are The COG‑LO platform adopts a token‑based authentica‑
received from the MSB and communicates with the tion solution offered by RedHat’s KeyCloak identity and
underlying data source e.g. a database. access management component [26], and is used for both
user authentication as well as component (service) au‑
• Producer‑ low: generates domain events after com‑ thentication.
municating with the underlying data source.
For what concerns the access control, COG‑LO adopts the
Outside of the context of a data connector the following Attribute‑based Access Control (ABAC) paradigm and is
data low types are de ined: established upon the XACML 3.0 language and reference
architecture. In particular, the starting point for incorpo‑
• Enforce‑ low: processes domain data in a way that rating ABAC authorisation functionality within the MSB
access control policies are applied to the data. has been extensible Access Control Markup Language
(XACML) that has been extensively used in academia and
• Orchestration‑ low: processes domain events and industry.
coordinates the chain of operations that need to be In line with the XACML reference architecture, the MSB,
performed in order to ful il given operational needs.
as the PEP, provides the mechanisms for enforcing the
In order for the MSB to respond to an incoming request, speci ied access and usage control policies when it comes
for example in a point‑to‑point communication scenario, to regulating message exchange between COG‑LO compo‑
the MSB basically builds chains of data low calls. nents, services or CLOs. The MSB interacts with the PDP
The COG‑LO data low management and orchestration so‑ by providing attributes obtained by the original request,
lution employs data lows to model the interactions be‑ with the latter transformed in the XACML format that the
tween COG‑LO components, enabling end users to create PDP can process.
custom data lows for handling incoming events e.g. traf‑ In the context of COG‑LO, AuthZForce [29] has been se‑
ic, emergency, general logistics events. This enables lex‑ lected as the policy decision engine as it implements the
ible integration of information systems and supports the OASIS XACML 3.0 core speci ication, and provides an API
realization of the COG‑LO vision: facilitating the creation to get authorisation decisions, based on authorisation
of ad hoc logistics collaboration by combining digital pro‑ policies, and authorisation requests from PEPs.
cesses with physical procedures taking place at the level Cryptography traditionally represents the bottom line of
of actual cargo and means of transportation. data protection. Therefore, COG‑LO puts in place a rich
In order to support pilot operations and drive business functional toolkit able to support all necessary crypto‑
scenarios a set of orchestrations have been deployed on graphic functionalities to foster data identiality. To
the COG‑LO platform. Their purpose is not limited to or‑ this end, the COG‑LO crypto‑engine leverages a plethora
der management, but also to provide support for acci‑ of cryptographic primitives, both symmetric and asym‑
dental events (e.g. vehicle breakdown) driving dynamic metric. Furthermore, COG‑LO adopts the advanced tech‑
rescheduling of daily deliveries. The orchestrations lever‑ nology of Attribute‑Based Encryption (ABE), targeting
age the Social Internet of Things for this task to the cryptographic enforcement of data disclosure policies
by leveraging the attributes assigned to entities, being
people or systems.

© International Telecommunication Union, 2021 75