,(((:LUHOHVV&RPPXQLFDWLRQVDQG1HWZRUNLQJ&RQIHUHQFH :&1&
Secure IoT-based Emergency Management System
for Smart Buildings
Olfa Dallel
2021 IEEE Wireless Communications and Networking Conference (WCNC) | 978-1-7281-9505-6/20/$31.00 ©2021 IEEE | DOI: 10.1109/WCNC49053.2021.9417343
NOCCS Laboratory NOCCS Laboratory
National Engineering School of Sousse National Engineering School of Sousse National Engineering School of Sousse
University of Sousse, Sousse, Tunisia University of Sousse, Sousse, Tunisia University of Sousse, Sousse, Tunisia
olfa.dallel.noccs@gmail.com souheil.benayed@gmail.com
Abstract—IoT-based emergency management systems are de-
signed to help emergency teams rescue people and property by
integrating IoT technology. The IoT devices communicate with
each other using the MQTT protocol by publishing relevant
information and being subscribed to topics in the MQTT broker.
Sharing data requires guaranteeing the access to only the autho-
rized MQTT clients. To secure access to the broker topics during
emergency situation, an access control mechanism is imperatively
required. Existing access control mechanisms enforce the access
control and may include the delegation of permissions without
involving a mechanism to control the delegation operation. In
this paper, we proposed an XACML-based Access Control and
Delegation (XACML-based ACD) mechanism that enforces the
access control as well as the delegation control. Our mechanism
involves a new decision point, called Delegation Decision Point
(DDP), which evaluates delegation control policies. The evaluation
process is based on new rule-combining algorithms that integrate
the delegation features: validity, depth and number of delegatees,
and a new policy-combining algorithm called first-delegable. We
implemented a testbed for the XACML-based ACD mechanism.
The results show that our decision-combining algorithms are
performant and the DDP evaluation delay is optimal, and
therefore, suitable for IoT-based systems.
Index Terms—IoT-based emergency management system, Ac-
cess control and delegation, MQTT Broker.
I. I NTRODUCTION
Around the world, governments impose to deploy an
emergency management system in public buildings. Building
Automation System (BAS) for emergency management are
widely used to predict unforeseen emergency situations (e.g.
fire, earthquake) and ensure the safety of the building occu-
pants. However, these systems are not reliable and can trigger
false alerts. In addition, emergency teams (e.g. firefighters, po-
lice, evacuators, emergency care team) have been coordinated
and communicated through Very High Frequency (VHF) radio
in emergency situations. This communication cannot give a
real vision about the critical situation inside the building,
neither the locations of the trapped occupants and therefore
inhibits the help and support efforts. The Information and
Communication Technologies (ICT) came to overcome these
issues by introducing Internet of Things (IoT) devices (e.g.
flame and temperature sensors, smoke detector and security
cameras), communication technologies such as WiFi and Long
Range (LoRa) technologies, as well as protocols such as the
Message Queuring Telemetry Transport (MQTT) protocol [1]
978-1-7281-9505-6/21/$31.00 ©2021 IEEE
Authorized licensed use limited to: Univ of Calif Santa Barbara. Downloaded on June 25,2021 at 08:39:13 UTC from IEEE Xplore. Restrictions apply.
Souheil Ben Ayed Jamel Bel Hadj Taher
NOCCS Laboratory
belhadjtahar.jamel@gmail.com
which meets the IoT device features. Emergency management
systems are enhanced by offering services such as Emergency
Communication Center (ECC) notifications, damage danger
map that shows the damaged areas in the building [2], evacuees
localization service [3], as well as real-time evacuation paths
[4] during emergency evacuation.
During rescue operations, real time data (e.g damaged area,
locations of evacuees) have to be collected from the smart
building sensors and be accessed by the emergency teams in
order to make critical decisions and save lives and property.
The shared data security requires guaranteeing the access to
only authorized emergency members. Several access control
mechanisms are proposed [5] [6] [7] to secure data shared
in the MQTT brokers. However, in emergency situation, the
emergency teams have no access permission associated to
them, thus, the ECC, holding access rights for the emergency
system data, can delegate specific permissions.
Delegation consists of sharing permissions with delegatees.
It can happen for various reasons such as the delegator is
unable to perform some tasks or the delegator wishes to
share some tasks with sub-users. Two types of delegation
exist: grant and transfer. Granting permissions consists of
devolving them to the delegatee while maintaining the same
permissions for the delegator. Transferring permissions means
moving them to the delegatee while revoking them from
the delegator. A delegator may, temporarily or permanently,
share his permissions with sub-users through delegation. The
delegator can either offer all of his access rights or restrict
them under specific conditions. Therefore, a mechanism to
ensure and control the delegation operation is required.
In this paper, we propose an access control and delegation
mechanism for a secure IoT-based emergency management
system in a smart building. We aim to:
• Specify delegation control policies.
• Propose new decision algorithms to evaluate the delega-
tion control policies.
• Integrate the delegation control into the eXtensible Ac-
cess Control Markup Language (XACML) architecture
(i.e. the standard access control mechanism proposed
by OASIS Consortium [8]) by adding a new entity
responsible of evaluating the delegation control policies.
 ,(((:LUHOHVV&RPPXQLFDWLRQVDQG1HWZRUNLQJ&RQIHUHQFH :&1&
This paper is structured as follows. In section II, we cite re-
search works related to the IoT-based emergency management
systems and access control mechanisms for MQTT brokers
since there is no paper which proposes a delegation mechanism
for MQTT protocol and bridging brokers. In section III, we
introduce an emergency management system based on MQTT
broker bridging in a smart building. To ensure the control
of access permission delegation, we discuss the delegation
specification language and the capability structure of our
delegation policies in section IV and in section V respectively.
In section VI, we describe our XACML-based Access Control
and Delegation (XACML-based ACD) mechanism for our
emergency management system. We give details about access
control enforcement in section VII and delegation operation
control in section VIII. In the last section, we discuss the
performance evaluation results of the delegation mechanism
based on our new policy- and rule- decision algorithms.
II. R ELATED W ORKS
To our knowledge, there is no paper which proposes a dele-
gation mechanism for MQTT protocol and broker bridging. In
this section, we review the IoT-based emergency management
systems and access control mechanisms for MQTT brokers
since we will introduce an access control and delegation
mechanism for MQTT brokers by adopting an IoT-based
emergency scenario in a smart building.
A. IoT-based Emergency Management Systems
Several researchers proposed improvements for emergency
management systems by integrating IoT technologies. Kodali
and Yerroju [9] proposed an emergency response system for
fire hazards which is used to detect the hazard and alert
the emergency rescue organizations by designing an IoT
standardized structure. The proposed system includes IoT
sensors (e.g. flame detection sensor, smoke detection sensor,
and flammable gas detection sensor), a GPS module, a Wi-
Fi connection, and the MQTT protocol for fast and reliable
communication. Thanks to IoT real time data, Zualkernan
et al. [3] proposed advanced services such as evacuation
pathfinding service and evacuees localization service during
fire incident. Al-Nabhan et al. [4] proposed an IoT-Cloud-
based emergency evacuation solution which determines real-
time evacuation paths during emergency evacuation. Felice
et al. [2] proposed mobile applications such as a map that
shows the damaged areas in the building. In addition, rescue
teams require communications and coordination to evaluate the
critical situation and make decisions. For this goal, Ben Arbia
et al. [10] proposed to equip the rescue team members with
on-body sensors connected to a smart phone via Bluetooth
and focused their researchers on proposing a routing protocol
and payload applications. However, all of these researches
do not integrate the security of real-time data exchanged
during emergency incidents. Tran et al. [11] proposed a RFID-
based secure mobile communication framework for emergency
response management. They introduced an emergency Role
based Authentication/Authorization Protocol (eRAAP) and
Authorized licensed use limited to: Univ of Calif Santa Barbara. Downloaded on June 25,2021 at 08:39:13 UTC from IEEE Xplore. Restrictions apply.
integrated a Role-Based Access Control (RBAC) model in
order to enforce the user access control. Nonetheless, RBAC
model can not be efficient for a large scale systems such as
IoT-based systems.
B. Access Control Mechanisms for MQTT Brokers
The default MQTT implementations such as the mosquitto
[5] uses an Access Control List (ACL) configuration file
to control the access to the broker topics. However, ACL
requires to be managed in order to add, update and remove
the access policies. Enforcing the access using the ACL can
not be applied in public smart building including tempo-
rary users. Gabillon et al. [6] proposed an access control
mechanism based on XACML and Attribute-Based Access
Control (ABAC) model for IoT messages in order to regulate
publications and subscriptions, and distribution of messages to
subscribers. However, it is limited to access control without
integrating the delegation of access permissions. Colombo and
Ferrari [7] proposed access control monitor which operates as
a proxy between the MQTT clients and the MQTT broker in
order to enforce access control constraints by intercepting and
possibly manipulating the flow of exchanged MQTT control
packets. This mechanism is based on the ABAC model and
can support other access control models. However, it is limited
to only one MQTT broker and is not extended to a bridge of
brokers. In addition, the delegation is not handled in this work.
III. S ECURE E MERGENCY M ANAGEMENT S YSTEM USING
MQTT B RIDGING B ROKERS
In this section, we describe our proposed XACML-Based
Access Control and Delegation mechanism during an emer-
gency incident in a smart public building (as shown in Figure
1). The smart building is equipped with the emergency man-
agement system which is comprised of various sensors related
to emergency incidents such as flame sensor, temperature
sensor and smoke detector. These sensors gather real time
data and publish it to the specified topics in the internal
MQTT broker (IMqttB). For example, the smoke detector
publishes the smoke level under the firstfloor/smoke topic;
the flame sensor publishes the location of the fire flame
under firstfloor/fire; and the temperature sensor publishes the
temperature values under the firstfloor/temperature topic. To
prevent being exposed to the internet, the IMqttB and IoT
devices in the smart building are isolated by setting up an
External MQTT Broker (EMqttB). A bridge connection is
established between the IMqttB and the EMqttB in order
to make remote users able to access the shared data in the
IMqttB.
During an emergency incident, the emergency management
system sends an alert notification about an emergency event
to the ECC which is already subscribed to all topics storing
data related to the incident in the IMqttB and can get access to
them through the EMqttB. The ECC dispatches the alert to the
responding agencies (e.g. rescue department, fire department,
police, and ambulance and healthcare emergency). Equipped
with their emergency infrastructures, the responding agencies
 ,(((:LUHOHVV&RPPXQLFDWLRQVDQG1HWZRUNLQJ&RQIHUHQFH :&1&
require relevant information to get better vision about the
building damaged areas, safe exits and evacuees locations.
The ECC delegates the required access permissions to data
required by every rescue team based on its emergency role
and missions.
In the following sections, we will describe the delegation
and access control mechanism through the MQTT bridge. A
delegation control mechanism requires a delegation control
policy specified in a policy specification language, a model
to present delegation policies and a mechanism to evaluate
policies and allow or deny the delegation operation.
IV. D ELEGATION C ONTROL P OLICY
An access control policy defines who is allowed to access
a specific resource to perform which actions under which
conditions. By analogy, a delegation control policy defines
the delegation actions (grant or transfer) that can be per-
formed by the delegator on his access permissions and under
which conditions. In order to improve the performance of the
delegation decision making, we need a lightweight, scalable,
distributed, extensible and well structured policy specification
language. XACML, proposed by OASIS Consortium [8], is a
standard and widely employed to specify policies. It makes
the system compatible with other platforms. However, it is
verbose and suffers from the syntax complexity. JSON-based
Access Control Policy Language (JACPoL), proposed by Jiang
and Bouabdallah [12], applies JSON syntax to encode policies
while reducing the size and complexity of a policy. It is simple,
lightweight, descriptive, scalable and expressive language.
Based on JACPoL and XACML comparison [12], JACPoL can
improve the performance and optimization of access control
policy evaluation. For these reasons, JACPoL is the more
suitable to specify our delegation policies.
V. D ELEGATION C APABILITY S TRUCTURE
Integrating ACL, RBAC [13], and ABAC [14] models in
access control mechanisms to protect a huge number of IoT
resources requires a large number of access policy lists, roles
and attributes respectively, leading to the explosion in the
number of lists, roles and attributes [15]. In addition, these
models require a much more effort to manage the access
policies, roles and attributes. In order to overcome these issues,
Capability-Based Access Control (CapBAC) model is used for
enforcing access control for high scalable systems such as
IoT systems. An access capability is a token or a key that
embeds access rights to an IoT resource. It is assigned to an
authenticated and authorized user.
To perform the control of the delegation operation, we in-
troduce a new capability called Delegation Capability (DCap).
A DCap is the proof that the user holds the right to delegate
his access permissions. It embeds capability information and
delegation control policies. The capability information include:
the capability identifier, the user identifier, the capability status
(enabled, disabled), and the capability validity. We adopt
the same policy model proposed by OASIS [8]. Delegation
policies are expressed as a policy set which includes a set
Authorized licensed use limited to: Univ of Calif Santa Barbara. Downloaded on June 25,2021 at 08:39:13 UTC from IEEE Xplore. Restrictions apply.
of policies, and a policy includes a set of rules. According
to XACML and JACPoL, an access target block contains the
subject, the object, the action and the environment. Since,
we propose to embed the delegation policies in the delegator
capability, the subject is already defined in the capability
information as the capability user. Therefore, we will omit
the subject from the target. A delegation target block includes:
the delegated permission identifier, the action and the environ-
ment. In the case that a delegatee receives multiple delegated
access permissions from several delegators, we propose to
encompass all the delegated permissions in a single access
capability, in order to avoid the creation of several access
capabilities related to the same delegatee. Encompassing all
delegated permissions is allowed since the delegatee and all
delegators belong to the same administrative domain.
Delegation operations (Grant and transfer) can be allowed
by satisfying both the contextual conditions (e.g. place, time)
and the delegation conditions which are:
• Delegation validity: Delegation can be temporary or
permanent. A temporary delegation is expressed by a
valid period of time during which the permission can
be delegated to the delegatee. Delegation validity can be
expressed as an interval of time limited by a starting date
and an expiration date, a period of time before a specific
date, or a period of time starting after a specific date. The
absence of the validity field means that the delegation
operation is permanent.
• Delegation depth: represents the number of times the
delegation operation can be performed by successor del-
egators. It is used to restrict further delegation operations
made by successor delegators.
• Number of delegatees: represents the number of dele-
gatees to whom the delegator can directly delegate his
permissions. It is used to limit the number of delegation
operation made by the current delegator to next delegatees
in the same level. If this field is ignored, the delegation
can be performed to any number of delegatees.
Figure 2 depicts our proposed delegation capability struc-
ture. Optional fields are marked with question marks.
VI. XACML- BASED ACCESS C ONTROL AND D ELEGATION
M ECHANISM
To perform the control of the access permission delegation
and enforce the access control to topics in the MQTT brokers,
we aim to extend the XACML mechanism [8]. We propose
an XACML-based Access Control and Delegation (XACML-
based ACD) mechanism which involves all the XACML
entities: Policy Enforcement Point (PEP), Context Handler
(CH), Policy Decision Point (PDP), Policy Administration
Point (PAP), Policy Information Point (PIP). To these entities,
we add a new entity called Delegation Decision Point (DDP)
in order to integrate the control of permission delegation
as illustrated in Figure 1. The DDP performs the control
of delegation operations by evaluating the delegation control
policies included in the delegator capability. It generates new
 ,(((:LUHOHVV&RPPXQLFDWLRQVDQG1HWZRUNLQJ&RQIHUHQFH :&1&

Fig. 1. XACML-based Access Control and Delegation mechanism for IoT-based emergency management system.

access control policies and adds them to the delegatee access
capability.
VII. ACCESS C ONTROL
Based on the MQTT client (publisher, subscriber) location,
we propose two types of access control: indoor access control
and outdoor access control.
A. Indoor Access Control
Indoor access control refers to an access enforcement for
a client who wants to publish / subscribe into the IMqttB
while he is inside the smart building. Once he is connected
to the IMqttB, the client sends a publish or subscribe request.
As shown in figure 1, the client request is intercepted by the
PEP of the IMqttB, which converts the request to an access
request and forwards it to the PDP via the CH. The PDP
retrieves the requester capability from the PAP, and inquires
the PIP for additional contextual information via the CH. The
PIP collects required data from multiple information sources
and returns these data back to the PDP via the CH. The PDP
evaluates access control policies extracted from the requester
capability along with the contextual information against the
access request, and returns the access decision (permit / deny)
to the PEP via the CH. If the access permission is approved,
the PEP forwards the client publish or subscribe request to the
IMqttB, otherwise, the client request is rejected.
B. Outdoor Access Control via the Bridge Broker
Outdoor access control refers to an access enforcement for
a client who wants to publish / subscribe into the IMqttB
while he is outside the smart building. The client request is
intercepted by the EMqttB. In the default configuration of
the bridge broker proposed by Mosquitto [5], the EMqttB
is subscribed to all the topics in the IMqttB. In this case,
if an attacker succeeded to get access to the EMqttB, he
can publish a large amount of invalid data, flood the broker
with messages, and cause a Denial of Service (DoS). Also,
he can subscribe to all topics in the EMqttB and gets the
confidential data of all the devices inside the smart building.
As mentioned in the MQTT specification proposed by OASIS
[1], ”an implementation should consider limiting access to
Topic Filters that have broad scope, such as the # Topic Filter.”

Authorized licensed use limited to: Univ of Calif Santa Barbara. Downloaded on June 25,2021 at 08:39:13 UTC from IEEE Xplore. Restrictions apply.
 ,(((:LUHOHVV&RPPXQLFDWLRQVDQG1HWZRUNLQJ&RQIHUHQFH :&1&
Fig. 2. Delegation capability structure.
For this purpose, we try to avoid that the EMqttB subscription
to all topics in the IMqttB by:
• considering the bridge broker (EMqttB) as an MQTT
client for the IMqttB.
• Enforcing the access control for the EMqttB as following:
an external MQTT client sends a publish request (or
subscribe) to the PEP of the EMqttB. This latter forwards
the access request to the XACML-based ACD mechanism
(as shown in Figure 1). The access control is handled
by the XACML-based ACD mechanism similarly as
mentioned in the indoor access control. If the access
Authorized licensed use limited to: Univ of Calif Santa Barbara. Downloaded on June 25,2021 at 08:39:13 UTC from IEEE Xplore. Restrictions apply.
decision returned by the PDP is permit, then the PDP
sends a delegation (i.e. grant) request to the DDP via the
CH. The DDP grants the client access permission to the
EMqttB by creating a temporary access permission which
is removed once the client is disconnected. In the other
hand, the PEP of the EMqttB forwards the publish (or
subscribe) request to the EMqttB which creates a new
publish (or subscribe) request and sends it to the PEP
of the IMqttB. This latter sends an access request to the
XACML-based ACD mechanism. The PDP extracts the
EMqttB capability from the PAP and looks for an access
permission granted by the requester client. If there is
no permission delegated by the client requester, then the
access is denied, otherwise the access is allowed.
VIII. D ELEGATION C ONTROL
To delegate his access permission, a delegator sends a
delegation request to the PEP of the MQTT broker which
forwards the request to the DDP via the CH (as shown in
Figure 1). The DDP extracts the delegator capability from the
PAP and checks the capability information (owner identifier,
validity, and status). If the verification operation is successful,
the DDP evaluates the delegation policies against the delegator
request and contextual information extracted from the PIP (via
the CH). If the capability verification and the delegation policy
evaluation failed, the delegation operation is not allowed and
the delegation request is rejected. Otherwise,
• for grant operation: the DDP inquiries the PAP for the
delegatee capability, appends granted permission to the
capability if this latter exists, otherwise, a new capability
that embeds the granted permission is created, signed
with the delegator signature and assigned to the delegatee.
Lastly, the DDP stores / updates the capability into the
PAP.
• for transfer operation: the DDP inquiries the PAP for the
delegatee capability, appends transferred permission to
the capability if this latter exists, otherwise, a new capa-
bility that embeds the transferred permission is created,
signed with the delegator signature and assigned to the
delegatee. In addition, the DDP removes the delegated
permission from the delegator capability and stores /
updates the delegatee and delegator capabilities into the
PAP.
In the following subsections, we will describe the evaluation
of delegation policies and rules made by the DDP.
A. Delegation Policy Evaluation
Our XACML-based ACD mechanism supports the ”permit-
overrides” and ”first-applicable” combining algorithms illus-
trated in the XACML specification 3.0 [8], and the ”highest-
priority” combining algorithm proposed by Jiang and Bouab-
dallah [12]. In addition, we propose a new policy-combining
algorithm called the first-delegable combining algorithm. This
latter allows the delegation based on the first policy that
permits the delegation operation. This policy is determined
based on the delegation rule evaluation.
 ,(((:LUHOHVV&RPPXQLFDWLRQVDQG1HWZRUNLQJ&RQIHUHQFH :&1&

B. Delegation Rule Evaluation first-delegable, first-applicable, highest-priority, permit-

The delegation rule evaluation consists of calculating the
effect. The effect is determined by:
• evaluating the matching between the rule target and the
delegation request target.
• determining if the permission-to-delegate is delegable
(satisfies the delegation conditions).
• evaluating all the contextual conditions which need to be
satisfied.
The target matching and contextual conditions are evaluated
similarly as mentioned in the XACML specification [8].
In case there is a set of delegation rules needed to be
evaluated, we propose new rule-combining algorithms that
combine the rules in order to obtain one single authoriza-
tion decision. These combining algorithms are based on the
delegation properties: the delegation validity, the delegation
depth, and the number of delegatees. We choose the delegation
validity in order to control the delegation period, and the
delegation depth and number of delegatees in order to restrict
further delegation operations. Table I shows our new rule-
combining algorithms.
If multiple rules have either the same delegation validity,
or the same delegatee number, or the same delegation depth,
we propose the first-delegable as a rule-combining algorithm
which applies the first rule where the effect value is permit.
TABLE I
RULE - COMBINING ALGORITHMS
Rule-combining algorithm Role
Maximum-delegation- Returns the decision of the rule that has
validity the maximum lifetime.
Minimum-delegation- Returns the decision of the rule that has
validity the minimum lifetime.
Greatest-delegation- Returns the decision of the rule that
number allows to delegate the permission to the
maximum number of delegatees.
Least-delegation-number Returns the decision of the rule that
allows to delegate the permission to the
minimum number of delegatees.
Highest-delegation-level Returns the decision of the rule that
allows the maximum number of times
the delegation operation can be further
performed by the successor delegators.
Lowest-delegation-level Returns the decision of the rule that
allows the minimum number of times
the delegation operation can be further
performed by the successor delegators.
IX. T EST AND E VALUATION
In order to test and evaluate the delegation processing of our
XACML-based ACD mechanism, we implemented PEP, CH,
DDP, PAP and PIP entities using java programming language.
We tested and evaluated our mechanism by varying:
• the delegation depth from 1 to 20.
• the policy scale: we varied the number of delegation
policies from 5, 10, 50 to 100 in the delegation capability,
and applied various policy-combining algorithms (i.e.
overrides).
• the policy depth: we varied the number of delegation
rules from 5, 10, 50 to 100 in the delegation capability,
and applied various rule-combining algorithms (i.e.
maximum-delegation-validity, minimum-delegation-
validity, greatest-delegation-number, least-delegation-
number, highest-delegation-level, lowest-delegation-level,
first-delegable, first-applicable, highest-priority, permit-
overrides).
All tests are repeated 1000 times and performed on Ubuntu
OS with 8GB of memory and Intel Core i7, up to 3.5Ghz.
We calculated the delegation evaluation processing delay of
20 consecutive delegation requests.
Figure 3 shows the evaluation delay using the first-delegable
policy-combining algorithm. The delegation processing delay
does not exceed on average the value of 20ms for 20 con-
secutives delegations when evaluating 100 policies. Increasing
the number of policies from 10 to 100 results in insignifi-
cant increase in the policy evaluation processing delay from
11.19ms to 19.10ms. Figure 4 presents the evaluation delay
using highest-delegation-depth rule-combining algorithm. The
delegation processing delay does not exceed on average the
value of 13ms for 20 consecutives delegations when evaluating
100 rules. Increasing the number of rules from 10 to 100
results in insignificant increase in the rule evaluation pro-
cessing delay from 7.96ms to 12.60ms. Figure 5 describes a
comparison of process delay for policy-combining algorithms:
first-delegable, first-applicable, highest-priority, and permit-
overrides for 100 policies. Our proposed algorithm first-
delegable requires approximately the same delay to process
a delegation request in comparison with the highest-priority
and permit overrides. However, the first-applicable combining
algorithm requires less delay since it returns the decision of
the first applicable delegation policy which can not be always
the suitable policy to apply. We can conclude that our policy-
and rule- combining algorithms can be applicable for scalable
and real-time IoT systems.
X. CONCLUSION AND FUTURE WORK
In this paper, we proposed a new XACML-based Access
Control and Delegation (XACML-based ACD) mechanism
which combines both the delegation operation control and
the access control. Our mechanism extends the XACML
architecture by adding a new decision point called Delegation
Decision Point (DDP) which performs the delegation control
based on delegation control policies. Delegation policies are
expressed in JACPoL specification language and embedded in
a delegation capability assigned to the delegator. We proposed
new decision algorithms to evaluate delegation policies and
rules. Our evaluations show that our new rule- and policy-
combining algorithm are optimal and can be applicable for
IoT systems. As a future work, we plan to add a dynamic
delegation to our XACML-based ACD mechanism in order to
perform delegation operation when the delegator is absent.

Authorized licensed use limited to: Univ of Calif Santa Barbara. Downloaded on June 25,2021 at 08:39:13 UTC from IEEE Xplore. Restrictions apply.
 ,(((:LUHOHVV&RPPXQLFDWLRQVDQG1HWZRUNLQJ&RQIHUHQFH :&1&

R EFERENCES
[1] K. B. Andrew Banks, Ed Briggs and R. Gupta. (2019,
Mar.) MQTT version 5.0. [Online]. Available: https://docs.oasis-
open.org/mqtt/mqtt/v5.0/mqtt-v5.0.html
[2] M. Felice, L. Bedogni, and L. Bononi, “The Emergency Direct Mobile
App: Safety Message Dissemination over a Multi-Group Network of
Smartphones using Wi-Fi Direct,” in Proceedings of the 14th ACM
International Symposium on Mobility Management and Wireless Access,
MobiWac, Nov. 2016, pp. 99–106.
[3] I. A. Zualkernan, F. A. Aloul, V. Sakkia, H. A. Noman, S. Sowdagar,
and O. A. Hammadi, “An IoT-based Emergency Evacuation System,” in
IEEE International Conference on Internet of Things and Intelligence
System (IoTaIS), 2019, pp. 62–66.
[4] N. Al-Nabhan, N. Al-Aboody, and A. A. A. Islam, “A hybrid IoT-based
approach for emergency evacuation,” Computer Networks, vol. 155, pp.
87–97, 2019.
[5] R. A. Light, “Mosquitto: server and client implementation of the MQTT
protocol,” The Journal of Open Source Software, vol. 2, no. 13, May
2017.
[6] A. Gabillon, R. Gallier, and E. Bruno, “Access Controls for IoT
Networks,” SN Computer Science, vol. 1, no. 1, Jan. 2020.
Fig. 3. First-delegable policy-combining algorithm. [7] P. Colombo and E. Ferrari, “Access Control Enforcement within MQTT-
Based Internet of Things Ecosystems,” in Proceedings of the 23nd ACM
on Symposium on Access Control Models and Technologies, 2018, pp.
223–234.
[8] (2013, Jan.) eXtensible Access Control Markup Language (XACML)
version 3.0. OASIS Standard. [Online]. Available: http://docs.oasis-
open.org/xacml/3.0/xacml-3.0-core-spec-os-en.html
[9] R. K. Kodali and S. Yerroju, “IoT based smart emergency response
system for fire hazards,” in 2017 3rd International Conference on
Applied and Theoretical Computing and Communication Technology
(iCATccT), 2017, pp. 194–199.
[10] D. Ben Arbia, M. Alam, A. Kadri, and R. Attia, “Enhanced IoT-Based
End-To-End Emergency and Disaster Relief System,” Journal of Sensor
and Actuator Networks, vol. 6, no. 3, p. 19, Aug. 2017.
[11] T. Tran, F. Z. Yousaf, and C. Wietfeld, “RFID Based Secure Mobile
Communication Framework for Emergency Response Management,” in
IEEE Wireless Communication and Networking Conference WCNC, Apr.
2010.
[12] H. Jiang and A. Bouabdallah, “JACPoL: A Simple but Expressive
JSON-based Access Control Policy Language,” in The 11th WISTP
International Conference on Information Security Theory and Practice
(WISTP 2017), vol. 10741, Sep. 2017, pp. 56–72.
[13] D. F. Ferraiolo, J. A. Cugini, and D. R. Kuhn, “Role-Based Access
Control (RBAC): Features and Motivations,” in 11th Annual Computer
Security Applications Conference, Dec. 1995, pp. 241–248.
[14] X. Jin, R. Krishnan, and R. Sandhu, “A Unified Attribute-Based Ac-
cess Control Model Covering DAC, MAC and RBAC,” in Data and
Fig. 4. Highest-delegation-depth rule-combining algorithm.
Applications Security and Privacy XXVI, vol. LNCS-7371, Jul. 2012,
pp. 41–55.
[15] S. K. Pinjala and K. M. Sivalingam, “DCACI: A Decentralized
Lightweight Capability-Based Access Control Framework using IOTA
for Internet of Things,” in 5th IEEE World Forum on Internet of Things,
WF-IoT 2019, Limerick, Ireland, April 15-18, 2019, 2019, pp. 13–18.

Fig. 5. Policy-combining algorithms for 100 policies.

Authorized licensed use limited to: Univ of Calif Santa Barbara. Downloaded on June 25,2021 at 08:39:13 UTC from IEEE Xplore. Restrictions apply.