9.1 Introduction

Today, different devices are connected forming small networks and being an integral part of the Internet of Things (IoT). Such networks are typically designed to provide individual solutions for a certain purpose (e.g., environmental monitoring or health monitoring) [1–3]. Devices used potentially show a large heterogeneity concerning hardware and software, thus, a linking to specialized systems allows for analysis and visualization of the data collected. While such an approach exists for IoT, it does not exist for an integrated handling of user requests and network owners changing over time in support of (i) mobility, (ii) ownership and controlling of data, and (iii) updating privileges granted immediately. Thus, the Web‐based framework leads to the innovative and practical solution discussed here.

Many specific solutions exist to address mobility requests, while installing a dedicated application on the mobile device. This is considered to be a good solution, but these solutions typically pose special requirements to the device's operating system and can quickly exhaust the device's resources, while being in operation. Integrating energy‐saving mechanisms can solve the latter problem, but applications may still require memory. Thus, Web‐based solutions are considered highly appropriate, as they only require Internet access and a browser on the controlling devices. Furthermore, the code base in use must only be updated in a single instance, which reduces maintenance costs.

The demand on handling ownership aspects and control of data increases due to wider offers of third‐party services in support of analysis and visualization of data. Additionally, a possible misuse of unauthorized data access in IoT needs to be avoided. Thus, in combination with user demands, to be able to update privileges and to grant access to the data collected, challenges arise due to the situation that accesses granted to users can hardly be revoked or updated immediately, if at all.

WebMaDa, a Web‐based Management and Data Handling Framework, addresses the three aforementioned aspects (i)–(iii) for sensor networks in an integrated manner. The development started in 2014 with basic support of mobile access to sensor networks owned by a single user, while allowing for the visualization of data in a flexible and hardware‐independent manner [4]. WebMaDa was extended by addressing the general request of fine‐grained access management and pulling data in emergency cases [5]. The drawback was that each request (e.g., create networks, access foreign networks, view, or pull data) required an interaction with a global administrator, thus, maintaining a central control and introducing unnecessary delay into the system. WebMaDa 2.0 solved this deficiency by automating the request and allowing for an immediate access grant handling without the involvement of a global administrator [6]. Additionally, WebMaDa 2.1 also addresses the demand for privacy and controlling data access besides the pure automated processing of requests by forwarding to the respective contact points using a mailing system. This ensures that network owners hold the full control of data collected and receive full transparency of when and by whom data was accessed and which rights had been granted.

This chapter summarizes the current situation and concerns of users and network owners in IoT. In turn, it categorizes and discusses the requirements design of WebMaDa. Consequently, WebMaDa is presented in detail with the special focus on (i) the automated request handling and (ii) the addressing of data control with respect to privacy and transparency. The evaluation provides a proof of operation.

9.2 IoT‐Related Concerns

The IoT today includes many types of devices ranging from resource‐rich devices (e.g., Tablets, Notebooks, Servers) to devices with fewer resources (e.g., Smartwatches, Smartphones, Sensors). Both types collect a lot of data with high variety and, partially publish them using different technologies as shown in Figure 9.1. At first glance, this does not seem to be a big problem, but over time this has changed as the number of devices with fewer resources increased and can be placed everywhere, and as well as devices, owners become more and more mobile and travel around, but still want to stay in control of deployed devices out of their current range. Thus, the first request on mobility support arose.

Furthermore, users became aware of the fact that collected data can support profiling and predict habits. Both usually occur in the data flow as soon as third‐parties are involved (e.g., displaying data or storing data in the Cloud) leading to a loss of data control. This is contradictable to the expectations and definition of ownership, which was strengthened by the release of the General Data Protection Regulation (GDPR) [7] in May 2018 in Europe. Thus, the second request of IoT‐device users focuses on ownership support.

The third concern about immediate privilege update support follows the first two concerns directly. As users are more and more mobile, they have no direct contact to the deployed devices and also want to access them remotely, perhaps even giving specific people access to them and update granted privileges. In theory, this can happen easily, but here again a control‐loss happens, because the owners must trust a third‐party offering such an access management service and require an involvement of unknown persons (e.g., administrator) to react on requests in time. Where the timing issue might be critical, in some cases, like emergency cases or losing trust in people having access. Further, owners want to be kept informed about privilege changes and access to data that depend on the third‐party if it is done in time or even at all.

