In general terms, you can describe the structure of the service in 2 parts: the back end infrastructure and the web front end. The image below schematically shows the relationship of the components. Below that, the different components are briefly explained.
Back end infrastructure
The technical heart of iotroam consists of a RADIUS server and the iotroam database. These servers are hosted in the high availability SURF data centers in Amsterdam. The iotroam database is replicated in a geographically separate data center.
Web front end
The web front end or portal provides functionality to users and administrators and is also hosted in the high availability SURF data centers.
WiFi network at the institution
An SSID named 'iotroam' (lower case!) must be configured in the WiFi network at the institution. SURF is aware of introducing an extra SSID, where the advice is to keep the number of SSIDs limited. Nevertheless, this was chosen so that there is a clear distinction between personal devices (connected with eduroam) and IoT devices. The function of the SSID is clear to users and it makes collaboration between institutions (roaming) easier. The SSID iotroam can of course be used for all devices using WPA2-personal.
Use of optional Radius proxy at the institution
An institution can choose to send RADIUS requests from the access points not directly to the iotroam infrastructure, but through its own RADIUS server. This will act as a proxy: it forwards the requests to iotroam's RADIUS server and receives the response for processing.
SURF recommends that institutions set up iotroam in this way so that the institution's administrators themselves have access to logging of RADIUS requests. This makes initial analysis during troubleshooting easier. And solutions such as Quarantainenet can be more easily integrated.
Secure management
Only authorized administrators of the institution have access to the administrator part of the iotroam portal. An administrator can view RADIUS clients, users, groups, device profiles, added devices. The administrator can set up and manage these components.
Authorization for the management portal is done by using SURFconext. This ensures that only those users who should have access from within the institution are granted access. We use proprietary roles for this purpose: "iotroam-beheerder" which allows a user with this role to access the administration interface. An institution's ICP assigns this role to IT administrators.
When an administrator is no longer employed by an institution, it is the responsibility of the institution to revoke the authorizations. Of course, access for the administrator no longer works once it is no longer possible to authenticate via SURFconext.
Users must also log in to the portal via SURFconext so that only those authorized by institutions can use the service. Which groups (affiliates) are allowed to use iotroam can be set in the administrator interface.