In algemene termen kun je de opbouw van de dienst omschrijven in 2 delen, te weten de back end-infrastructuur en de web front end. Onderstaande afbeelding geeft schematisch de samenhang van de componenten weer. Daaronder worden de verschillende onderdelen kort toegelicht.
Back end-infrastructuur
Het technisch hart van iotroam bestaat uit een RADIUS-server en de iotroam-database. Deze servers zijn gehost in de high available SURF-datacenters in Amsterdam. De iotroam-database wordt gerepliceerd in een geografisch gescheiden datacenter.
Web front end
De web front end of portal biedt de gebruikers en de beheerders de functionaliteit en is eveneens gehost in de high available SURF-datacenters.
API
Met een Rest API kan informatie van groepen en apparaten in groepen worden uitgelezen en kunnen apparaten worden toegevoegd of gewijzigd. Hiervoor is een API-key nodig voor autorisatiedoeleinden, waarin ook de groepsrechten worden vastgelegd.
WiFi-netwerk bij de instelling
In het WiFi-netwerk bij de instelling moet een SSID met de naam ‘iotroam’ (met kleine letters!) worden geconfigureerd. SURF is zich ervan bewust een extra SSID te introduceren, waar het advies is om het aantal SSID’s beperkt te houden. Toch is hiervoor gekozen, zodat er een duidelijk onderscheid is tussen persoonsgebonden apparaten (eduroam) en IoT-apparaten. De functie van de verschillende netwerken is duidelijk voor gebruikers en het maakt samenwerking tussen instellingen (roaming) eenvoudiger. Het SSID iotroam kan uiteraard gebruikt worden voor alle apparatuur die van WPA2-personal gebruik maakt.
Gebruik van optionele Radius-proxy bij de instelling
Een instelling kan ervoor kiezen om de RADIUS-requests van de access points niet direct naar de iotroam-infrastructuur te sturen, maar via een eigen RADIUS-server. Deze fungeert dan als proxy: stuurt de requests door naar de RADIUS-server van iotroam en ontvangt de respons om deze te verwerken.
SURF raadt instellingen aan om iotroam op deze manier in te richten, zodat de beheerders van de instelling zelf de beschikking hebben over logging van de RADIUS-requests. Daarmee wordt de eerste analyse bij troubleshooting eenvoudiger. En kunnen oplossingen als Quarantainenet makkelijker geïntegreerd worden.
Beveiligd beheer
Alleen geautoriseerde beheerders van de instelling hebben toegang tot de beheerportaal. Op het beheerportaal krijgt een beheerder inzicht in de RADIUS clients, gebruikers, de groepen, de device profielen, de toegevoegde apparaten. De beheerder kan deze onderdelen instellen en beheren.
De autorisatie voor het beheerportaal wordt gedaan door gebruik te maken van SURFconext. Zo zijn wij er zeker van dat alleen de gebruikers die vanuit de instelling toegang behoren te hebben, ook daadwerkelijk toegang krijgen. We gebruiken hiervoor eigen rollen zoals bijvoorbeeld de rol iotroam-beheerder waardoor een gebruiker met deze rol toegang krijgt tot de beheerdersinterface. Een beheerder met de rol AAIVerantwoordelijke heeft ook toegang tot iotroam in de beheerderrol. De ICP van een instelling kent deze rol toe aan IT-beheerders.
Als een beheerder niet meer werkzaam is bij een instelling, is het de verantwoordelijkheid van de instelling om de autorisaties in te trekken. Natuurlijk werkt de toegang voor de beheerder niet meer zodra er middels SURFconext niet meer kan worden geauthenticeerd.
Ook gebruikers moeten via SURFconext inloggen op de portal, zodat alleen door instellingen geautoriseerde personen van de dienst gebruik kunnen maken. Welke groepen (affiliates) gebruik mogen maken van iotroam kan in de beheerdersinterface worden ingesteld.