All these concerns can partially be addressed by third‐party services, but at the same time require full trustability that the service follows rules like those mentioned in the GDPR, for example, strengthen data subject rights, data protection officer in place, privacy‐by‐design and by‐default, and data breach notification [7]. Thus, WebMaDa was developed to address the aforementioned three concerns step‐wise until processes were automated sufficiently to reduce the involvement of administrators and giving data owners full control of their collected and published data. The upcoming section presents the design decisions taken leading to the establishment of the WebMaDa framework.

9.3 Design Decisions

Being aware of users' concerns and the devices they used (e.g., Smartphones, tablets) when traveling it was decided to develop a Web‐based solution to support network monitoring when absent from the place of deployment. This approach is highly recommended, as it will be operating system independent, will not require additional Apps to be installed on the mobile devices, and will also support code maintenance in one place only. In order to link the deployed network to the Web‐based framework, the data owner will first be required to register, providing unique credentials to a special framework CoMaDa (Configuration, Management, and Data handling) [8,9] which functions as a bridge between the deployed network and WebMaDa. The main responsibility of CoMaDa is to transmit collected data to a backend infrastructure providing the data to WebMaDa and storing the data and all access, as well as any data request placed in direction to the nodes in the network and received answers.

It was decided to have a MySQL database, called WebMaDa‐DB, in the backend infrastructure to log all kinds of information. Each user of WebMaDa is stored with contact information, as well as whether a network is owned or not. For each registered network having an unique identifier information of the network's topology, the individual nodes, the received data, and the network owner are stored. As also foreigners should get access to special networks granted by owners, the WebMaDa‐DB underwent an extension. New tables were integrated to store individual access rights to foreign networks and, to address the controlling request of owners, an exhaustive logging system was established storing all access including timestamps and the requested data.

In order to address the third user concern on immediate handling of requests, especially for privilege updates, an automated request handling was designed. This requires an Email system informing owners of placed requests for access on the one hand while, on the other hand, immediately notifying requestors about grants and denials. Thus, the administrator is only involved at the beginning when users request access to WebMaDa. When this has been granted, the users themselves can interact without any involvement of the administrator with the owners of another network. As a result, delays are reduced and owners can immediately take privilege decisions on their own. In order to be able to document Email communication the WebMaDa‐DB was required to be extended again to log the placed requests, the answers sent out, and the changed privileges.

The resulting data flow in an abstract way as shown in Figure 9.2 including four main components having the following purpose [5]:

• The network collecting data (here a Wireless Sensor Network (WSN)) is connected to CoMaDa.
• CoMaDa periodically processes data received from the network to forward the data to WebMaDa's backend. Therefore, it links the data to the unique credentials of the network, which in return, links the data in the backend to the corresponding tables. Furthermore, CoMaDa supports communication to the network received from WebMaDa to request immediate sensor readings.
• WebMaDa's backend stores all data received from CoMaDa, handles user and network registration, offers privilege management, supports automated request handling, logs all kinds of information, and offers the code and infrastructure for WebMaDa's frontend support. The backend itself is build by for items: (i) An Apache HTTP Server, called entry server, where all traffic to WebMaDa passes through working as a proxy server and terminating TLS connections before the traffic is forwarded to WebMaDa's components. (ii) A server hosting database of WebMaDa (WebMaDa‐DB) and (iii) an Apache HTTP Server, called Web server, hosting the final front‐end of WebMaDa. And (iv) an Apache Tomcat Server hosting the WebSocket end point.
• WebMaDa's frontend offers a user‐friendly graphical user interface (GUI) offering different functionalities like registration, data viewing, privilege request and adjustment, data request placements, and data filtering. The frontend is privilege‐sensitive constructed; meaning different functions are available depending on whether someone is a user or an owner.

9.4 WebMaDa's History

As mentioned in Section 9.2 users requested a solution supporting mobile access and interaction with their deployed networks. Thus, WebMaDa was developed offering user's the possibility to monitor their deployed network during their absence by using manifold devices. Until that time existing solutions to access sensor networks required a SmartCard solution issued by the administrator of each network [12–15]. This in turn brought several drawbacks: (1) User had to have carry additional card and special terminals were required to insert the card in order to authenticate and authorize the user before accessing the network. (2) Additional cost occurred due to SmartCard production and special terminals required. (3) For each network one administrator was required, needed to be available to issue SmartCards. And (4) the network owner lost control of the data, as they do not know why someone requested access and if it was gained assuming they did not function of administrator issuing the SmartCards themselves. All these drawbacks inspired the design and development of WebMaDa in order to develop a user-friendly solution to access networks when being far away with less involvement of an administrator, staying control of own data and granted privileges, as well as being flexible to extend WebMaDa with further features continuously.

