TC11.6 - Monitoring accesses and changes

Test Case Title	TC11.6 - Monitoring accesses and changes
Goal	To provide evidence about the capabilities of the solution to log accesses and changes.
Prerequisites	Access to the platform at least as ToolAdmin, but the final access should be done only by aa user with RootAdmin role. 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 monitor accesses and changes.
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 access and changes to data from the applications is logged over a database and monitored for possible misuse. The Snap4City solution allows monitoring:

• accesses on all tools, all tools are monitor in access log via KeyCloak, and in role access via LDAP
• personal data all changes are log to allow the auditing
• traffic flow data analysis AMMA Tool
• data access and changes analysis: Developer Dashboard, DevDash
• Back office Resource Analysis, ResDash
• Back office container Monitoring
• Smart City API Monitoring dashboard
• Notificator Engine Monitoring
• Web server Monitoring
• Back Office Scheduler Monitoring, DISCES tool
• Mobile Applications Monitoring, recommender
• queries on ServiceMap and API are Log.
• IOT Device registration is log on the KB.

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:

• 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.

 

Tracking and access and changed 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.

 

Access Log of ServiceMap

The ServiceMap tool stores on a specific table information about who make access to the tool functionality both via API and using the tool itself via web UI.

The AccessLog SQL table stores the information about each call and can be stored on mysql or/and on Phoenix HBase databases.

The table stores the following data:

• timestamp, timestamp when the action was performed
• mode, the type of call performed, it can be:
  • 'api-events-day'
  • 'api-events-month'
  • 'api-events-week'
  • 'api-imgcache'
  • 'api-last-feedback'
  • 'api-location'
  • 'api-location-search'
  • 'api-notification'
  • 'api-service-comment'
  • 'api-service-info'
  • 'api-service-photo'
  • 'api-service-stars'
  • 'api-services'
  • 'api-services-by-gps'
  • 'api-services-by-municipality'
  • 'api-services-by-queryid'
  • 'api-shortestpath'
  • 'api-sparql'
  • 'api-text-search'
  • 'api-tpl-agencies'
  • 'api-tpl-bus-lines'
  • 'api-tpl-bus-routes'
  • 'api-tpl-bus-stops'
  • 'api-tpl-latlng'
  • 'save'
  • 'ui-events-day'
  • 'ui-events-free_text'
  • 'ui-events-month'
  • 'ui-events-transverse'
  • 'ui-events-week'
  • 'ui-location'
  • 'ui-location-search'
  • 'ui-service-info'
  • 'ui-services-by-gps'
  • 'ui-services-by-municipality'
  • 'ui-shortestpath'
  • 'ui-text-search'
  • 'ui-tpl-search'
• ip, the IP address from where the call was made
• userAgent, the user agent of the client performing the call
• uid, the optional User ID of the user performing the call
• serviceUri, the optional serviceUri provided in the call request
• selection, the optional selection provided in the call request
• categories, the optional list of categories requested in the call
• maxResults, the optional max number of results requested in the api call
• maxDistance, the optional max distance provided in the api call
• reqfrom, it can be user or app, to state if the request was performed by a human user or by an application on its own.
• text, the optional text requested in the api call
• queryId, the queryId used to call the functionality
• format, it can be html or json
• email, the optional email address provided by the user when saving a configuration
• referrer, stores the optional referrer provided in the HTTP header
• site, stores the virtual ServiceMap hostname from which the call was performed

Many metrics of the dashboard builder use information from this table to provide information on the use of ServiceMap.

 

Access Log of NodeRED IOT Applications

Access to nodered applications can be tracked using KeyCloack access logs and from apache/nginx logs. Internal nodes activites are tracked using the Node

 

Access Log of KeyCloak (view for the RootAdmin only)

Point the browser  https://www.snap4city.org/auth

 

RootAdmin, by the “session” menu item can track the Realtime connection per client

For each client it is possible to track user ip and session start

By clicking to the username it’s possible to see the history of all its access on the snap4city tools as depicted in the following figure

Changes Log on DISCES

Each execution on process is log with a number of parameters. See the DISCES from the main menu under the Management menu item.