what is govroam?
govroam provides government employees with seamless access to WiFi networks, wherever the service has been made available by participating organisations. Users are automatically authenticated through a single Wi-Fi profile and set of credentials. Authentication of users is performed by their home organisation, using the same credentials as when they access the network locally, while authorisation to access the Internet and possibly other resources is handled by the visited organisation.
govroam is based on eduroam, the world-wide roaming access service developed for the international research and education community. eduroam was initiated by SURFnet and started as a project of the Trans-European Research and Education Networking Association (TERENA), which still oversees its operation worldwide. It was originated from The Netherlands and has spread to many countries. SURFnet actively participates in govroam.
govroam NL service policy - jan 2015
Initially our govroam initiative is focussed on the Netherlands. In Austria, Belgium and Slovenia, similar projects have started. The Dutch and Belgian initiatives are examining cooperation. Further internationalisation will be discussed with participating organisations.
govroam stands for governmental roaming. It offers users from participating govroam organisation secure Internet access at any other government participating location. The govroam architecture that makes this possible is similar to the eduroam (educational roaming) worldwide roll-out with over 10 years over experience. govroam as well as eduroam are based on a number of technologies and agreements, which together provide the govroam user experience of seamless and automatic online connection to Internet.
The crucial agreement underpinning the foundation of govroam involves the mechanism by which authentication and authorisation works:
- The authentication of a user is carried out at their Identity Provider (IdP), using their specific authentication method.
- The authorisation decision allowing access to the network resources upon proper authentication is done by the Service Provider (SP), typically a Wi-Fi network or Wi-Fi hotspot.
In order to transport the authentication request of a user from the Service Provider to his Identity Provider and the authentication response back, a world-wide system of RADIUS servers is created. Typically every Identity Provider deploys a RADIUS server, which is connected to a local user database. This RADIUS server is connected to a federation level RADIUS server, which is either in turn connected to the upstream RADIUS server infrastructure or can connect to other RADIUS servers dynamically (using the protocol RADIUS/TLS). Because users are using usernames of the format “user@realm”, where realm is the IdP’s DNS domain name often of the form organsiation.tld (tld=top-level domain; both country-code TLDs and generic TLDs are supported), the RADIUS servers can use this information to route the request to the appropriate next RADIUS server until the IdP is reached.
To transfer the user’s authentication information securely across the RADIUS-infrastructure to their IdP, and to prevent other users from hijacking the connection after successful authentication, the access points or switches deployed by the SP use the IEEE 802.1X standard that encompasses the use of the Extensible Authentication Protocol (EAP). EAP is a container that carries the actual authentication data inside, the so-called EAP methods. There are many EAP methods an IdP can choose from.
govroam requires that the chosen EAP method must allow:
- mutual authentication (i.e. the user can verify that he is connected to “his” IdP whereever the user is
- encryption of the credentials used (i.e. only the user and his IdP will see the actual credential exchange; it will be invisible to the Service Provider and all intermediate proxies)
RADIUS transports the user’s name in an attribute User-Name, which is visible in clear text to all intermediate hosts on the way. Some EAP methods allow to put a different User-Name into the RADIUS packet than in the EAP payload. In that case, the following terms are used:
- outer identity: this is the User-Name in the RADIUS packet and visible to all intermediate parties
- inner identity: this is the actual user identification. It is only visible to the user himself and the Identity Provider
When using such EAP methods, and activating this option, the real username is not visible in RADIUS (it will only see the outer identity). Doing so will enhance the user’s privacy, and is encouraged. Outer identities should be in the format “@realm” (nothing left of the @ sign, but the realm is the same as with the actual username). The realm part still must be the correct one as it is used to route the request to the respective Identity Provider. Once the IdP server decrypts the TLS tunnel in the EAP payload, it gets the inner identity and can authenticate the user.
After successful authentication by the Identity Provider and authorisation by the Service Provider, this SP grants network access to the user, possibly by placing the user in a specific VLAN intended for guests. The SP must at least provide Internet access (free of charge) and may provide additional service such as a printing facility.