Simulación sin interferencias 113 

According to the analysis of the read and write frequency, it is concluded that reading access is predominant in System KG. It has been noticed that the process of inference leads to high system resource usage. Accordingly, to improve the efficiency of system operation, the frequency of performing inference should be optimized. To achieve this objective, materialization is applied, which refers to the process to generate a Materialized Ontology View. As defined in [116], a Materialized Ontology View of a base ontology is “a (valid) ontology that consists solely of projections, copies, compressions, and/or combinations of elements of the base ontology, presenting a varying and/or restricting perception of the base ontology, without introducing new semantic data”. Materialization allows to speed up query processing by explicating the implicit entailments which are sanctioned by the semantics of an ontology. [117] In other words, the outcome of inference should be stored as ready-to-consult facts in System KG for all the subsequent queries. And the inference should be only triggered when there are changes that can affect the result of the previous inference. This avoids the re-computation of derived information for every query.

Considering the circumstances of the platform that any change in the configuration of users, roles, devices and spaces may affect the result of the inference as they are the classes that have been involved in the rules. The change status of the named graph of a client is marked with a flag "changed". If changes are detected in the configuration of space, devices, parameter, users and roles of a client, the flag will be set as true. As each client has only one administrator who can modify the configuration, the inference will be triggered in two cases if flag "changed" is true. In the case that a query is made or the administrator has issued a logout request. By doing this, the system stability and query performance is optimised.

Chapter 5

Fine-grained access control for the Web

of Things

Considering the inherent characteristics of Web and the Internet of Things, how to ensure the security and privacy of both data and devices is one of the key issues to be concerned. Providing access to Things at the level of web and application brings new challenges for the IoT solutions. As a result, security is also an important issue to consider for the Web of Things. This chapter will explain about the authentication and authorization mechanism for the IoT platform, which has been developed on the basis of Web API and PKGs.

5.1 Authentication and Authorization

In the platform, the access control process is separated into two issues: authentication, i.e. "who you are" and authorization, which answers the question "what you can do".

Authentication ensures that the agent which is accessing the system is the right one. The agent could be either a person or software. In the platform, the authentication is realized by using both token-based method and ACL (Access Control List).

• A person (user) needs to authenticate himself by providing the proper username and password at the moment of login. If the login succeeds, a token will be returned. This token should be store in the local storage of the user and be put in the Authorization header of all the subsequent requests for accessing and manipulating the authorized data in the platform and control the authorized devices through the platform.

• A Border Router needs to provide its identifier in each request. Central Server keeps a list of valid identifiers and will only allow the request to pass if the appended identifier is in the list.

90 Fine-grained access control for the Web of Things Authorization is the process of specifying the access rights of agents to resources. In con- sideration of the complex situation in the platform, a fine-grained authorization mechanism is designed by combining the three most popular strategies for the definition of authorization policies:

• Discretionary Access Control (DAC), which restricts the access to objects based on the identity of subjects and/or groups to which they belong. And a subject with certain access permissions can transfer that permission on to any other subject [118][119][120]. In the case of the developed platform, for each organization/family that has registered for the platform, one administrator is defined, who has the rights to manage all the belonging users, infrastructures, facilities and assign the access permissions to different users.

• Role-Based Access Control (RBAC), which associates the permissions with roles and the users and can have various roles.[121][122] This strategy fits well with the requirement of multi-user system, providing a flexible way to manage the relationship between large amount of users and facilities. In the case of the developed platform, each user has a list of roles and it gets all the permissions that these roles hold. • Attribute-Based Access Control (ABAC). The access rights are granted according to

the attributes of users, resources, objects and environments. [123][124][83] Compared with the two strategies mentioned previously, ABAC is much more flexible and adaptive to the real-world situation, which enlarges the focus from users to the facilities and the surroundings. In the case of the developed platform, the access to devices are granted to roles according to the functionalities and locations of each device.