The purpose of the eduroam AU AdminTool is to enable up-to-date information about eduroam AU deployment to be made available to the national roaming operator (AARNet), to end-users, and to the eduroam global database.
The eduroam AU AdminTool is used by institutional administrators to maintain up-to-date information about their eduroam deployment.
Why is maintaining accurate institutional deployment data important?
The eduroam AU AdminTool is Python-Django-based, with a PostgreSQL database, and Apache web server.
The eduroam AU AdminTool provides the following web user interfaces:
It is the responsibility of eduroam AU participant institutions to maintain the accuracy of their data. Nominated institutional administrators are granted access to enter their institutional eduroam deployment data.
Note: no security sensitive information is stored in the AdminTool. The fields for RADIUS server secrets and institutional test account passwords are locked and only a default value is stored in the AdminTool database. Entry of RADIUS server secrets and test account passwords is currently disabled and will be enabled in future only after a thorough security audit of the AdminTool.
Institutions are advised that a subset of data entered into the AdminTool is shared globally (refer to the XML file section of this document).
The global policy requires that National Roaming operators provide a data feed to the Global Database containing information regarding their national eduroam and institutional deployments.
The European eduroam Operation Team has created and maintains a global database which stores this informaiton, and provides a web interface to enable National Roaming Operators to access information on countries and institutions participating in eduroam.
More documentation on the Global Database is available.
XML data provided to the global database is a subset of data entered via the AdminTool.
As this data provides contact information, access to the institutional data file is restricted to the global eduroam database ingest service and AARNet internal servers.
If you wish to have a copy of the XML data for your institution, please submit a request via firstname.lastname@example.org.
The following data is uploaded:
The data schema for the XML files are linked above.
XML files are ingested to the global database on a 4 hourly basis.
Currently the XML files provided to the Global
Database are not protected, i.e. those files above are freely accessible.
The eduroam AU public interface provides summary information on eduroam AU participants.
A national map of eduroam participants in eduroam AU is presented on the https://admin.eduroam.edu.au homepage.
A participant list is available under the “Institutions” menu item.
Each institution entry provides links to the institution’s specific eduroam information page and the institutions network access Acceptable Use Policy.
The institution’s eduroam information page should describe any network access restrictions imposed due to local policy on eduroam users.
It is recommended that eduroam users read the visited institution’s Acceptable Use Policy and ensure they comply with it.
Note: users are required to comply with their home institution’s acceptable use policy (AUPs), which, given the closed community of eduroam users i.e. people involved in education and/or research, it is assumed that AUPs will be equivalent. If an eduroam service provider institution observed network activity in breach of its AUP (e.g. download of copyright or illegal materials) they should identify the device MAC address and home institution from RADIUS logs, and pass on the RADIUS logs and description of noncompliant activity (e.g. copyright infringement notification) to the identified home institution. The home institution should take action against the user as if the user had performed the activity on the home network.
See “eduroam AU AdminTool User Guide” for more details on the public interface to the eduroam AU AdminTool.
If location services are turned on, the closes eduroam location can also be displayed. Clicking on Closest eduroam results in a closest eduroam map being displayed in a new browser tab.
The World Map link displays the global map of eduroam.
Given the number of locations, the World Map may take some time to display.
The “Manage” menu item of the AdminTool provides access to the institutional administrator pages.
eduroam AU AdminTool administrative access requires SAML authentication. The service is accessed via AARNet’s SAML Proxy. For institutions without a SAML IdP, administrators will be added to the Australian Access Federation Virtual Home Organisation.
Institutional Administrators access the AdminTool via their SAML IdP or via the AAF Virtual Home Organisation.
SAML Access is provided via the AARNet ‘OpenConext’ instance, a SAML proxy. This allows us to provide access for customers who are from institutions with a SAML IdP however not in the AAF.
The AARNet SAML Proxy service provides a page of IdP icons which are links to those institution’s SAML login page.
In case of institutions without a SAML IdP, those that do who want to use the AAF VHO, AARNet will create an account in the VHO enabling the admin’s to access AdminTool.
This requires AARNet creating an account under the VHO “AARNet” group, which results in an email being sent to the user describing the terms and conditions for access and use of the VHO account.
The user will then activate their VHO account via the link provided in the email, and will then be able to access to the AdminTool selecting the “Virtual Home Org” IdP in the SAML Proxy IdP list.
The first time an institutional administrator accesses the service via SAML, a prompt appears allowing selection of the institution they wish to administer.
An email is sent to the eduroam AU administrator requesting activation of the user as institutional administrator for the nominated institution.
One activated, a confirmation email is sent to the institutional administrator.
The administrator can they access the AdminTool via the Manage menu item and will either see a page indicating this institution has no data and needs to be populated from scratch, or displays existing details for the institution.
When institutional data has been entered already (should be the case as during on-boarding some information will be pre-populated for the institution by the eduroam AU administrator), when the institutional administrator logs into the AdminTool, a map will be displayed showing already configured locations (e.g. map displayed for AARNet institutional administrator).
Information already entered for each location can be displayed by pressing on the eduroam location icons
eduroam AU participating institutions are required to maintain their eduroam deployment data via the eduroam AU AdminTool.
Institutional data is used by AARNet for support purposes, for report generation, and in future for data population of eduroam related services. In particular, the TroubleShooting service under development will make use of test account information and server information.
There are various categories of information that are required to be entered:
These data categories are described further below.
The expectation for reflecting any changes depends on the nature of the change
Within 12 hours: Realm(s), Contact(s), Test Account(s)
Within 24 hours: RADIUS Server(s)
Within 7 days: Location(s), Monitored realm(s)
In order to confirm the data which is sent to the Global Database via the XML file, institutions may request AARNet to provide to institutional admins the section of the file describing the institution.
Institutions will be provided with this data at the completion of the onboarding process.
During operation, institutions should submit a
request if they wish AARNet to provide the institutional data for confirmation.
Basic information about the institution.
The “Number User” and “Number of IDs” are rough estimates only.
Note that the URLs entered into the institutional data must be:
These URLs are published on the open AdminTool public interface under “Participants”. It is important that the AUP and institutional eduroam participation webpage can be accessed by institution’s users, visitors, and other eduroam participating institution eduroam administration.
It is important that globally eduroam users know where eduroam access is available, i.e. where the “eduroam” SSID is broadcast.
Location information is intended to provide information on locations and also any differences to the wireless service at these sites.
Accuracy of location information is a matter for the institution to determine. However the minimum resolution is distinct campuses.
Within a campus, identifying separate WiFi hotspots isn’t required. Institutions should provide a detailed eduroam hotspot map (likely similar to institutional WiFi coverage map) on their institutional eduroam webpage.
RADIUS servers can be configured to operate as “Service Providers”, proxying all requests to the National RADIUS Servers, or as Identity Providers, authenticating local realms.
For Identity Provider participants, the institutional realms supported will include at least the primary domain (with an appended “.au” country code DN component if the primary domain doesn’t include it).
Note that only under rare exceptional circumstances will AARNet allow an Identity Provider institution to use a realm which doesn’t include “.au”.
The RADIUS servers that are configured to handle an institutional realm may be a subset of all RADIUS server specified under the “Servers” section.
Eduroam infrastructure monitoring is a goal of AARNet as NRO. In order to perform monitoring, an institutional test account is required to be provided by institutions.
A test account for specific realms (or a single test account that will work with multiple realms) should take the name “eduroam-test@realm”.
The authentication protocols supported should also be specified. It is recommended that PEAP/MSCHAPV2 be the protocols supported & recommended for use by users, as a challenge-response protocol provides an additional layer of security in case of rogue APs/RADIUS servers.
Eduroam AU policy requires that a technical contact which is a personal contact is provided. A group account (e.g. an IT service desk address) may also be provided.
Ideally two administrator contacts are provided.
The AdminTool is monitored via AARNet NOC.
If the server dies or the web server ceases to respond, an alert will be raised and a notification sent to the AARNet Service Desk, who will investigate and contact AARNet’s eduroam technical manager if required to restore operability.