|
Test Case Title |
TC11.5 - Auditing and accounting views, View on KeyCloak configuration not accessible from menu |
|
Goal |
To provide evidence about the capabilities of the solution to perform Auditing and accounting of the major activities performed by the users on the platform. |
|
Prerequisites |
Access to the platform at least as ToolAdmin, but the final access should be done only at the RootAdmin. The following functionalities are available only for specific Snap4city users with specific privileges. |
|
Expected successful result |
Evidence about the fact that the platform is capable to audit about the activities, and is capable to understand what occurred and what is going on, and also capable to perform accounting of all the major aspects and resource consumption. The accounting is the frist step to define mechanisms of billing and also for creating some mechanism for providing incentives and bonus to the users. |
|
Steps |
Please note that some of the following links could be accessible only for registered users.
The platform is supporting 5 kinds of users for the most powerful to the less:
- RootAdmin (for auditing user behaviour, system conditions in deep, user management),
- ToolAdmin (for changing setting in the tools),
- AreaManager (developer),
- Manager (Final User),
- Public (public users). The latter is presently blocked by a password but is totally public and accessible in the future.
The users have distinct roles, menus, access to functionalities and capabilities as described.
The solution is based on LDAP for roles/authorization, Keycloak for SSO authentication. In some specific and critical cases, for the RootAdministrator a double password is requirement to increase security.
All components are accessible via authentication over HTTPS protocol. Almost all actions performed on client device are logged and stored for auditing, and all those acting on personal data.
The solution also perform logging and Accounting to measures the resources consumed by users. This includes for each user the amount of:
- data exchanged (AMMMA, DevDash)
- logging of session statistics
- IOT applications
- Dashboards
- MyPersonalData
- MyAnnotations
- Delegation
- IOT Devices registered
- Etc.
All these feature of the accounting would be useful for billing and providing strategies for serious gaming in the platform, to help users passing to the next levels, to provide them stimuli, to put users in competitions each other. It is very easy to show the summary of the statistical data about the usage on the dashboard. See for example the dashboard of the Mobile Engagement running in this period in Tuscany.
Snap4City keeps trace of any data entering into the platform, via ETL, from IOT brokers, from mobiles and IOT applications by means of a set of tools for the administrators:
- AMMA for general indexing and auditing to data flow.
- DevDash for general indexing and auditing to data.
- Auditing: Data Type vs users (from main menu: Management à Data Type vs Users) only for Root Admin Role
- Auditing Personal Data, including annotation, IOT devices keys, etc. (from main menu: Management à Auditing Personal Data) only for Root Admin Role
- Auditing Data Type Ownership (from main menu: Management à Data Type Ownership) only for Root Admin Role
- Auditing Data Access Try-out (from main menu: Management à Auditing Data Access Try-out) only for Root Admin Role
And a personal tool for each user to understand the access to his/her own data.
AMMA for general indexing and auditing to data flow (accessible as anonymous data)
AMMA, Application and MicroService Monitor and Analyser: https://www.snap4city.org/drupal/node/43 is an Open Source tool for monitoring and analysing communications aspects in real-time, such as data flows and volumes information among IOT, ETL and Data Analytics (in input and output, iot and storage, and API) collected by the EventLogger module in the whole solution (all ETL processes, IOT applications and MicroServices are monitored). The AMMA tool is based on SOLR index, and Banana plus special widget developed for Snap4City for accessing and displaying indexed data in an intuitive and interactive fashion, allowing applying faceted filtering and data drill down in time and space, displaying stacked data and temporal trends.
Integrating the APP and ETL ID with the following data it is possible to account and understand the traffic flow produced by users.
DevDash for general indexing and auditing to data value (accessible as anonymous data)
DevDash, Developer Dashboard: https://www.snap4city.org/drupal/node/42 is an Open Source tool for accessing to data collected (by means of ETL and IOT processes) in an interactive and faceted manner. It is based on SOLR to index the data, to enable the drill down, and to dynamically shape the data according to multiple filters. This Dashboard approach is only for developers.
Tracking and accounting activity performed on the platform and portal (view for the RootAdmin only)
From the list of users: https://www.snap4city.org/drupal/admin/people
Main, Settings --> User Management
Snap4City portal registers:
- Accesses and their duration: Visits
- Contributions performed on content: blog, articles, etc.: Content
Root Admin can also control the user connected on the portal (Who’s Online) and their recent contributions.
Accounting about Dashboard per user (view for the RootAdmin only)
The RootAdmin can access to the table version of the list of Dashboard.
Main Menu, Dashboard --> View as Table
This view, reported in figure, allows the administrator to see a number of details about the usage of the Dashboards.
The features are: title, owner, creation date, last edit date. In addition, as evident in other views, the administrator knows:
- Kind of dashboard:
- passive, meaning that the Dashboard only uses the public data,
- broker, it is connected to some IOT Device as event driven stream via some IOT Broker
- IOT apps, it is connected to some IOT App as event driven stream
- Broker & IOT apps, both of the above
- How many data sources the dashboard uses
- If the dashboard is public or private, if it is private, the owner and its delegation
- number of accesses performed
- number of delegations provided, see in the following for a table
- How many IOT applications back and forward are connected to the dashboard
- How many IOT streams from IOT brokers back and forward are connected to the dashboard
Accounting about Data vs Type/Ownership (view for the RootAdmin only)
The RootAdmin can access to the table version of the list of Dashboard.
Main Menu, Management --> Data Type vs Users (Ownership)
This view, reported in figure, allows the administrator to see the list of Entities owned by a given user and the creation date, on the right side the status of the element is also provided.
The Element Types can be:
- IOTID: an IOT Device private
- ServiceURI: a POI or a single sensor on the ServiceMap and KB with some geolocation, it medata, etc. For example a shops, a sensor, an actuator, etc. even read by ETL or IOT any way...
- ServiceGraphID: a family of Element Types as ServiceURI which have been loaded as private into the system with a unique ETL process. For example all the: traffic sensors, position of the TV cameras which I would like to keep private.
- APPID: an IOT application
- DashboardID: an Dashboard
Auditing Personal Data (view for the RootAdmin only)
The RootAdmin can access to the table version of the list of Dashboard.
Main Menu, Management --> Auditing Personal Data
This view, reported in figure, allows the administrator to see the list of actions performed on Personal Data (to read and write them) by each single user, when it is connected on the several tools, or when his/her own App is working. Each log line, is mainly classified along axes:
- Access Type: READ, WRITE
- Domain: data (access), delegation statement
- Motivation: Personal Information, Shared Position, My Position, IOKeys, etc.
- App name: if the request is coming from an APP
- Source Request (tool): DashboardWizard, DashboardManger, IOTApp, etc.
- User name: the owner
- Delegated User name: the recipient, anonymous if made public
- Delegated APPname
- Variable name: what has been accessed
- Etc.
Auditing Data Access Try-out (view for the RootAdmin only)
The RootAdmin can access to the table version of the list of Dashboard.
Main Menu, Management --> Auditing Data Access Try-Our
This view, reported in figure, has been set up for monitor the data safer API to detect eventual faults in accessing data and tryout to access to them non authorized. So that the calls of the Personal Data API are monitored and the list of failed accesses are logged. Those reported in the table are tests. The data stored are those that allows us to understand what has been performed, who has done the request, from when, when and how, and the error log.
Tracking and accounting activity performed by the users (view for the RootAdmin only)
The RootAdmin can access to the table version of the list of Auditing access to my data
Main Menu, My Profile --> My Personal Data Type -> Auditing Access to My Data
This view, reported in figure, allows the administrator to see the list of actions performed on Personal Data (to read and write them) by each single user, when it is connected on the several tools, or when his/her own App is working. Each log line, is mainly classified along axes:
- Time: Access time
- Application name: if the request is coming from an APP
- Source (tool): DashboardWizard, DashboardManger, IOTApp, etc.
- Variable name: what has been accessed
- Domain: data (access), delegation statement
- Motivation: Personal Information, Shared Position, My Position, IOKeys, etc.
- Access Type: READ, WRITE
- User name: the owner
Tracking accesses on the platform (view for the RootAdmin only)
The RootAdmin can access to the KeyCloak console for accessing to the log of all the accesses on the platform.
We have the starting and stopping time and a number of activities that can be finely logged and queried. Please note that the storage is protected.
