# IAACaaS: IoT Application-Scoped Access Control as a Service +
## 5 Implementation and Results
### Use Case Analysis  
To illustrate how the proposed model can be applied to a real use case scenario, we provide a sample smart city setup that we have tested in the environment deployed at FIWARE Lab. Table 2 shows a summary of the services and devices we have registered for this scenario, as well as the roles and permissions we have defined and the corresponding assignments between them. On the other hand, Figure 5 shows a diagram of the designed system. We can see how the services administrators (in this case, the administrators of the _Parks and gardens_ and of the _Electricity_ services) are the Service Admins that manage roles and permissions in the identity provider. They have to register their services in the IdP and then start registering devices and assigning roles to them. Assuming that the services would be provided by the local city government, devices can be shared between services. In the example, streetlights access both services as explained below. The first service, _Parks and gardens_, is in charge of the monitoring and management of the green areas around the city. One of the features that it offers consists of turning on and off the streetlights of a park depending on the presence of people around. To achieve this, we register a set of presence sensors (\(D1_{n}\)) that periodically publish in the _Parks and gardens_ service the presence status in different zones around the streetlight. This is possible because we define a _PI_ permission that allows GET requests to the specific resource in the service (/parks/idb/presence). This permission is assigned to the _RI_ role, which is in turn assigned to the sensors. Note that, to facilitate this task and thanks to the multi-tenancy feature of the proposed model, we define a group of devices that contains every \(D1_{n}\) sensor, and we just assign the _R1_ role to the group. \begin{table}
\begin{tabular}{c c c c c} \hline \hline
**Component** & **Operating System** & **CPU** & **Memory** & **Disk** \\ \hline
**Horizon** & Ubuntu 14.04 & 8 virtual CPU & 8 GB & 14 GB \\
**Keystone 1** & Ubuntu 14.04 & 8 virtual CPU & 8 GB & 14 GB \\
**Keystone 2** & Ubuntu 14.04 & 8 virtual CPU & 8 GB & 100 GB + 500 GB \\
**AuthZForce** & Ubuntu 14.04 & 4 virtual CPU & 4 GB & 18 GB \\
**HA Proxy** & Ubuntu 14.04 & 8 virtual CPU & 16 GB & 14 GB \\ \hline \hline \end{tabular}
\end{table} 
Table 1: Deployment servers characteristics. Figure 4: Deployment configuration. \begin{table}
\begin{tabular}{c c c c} \hline \hline
**Service** & **Device** & **Role** & **Permission** \\ \hline \multirow{3}{*}{Parks and gardens} & D1\({}_{n}\) (presence) & R1 & P1: POST /parks/(id)/presence \\ \cline{2-4}  & D2 (streetlight) & R2 & P2: GET /parks/(id)/presence \\ \cline{2-4}  & D3 (web panel) & R3 & P2: GET /parks/(id)/presence \\ \hline Electricity & D2 (streetlight) & R4 & P4: POST /lights/(id)/status \\ \hline \hline \end{tabular}
\end{table} 
Table 2: Devices’ summary. On the other hand, the streetlight periodically retrieves the presence status provided by the sensors around it and acts accordingly by turning on or off the light. To be able to read this information from the service, we define and assign the role \(R2\) with the permission \(P2\), which permits POST requests to the presence resource. Streetlights also have a sensor that reports the luminosity to the _Parks and gardens_ service; we have created a new permission \(P3\) that allows this action, and we have assigned it to the role that the device already owns (\(R2\)). Finally, to monitor the density of people in the parks, operators can visualize the presence status reported by \(D1_{n}\) sensors on a web page using their PCs/smartphones. This web page can read this information because role \(R3\) allows it thanks to permission \(P2\) (we reuse here the one we created for the streetlights). As can be seen, not only IoT devices can benefit from our AC mechanism: every client capable of creating an OAuth 2.0 token is eligible.