WebMaDa 1.0 was released in 2014 [4] having a similar data flow in place as shown in Figure 9.2 with the only exception that the backend existed only of a Web‐Server and a database. Also, the communication ways between CoMaDa and WebMaDa instances were not secured at all. Included services allowing registration of users, monitoring the network by owners, viewing data received in raw format and in line charts, viewing network topology, and requesting access to foreign networks. WebMaDa's administrator was highly involved in the total system, as he/she was in charge when people wanted to use WebMaDa requesting access to the network by default and, on the other hand, when users request access to foreign networks. This situation introduced delays to the reaction time on handling requests in general, and the structure of the WebMaDa‐DB was limited to the essential tables logging access grants, network identifiers, network topology, data received, and information about link to the line charts provided by a third‐party service.

Due to the increasing awareness on security and privacy [1], WebMaDa underwent some modifications to address this over the next few years. The first security update was integrated by changing the visualization of data received from the network. Here the third‐party involvement was replayed by graph creation using Google Charts [9]. Here, the library is used to draw line charts without transmitting data to externals and, thus, the network owner stays in full control of his/her data collected. Furthermore, additional visualization functionalities became available like layering data and zoom in for a specific time period. The biggest security changes were performed in 2016 [5,11] by updating the backend infrastructure completely and securing the communication ways as illustrated in Figure 9.2. This secure communication includes (i) an user interface (cf. https://webmada.csg.uzh.ch) used to maintain and access WSNs after successful authentication, (ii) an upload interface (cf. https://upload.webmada.csg.uzh.ch) that can be accessed using HTTP POST and uses a set of well‐defined JSON messages to upload received data from CoMaDa, and (iii) an secure pull request interface (cf. wss://pull.webmada.csg.uzh.ch) used by WebMaDa to send pull queries to CoMaDa receiving immediate sensor reading. For further details to these interfaces it is referred to [5,11]. This infrastructural update was mainly caused by the user's wish to request data immediately instead of periodically as well as the greater security awareness arising about communication in general. As a result, WebMaDa itself was extended with a fine‐grained access management solution, more tables in the WebMaDa‐DB logging privileges in greater detail, and pull‐support in the frontend realizing the immediately data request. All these modifications resulted in WebMaDa 2.0 addressing the users' request on ownership and controlling of data, as well as granting privileges on their own and requesting immediate data [5,10]. However, the administrator is still involved in different stages:

• Privilege requests must be handled, as no direct contact possibility between owner and user exists.
• Network or data deletion is requested by owners as there exists no right to cause it directly.
• Controlling requests must be addressed manually, i.e. when an owner wants to know how to access the data and when.

Thus, WebMaDa 2.1 was developed addressing the concerns mentioned in Section 9.3 and reducing the involvement of the administrator as much as possible to improve reaction times of requests and to address the owner's requests on control and immediate privilege updating. The resulting solution includes an automated user request handling solution, mailing and notification solution, and an extension of the WebMaDa‐DB for controlling purposes.

9.5 WebMaDa 2.1

In order to address a data‐controlling request from a network owner, WebMaDa distinguishes between two stakeholder roles, namely “network owner” and “user.” Initially, everyone registering with WebMaDa is considered to be a “user.” As soon as a user registers his/her own sensor network, this role changes to “network owner” and unique credentials are received for this network identifying it within CoMaDa and WebMaDa. Automatically, corresponding tables are created in the backend linked to these unique credentials for the network and the network owner takes over the administrator activity for his/her network. The tables include, on the one hand, general information (e.g., topology, nodes, data received) and, on the other hand, special information like access privileges, placed requests, and accessed data. Up until now, the administrator was required to grant potential users access to WebMaDa and to handle request from owners to receive controlling information of their network. In previous versions of WebMaDa, the administrator stays now in charge of forwarding requests from users to network owners, including access requests and rights for foreign networks, as well as accessing the WebMaDa‐DB to query controlling questions and forward the results. All these steps introduced delays into the workflow as requests placed required immediate reaction from network owners and were time consuming for the administrator in cases many requests were placed at the same time. To overcome this, WebMaDa's 2.1 missions are to automate processes and to shift workload from the administrator directly to the respective entities (e.g., owners, database management).

9.5.1 Email Notifications

Including a mailing solution into WebMaDa solved the designed automation process of handling request. This was possible, as users needed to provide Email contact information to obtain access to WebMaDa. WebMaDa 2.1 includes Email notification in the process of handling (i) access request to WebMaDa, (ii) access request to foreign networks, and (iii) request for password reset. As PHPMailer1 offers a number of advantages (e.g., active community, good documentation, and extensive error handling) compared to PHP's built‐in feature; it was decided to use it here. Another advantage of PHPMailer was that most of WebMaDa was already implemented in PHP and, thus, the integration of the library can be considered a logical step on the one hand, while on the other, it also pays attention to security standards like Secure Sockets Layer (SSL)/Transport Layer Security (TLS) that were already included in WebMaDa 2.0 and should further be supported.

9.5.1.1 Access Request Handling to WebMaDa

It was decided to start the Emailing notification in the early stages of WebMaDa contact. This means, until version 2.0, potential users had to contact WebMaDa's administrator via mail or in person to receive invitation codes and credentials to create an account for WebMaDa. This situation required the administrator to periodically check his/her mail for an access request, then logging into a special admin interface and creating an invitation code that is manually sent back to the potential user, along with registration instructions. In turn, the potential user could use this invitation code to finalize the registration process and become an user of WebMaDa. With the now integrated Email notification solution, the potential user just needs to click a button within WebMaDa to start the registration process by announcing his/her mail contact and the reason for using WebMaDa. Figure 9.3 illustrates the complete process where envelopes stand for automated Email notifications.

As soon as a request was placed, the administrator received a notification via Email with the required information. After login to the admin interface, the request is either denied or accepted by clicking buttons, causing the corresponding notification to be sent out. In case of declination, it is a negative information (red marked envelope) and the potential user can issue a new attempt. In case of agreement, a positive answer (green marked envelope) is sent out including the automatic created invitation code and the instructions on how to continue with the registration. WebMaDa‐DB receives an entry on generated invitation‐code linked to the corresponding Email placing the request and a timestamp until it is valid. In both cases, new entries appear in the tables logging the Email traffic for controlling purposes. As soon the potential user receives a positive validation, the registration can be completed by using the invitation‐code and providing the required additional information (e.g., username, real name, affiliation, password) to create a unique account. In WebMaDa's backend, it is automatically checked if the invitation‐code is still valid. If yes, the information is stored in the WebMaDa‐DB where the password is stored for security reasons in a hashed version. In return, a notification is sent out to the requestor that the registration process was successfully completed and WebMaDa can be used. From this point on he/she holds the role of a “user.” Else the registration process must be initialized and performed again.

Now the user can register own networks following existing workflows from WebMaDa 2.0, which are already automated and do not involve actions by WebMaDa's administrator anymore [5]. Further, the user is able to place access requests to foreign networks that up to now would involve WebMaDa's administrator again by forwarding the request to the network owner. To erase this involvement, automated Email notifications are placed in this process as well.

9.5.1.2 Access Request Handling to Foreign Networks

In order to receive access to a foreign network the workflow shown in Figure 9.4 is processed. It is initiated by an authenticated user selecting a public available WSN of interest after login to WebMaDa 2.1. As each WSN is represented in WebMaDa‐DB with a unique identifier – the WsnId – each placed request from now on is linked to this unique identifier. In return, a list of available nodes in the selected WSN is presented in the frontend, where the user now selects the permissions he/she wants to request. As soon as the request is placed, an Email is automatically created including the information about the request and is directed to the network owner. The owner's Email contact is received from the WebMaDa‐DB by placing an automated processed query to look up the contact information via the unique WsnId of the selected WSN. The network owner receives a notification in his/her Email account that a permission request was placed to the owned WSN. After logging into WebMaDa, the owner can deny or grant the request. In the first case, an Email is automatically sent out to the requestor with the information that the permission request was denied. In the other case, the network owner can either directly approve the placed request or modify the permissions requested (e.g., adding further rights or limit request rights). Next, an Email is automatically generated and sent back to the user, who placed the request. In both cases, entries in the WebMaDa‐DB are made including information of changed permissions to the respective WSN and about the sent Emails. In return, the user receives a summary of the request processing, can agree on it, when the request satisfies his/her initial request continuing with accessing the data or start the process from the beginning again to ask for modified permission.

As it can be seen by the flow shown in Figure 9.4 and with the above description interaction by WebMaDa's administrator is no longer required for handling any access requests for foreign networks. Thus, the time required for receiving access is only triggered by the reaction times of the network owner his/herself. He/she is also able to update given rights on his/her own without involving the administrator at all and is able to inform the permission holder automatically by Email when granted rights are modified or revoked at any time.

9.5.1.3 Password Reset

In older versions of WebMaDa, the administrator was required to reset a password. Using the Email notification by meeting both security and usability requirements at the same time, now also optimizes this process. Due to security reasons, no standard password can be set and sent to the user via Email. A simple link with a randomized token to reset the password would also not suffice, as it would be possible to intercept this message and use the link. Thus, it was decided that the automated process includes the following steps:

1. A user requests a password reset link for a user account. In order to receive a password reset link, the user has to enter the Email address that is assigned to his/her user account.
2. After submitting the form, the user is informed that if the address is linked to an account, he/she will receive an Email.
3. Within WebMaDa's backend, it is checked if the address matches a user account registered.
   1. If not, no further action is done, not even an Email is sent as a response to the request.
   2. If yes, a randomized token is created and sent to the user. This token is only valid for one reset.
4. For the reset, the user is requested to enter the username and a new password. The username is requested because it is never mentioned together with the Email address and can, therefore, be used as a secure combination that is known only to the user itself.
5. The updated information is stored in WebMaDa‐DB and the user can log into WebMaDa with his/her new credentials.

9.6 Implementation

This section presents implementation details for the notification process, the logging, and the filtering in WebMaDa 2.1. All relevant scripts and files are fully integrated into the previous version of WebMaDa, both in the front‐ and backend. With these enhancements and modifications, WebMaDa 2.1 can now fulfill the wishes and requests of current users mentioned in Section 9.2. A corresponding proof of functionality is given in Section 9.7.

9.6.1 Mailing Functionality

As described throughout Section 9.5.1 WebMaDa 2.1 includes an automated notification solution to reduce the workload of the administrator and allow direct contact between involved stakeholders (here: users, owners). In order to realize this, a mailing solution was designed having the requirement of guaranteed maintainability of the implementation. Therefore, it was decided to implement only one script containing Email templates and to be able to send the corresponding messages matching the different answering types required (cf. Figures 9.3 and 9.4). As a result, all activities that a user can trigger (e.g., permission request, new user request) to deliver an Email, must have their requests sent to this central location and changes in the mail template are only required in one script and, thus, lower the maintenance costs. To solidify the mailing solution requires two PHP files: (i) mailConfig.php and (ii) mailFactory.php. [6]

The first file – mailConfig.php – contains all necessary configurations for the PHPMailer. It also includes the sender's Email account and all basic configurations like the host and port of the mail server used, as well as the login information and the Mail From name. By intention, this file should only be included once, namely in the mail factory script.

The second file – mailFactory.php – is responsible for routing different requests to the correct method and sends the corresponding mails. This means, that if a user wants to call this script, sending an Ajax POST request to the factory along with a purpose is required. This request includes all required information to route the request to the correct method via a switch case statement. If necessary, some additional data can be added to the request. In most cases, this is an object that contains the recipient's Email address and the body of the message.

Sending mails is triggered by user interactions via an input as described throughout Section 9.5.1. This means, the process starts with a JQuery action (e.g., click or change) by the user caused in WebMaDa's frontend. In the following, an example of requesting the deletion of an access request by a network owner is assumed to describe the implemented workflow. Figure 9.5 [6] illustrates the linkage of scripts and gathered inputs for this process.

After initiating this request handling by clicking the corresponding button in the GUI the required data is gathered, namely Username and WsnId. In the next step, this data is sent by an Ajax request to the corresponding PHP script, which performs the desired operation. For details about the deleting operation see [5]. If the deletion is successful a true statement (=1) is returned by the script, or alternatively, a false statement (=0). Assuming the deletion was successful the method sendEmail(purpose, emailData) is called located in the util.js, because it is a method that will be utilized by different scripts. In order to create the necessary mail for notification, the required data (here: recipient Email and information for the mail body) is gathered. Next, a new Ajax request is sent to the mail factory including the gathered data. In the mail factory, the request is then routed based on the provided purpose (here: DeletePermissionRequest). Finally, the method sendDeletePermissionRequestMail(additionalData) is called, which fills the provided data into the mail template and then sends it via the function sendMail(). At the end of the process, the method mailSent() is called creating a log entry for the recently sent mail in the corresponding table in WebMaDa‐DB.

9.6.3 Filtering Functionality

The main goal of the filtering functionality is to provide a simple, yet powerful way to allow a network owner or administrator to view all changes that have been made in a network including when who accessed data. Achieving this goal, it was defined that a network owner can see all information logged related to his network owned. This includes the rights and permission requests, as well as the changes made to his network. Here, users can only see owned networks in a filtering of the table ActiveWSN, including all registered networks in WebMaDa. On the other hand, the administrators should see system relevant logging tables such as the Emails that have been sent by the framework, the User and Admin tables, the Invitation Requests and Codes, as well as an overview of all registered WSNs.

Based on these assumptions the filtering process is implemented as follows: Each filtering form contains fields that a logging table could possibly be filtered with (cf. Section 9.5.2.2). Further it contains the name of the assigned stored procedure as a hidden input field, which is annotated with the class pdoName. This design decision was taken in order to reduce code duplication in the corresponding JQuery script resulting in one filtering method calling dynamically selected stored procedures in it.

As the frontend of WebMaDa is designed with HTML‐files itself and the filtering should also support HTML, the fields in the HTML form have to be provided in the correct order as defined in the store procedure in the backend. This means, if the filtering procedure expects the username as first parameter, this has to be the first input element in the form, too. For each input field that should be considered as a filter, the class logFilter has to be added to the corresponding HTML element. The reason for this design request comes from the JQuery script scanning the HTML container for all elements that are annotated with this class and adds their value as filter criteria. Only the limit operator is handled separately, as it is used in all forms. The limit filter is annotated with the class limitFilter and is not included in the logFilter array.

As soon as the network owner specified in the frontend the filter criteria in a satisfying manner, the function openLog is called to receive the data of the corresponding log table. As a first step, the name of the PDO, all filters from the user interface, the Cross‐Site‐Request‐Forgery (csrf) token, as well as the container in which the log table is located have to be gathered. Next, the parameters are passed to the PHP script generateLogTable fetching the data from WebMaDa‐DB. Therefore, a customized PDO is generated with the name of the passed stored procedure and all filter parameters that have been sent with the request. First the stored procedure shown in Listing Listing 9.1 [6] contains all inputs present in the HTML form and then the corresponding log table used as the FROM clause (line 15). The WHERE clause (lines 16–18) is built to either ignore the input values if they are null or check if they have any values given. Due to this, it is possible to use the same procedure to search for various combinations of filter inputs and not creating a separate one for each condition. Finally, the PHP script generates a HTML table containing all obtained records. The generated string is returned to the JQuery method openLog, where it is set as the HTML content of the table container.

9.7 Proof of Operability

In this section a proof of operability for the implemented features Email notification, logging, and filtering is presented showing that the concerns listed in Section 9.2 are addressed by WebMaDa 2.1, namely (i) mobility support, (ii) ownership control, and (iii) immediate privilege handling.

9.7.1 Automated Request Handling

As described throughout Section 9.6.1 WebMaDa 2.1 received an extension for notifications per Email if requests are placed in order to support administrators, network owners, and users to received immediate notifications about received requests and update status. Proving the operation of the functionality is done in the following with two examples: (i) A potential user requests access to WebMaDa (cf. Figure 9.3) and (ii) a user requests access to a foreign network. In both cases screenshots are presented illustrating the GUI from requestor's perspective and from the respective answering party (e.g., administrator, network owner).

9.7.1.1 Example for Automated Handling Access Request for WebMaDa

For case (i) Figure 9.6 illustrates the form a potential user must fill out to requesting access to WebMaDa. Here the contact information and the purpose for the request must be provided. As soon as the button “Send Request” is pushed the automated notification system in the backend starts its work generation three mails automatically:

• Email to WebMaDa's administrator to inform that an invitation request was placed, triggering the him/her to log into the administrator page to access or grant the request (cf. Figure 9.7).
• Email to the requestor that the request was received by WebMaDa (cf. Figure 9.8, mail no. 1).
• Email to the requestor that the request was open (cf. Figure 9.8, mail no. 2).

As soon as WebMaDa's administrator receives the notification and logged into the admin view of WebMaDa he/she can see in the users menu which requests for invitation wait for an accept or a revoke decision and pending invites (cf. Figure 9.9a). The latter means that the request was granted, but the registration process not yet concluded. Independent of accepting or denying the placed request the requestor receives an Email about the status update. Here Figure 9.8, mail no. 3 shows the mail sent out when the request was granted. Automatically, the admin's view is updated and the granted request is shifted to the section pending invites waiting for the requestor concluding the registration (cf. Figure 9.9b).

As this process shows, the interaction with the administrator is very limited and everyone receives notification about status and actions. Furthermore, there is no longer any need to publish an Email address, which prevents the administrators Email address from ending up in a spam mailing list. Additionally, with slight adaptations in the backend WebMaDa's administrator can now give authenticated users the right to act as an administrator in parallel. This means work can now be distributed to several people and, thus, it is guaranteed that the creation of users can remain operative even in case of illness or other absence of a key person. Since the process has been simplified and unnecessary intermediate steps (e.g., opening and writing an Email) have been omitted, the goal can be considered of intermediate and automated request handling is fulfilled.

9.7.1.2 Example for Automated Handling Access Request to Foreign Network

As soon as the user has access to WebMaDa he/she can request access to foreign networks assuming the network owners specified them as “public.” If not set to “public” they would not appear in the available list presented to the user when specifying a request. The presented list includes only the names of the networks, meaning the user needs to know that (e.g., timWSN, G4T9R04PYS, Buenzli2), which is linked to an unique WsnId in WebMaDa‐DB. The user follows the steps shown in Figure 9.4. First, he/she logs into WebMaDa and navigates to the submenu “Other WSNs” where granted access to foreign networks is shown and new requests can be placed (cf. Figure 9.10). Here the user can see, where privileges to foreign network(s) were already granted including details (here: access to network G4T9R04PYS). In this view also granted access can be given back by pressing the red button causing automatic notification sent out to the corresponding partners and an entry in the corresponding logs and tables in the database. When now querying a new permission request the user selects the foreign network in a dropdown menu (here: Buenzli2, cf. Figure 9.10). Immediately after selecting the network of interest, a window pops up where the user can place the detailed request (cf. Figure 9.11; here: requesting push for Humidity‐TelosB and pull for Temperature‐TelosB), where A0LDUV5L6O equals the WsnId for the selected foreign network “Buenzli2” in WebMaDa‐DB. As soon as the user pushes the button “Open Request” the automated notification system becomes activated, creating corresponding Email to the involved people that raised the request. Additionally, all information is written in the WebMaDa‐DB. Visual feedback is given to the user in the GUI by listing pending permission requests (cf. Figure 9.12a).

When the network owner receives the notification per Email he/she logs into WebMaDa and can see in the submenu “My WSNs” pending requests as shown in Figure 9.12b. Now he/she can either directly grant it without changes, deny it or update it. In the last option the network owner can modify the placed request before granting it. This means he/she can remove requested permissions, grant additional ones or grant others. When the settings satisfy the network owner he/she pushes the button “grant” and in the backend notifications are created to inform the requestor and network owner about changes, as well as entries are created in WebMaDa‐DB. Automatically the requestors view is updated by moving the request from section “My permission requests” into the section “Privileges” in the GUI and in parallel a notification is send per Email to the requestor to inform about the status change.

With this solution design the network owner stays in full control of gathered data and can grant, update and/or revoke privileges whenever necessary without involving the administrator anymore, because the process automatically matches the selected WSN to the linked unique WsnId in the database and checks the corresponding owner and its mail. This information is then used to construct the initial notification. The answering process works in a similar way. The delay in handling the request is only influences by the network owner, who needs to handle the request.

The option for the network owners to mark the network as “private” serves as an important means of data security. This option is enabled by default and prevents other users from seeing the network or making access requests. However, this setting does not affect any existing access rights, instead it just controls the visibility of the network under “Other WSNs” in WebMaDa's submenu.

9.8 Summary and Conclusions

Within this book chapter a user‐friendly Web‐based framework for handling user requests automatically was presented by addressing user concerns for mobility support, ownership support, and immediate privilege update having the goal (i) to limit involvement of third‐parties in the process chain and (ii) to inform involved parties immediately about status changes.

The first concern on mobility support was the driving force to develop WebMaDa itself, by offering a Web‐based framework with functionalities such as registering network, grant/revoke/update privileges, and viewing gathered data. WebMaDa 2.1 extends now these basic functionalities by offering network owners filtering functionality, allowing seeing data access and granted rights also when being physically absence from the deployed network and the instance CoMaDa. This functionality also addresses the second concern on ownership support, as in WebMaDa 2.1 network owners can query requests to WebMaDa‐DB directly accessing the exhausting logging system. The third concern about immediate privilege handling is now possible by WebMaDa 2.1 as no third‐party like the administrator is involved anymore when access requests are placed. This became possible with WebMaDa 2.1 by including the automated notification system by informing involved parties directly about placed requests, status about the request, and updated that were processed. Everything is automatically in the backend logged to address the ownership support additionally.

Overall it can be stated that with the new included functionalities – automated request handling and addressing data control in parallel – WebMaDa 2.1 now addresses current concerns in IoT and strengthens the ownership with minimal involvement of third parties. For the future it is envisioned to offer more visualization opportunities via WebMaDa 2.X, like dynamic graph creation, and optimizing the logging solution to improve scalability of tables by including compression for archiving purposes. Further WebMaDa should be linked to other types of networks to collected data and on the other side link WebMaDa to actor systems such as climate control systems in order to trigger events when being abort (e.g., closing/opening window, turning off/on heating).

References

1. 1 Porambage, P., Ylianttila, M., Schmitt, C. et al. (2016). The quest for privacy in the Internet of Things. IEEE Computer Society 3: 34–43, April.
2. 2 Schmitt, C. and Carle, G. (2010). Applications for Wireless Sensor Networks (Chapter 46); Handbook of Research on P2P and Grid Systems for Service-Oriented Computing: Models, Methodologies and Applications, Edited by. N. Antonopulus, G. Exarchakos, M. Li and A. Liotto, pp. 1076–1091, ISBN: 1-61520-686-8, Information Science Publishing, January.
3. 3 Atzori, L., Iera, A., and Morabito, G. (2018). The Internet of Things: A survey; Journal Computer Networks 54 (15): 2787–2805, October.
4. 4 Keller, M. (2014). Design and Implementation of a Mobile App to Access and Manage Wireless Sensor Networks; Master Thesis, Communication Systems Group, Department of Informatics, University of Zurich, Zurich, Switzerland, November.
5. 5 Schmitt, C., Anliker, C., and Stiller, B. (2016). Pull Support for IoT Applications Using Mobile Access Framework WebMaDa; IEEE 3rd World Forum on Internet of Things (WF-IoT). New York, NY, USA December, pp. 377–382.
6. 6 Bünzli, D. (2018). Efficient and User‐friendly Handling of Access Requests in WebMaDa; Bachelor Thesis, Communication Systems Group, Department of Informatics, University of Zurich, Zurich, Switzerland, January.
7. 7 European Parliament (2016). Regulation (EU) 2016/679 of the European Parliament and of the Council of 27 April 2016 on the protection of natural persons with regard to the processing of personal data and on the free movement of such data, and repealing Directive 95/46/EC (General Data Protection Regulation); Document ID 32016R0679, Brussels, Belgium, April, https://eur-lex.europa.eu/eli/reg/2016/679/oj (last access: September 13, 2018).
8. 8 Schmitt, C., Freitag, A., and Carle, G. (2013). CoMaDa: An Adaptive Framework with Graphical Support for Configuration, Management, and Data Handling Tasks for Wireless Sensor Networks; 9th International Conference on Network and Service Management (CNSM), IFIP, Zurich, Switzerland, ISBN: 978-3-901882-53-1, pp. 211–218, October 2013.
9. 9 Schmitt, C., Strasser, T., and Stiller, B. (2016). Third‐party‐independent Data Visualization of Sensor Data in CoMaDa; 12th IEEE International Conference on Wireless and Mobile Computing, Networking and Communications, New York, NY, USA, pp. 1–8, October 2016.
10. 10 Silvestri, N. (2017). WebMaDa Extension Addressing Transparency Request for Data Owners; Assignment, Communication Systems Group, Department of Informatics, University of Zurich, Zurich, Switzerland, July 2017.
11. 11 Schmitt, C., Anliker, C., Stiller, B. (2017). Efficient and Secure Pull Requests for Emergency Cases Using a Mobile Access Framework; Managing the Web of Things: Linking the Real World to the Web, In: M. Sheng, Y. Qin, L. Yao, and B. Benatallah (Eds.), Morgen Kaufmann (imprint of Elsevier), Chapter 8, pp. 229–247, ISBN: 978-0-12-809764-9, February.
12. 12 Das, A.M. (2009). Two-factor user authentication in wireless sensor networks. IEEE Transactions on Wireless Communications 8 (3): 1086–1090, March.
13. 13 Chen, T.H., and Shih, W.K. (2010). A robust mutual authentication protocol for wireless sensor networks. ETRI Journal 32 (5), October.
14. 14 Turkanovic, M., Brumen, B., and Hölbl, M. (2014). A novel user authentication and key agreement scheme for heterogeneous ad-hoc wireless sensor networks, based on the Internet of Things notion. Ad Hoc Networks 20: 96–112, April.
15. 15 Amin, R., and Biswas, G.P. (2016). A secure light weight scheme for user authentication and key agreement in multi-gateway based wireless sensor networks. Ad Hoc Networks 36: 58–80, January.