Our monitoring service provides an easy way to test an Identity Provider works. It emulates a remote service provider on another campus and uses test credentials to perform a full EAP authentication.
If you have enrolled for eduroam CAT, you can use the "Check realm reachability" links in the administrator interface to verify your realm(s) are reachable from Europe. CAT also provides the ability to perform a live login for your realm(s) with test credentials you supply, or to test the reachability of any other valid realm. There are also some limited end-user tests available.
You can, of course, also test your Identity Provider by visiting another campus. However, you should be aware that when you do that, you're also testing that institution's service provider.
To properly test the eduroam wireless network on your campus, you need to try logging in as both a local user and as a visitor. This means you'll need some test credentials from a different identity provider (representing a visitor to your campus).
When you provide us with test credentials to monitor your eduroam IdP, we automatically create a reciprocal test account that you can use to test your eduroam SP (wireless).
The username for the test account is of the form firstname.lastname@example.org. So if your realm is example.ac.za and you've added a monitored realm account of email@example.com via the eduroam management portal, you'll also immediately have a test account of firstname.lastname@example.org that you can use.
The password for this test account will always be the same as the one you supplied for your realm's test account and changes immediately when you update your test credentials in the management portal.
There are some eduroam CAT profiles available for the Test IdP.
The Test IdP supports outer EAP types of either PEAP or TTLS and inner (phase 2) authentication via either MSCHAPv2, PAP or EAP-GTC. It is recommended you test with either PEAP/MSCHAPv2 or TTLS/PAP.
The outer identity is not validated and can contain any value. If you wish to test anonymous outer identities, you may use email@example.com.
By default, the encryption certificate it uses is signed by a dedicated, private CA in accordance with best practice. However, if you wish to test with a public, commercially signed certificate you may pre-select this by using an outer identity of firstname.lastname@example.org, which causes the RADIUS server to use the same certificate as this web site.
Including the string "_frag" in the anonymous identity (e.g. email@example.com or firstname.lastname@example.org) will cause the IdP to inflate the Access-Accept packet by 1800 bytes to try and trigger UDP fragmentation.
To aid with debugging, a subset of the most recent logs from the Test IdP can be viewed at https://eduroam.ac.za/faq/testing/log.txt?q=example.ac.za (where you should replace example.ac.za with your own realm).
Please note the test credentials are for testing by a single institution's administrator(s) only. Do not re-share them with your users or with another institution, or you risk compromising your own test accounts too. The test IdP is deliberately limited to use on three devices within 12 hours to reduce this risk.
Some institutions have exchanged test credentials with each other, much as they've done with ourselves. There's some merit in doing this even if you make use of the Test IdP, since it gives you another perspective and a real-world test case.
This is easiest to arrange when you already know the administrator of the remote eduroam identity provider and can leverage your existing trust relationship with them. Maybe you can reciprocally provide them with test credentials for your network?
You should make sure you are aware of any constraints on those credentials — for instance, not re-sharing them with other institutions. Note: we cannot provide you with another institution's test credentials without their explicit consent.
Once you have some test credentials, you can use them to test that the eduroam wireless network works on your campus in the way you expect. Remember that you need to test with both local (your own) credentials as well as visitor credentials.
You should test as many scenarios as you can — different devices (laptop, tablets, smartphones) and operating platforms (Windows, Linux, Android) — to ensure you're supporting the full array of likely visitors.
Note that there is more to testing than just successful authentication: it is very important that you also test that you've made all the required ports and protocols available (including, for instance, email, SSH and VPN). portquiz.net provides a useful service with open ports you can test against. Please periodically re-test this, as people sometimes inadvertently make firewall changes that break the eduroam service for visitors.
Remember too that visitors to your campus have no knowledge of your network. This means you cannot require them to make any changes (proxy configs, etc) to their device; it should just work™ for them as soon as they connect.
Finally, it is worth reiterating that visitors using eduroam should never be required to open their browser to complete authentication, and should never have to enter their home institution's username and password into a web page. If your eduroam network is prompting users to log in via a web page or click on a web page to accept terms and conditions, you've made a configuration mistake somewhere.
You may also wish to set up automated monitoring of your RADIUS routing in much the same way we've implemented the monitoring service. The rad_eap_test Nagios plugin may be useful here.
We strongly suggest that you make your monitoring system easily identifiable in logs by including suitable connection information, Calling-Station-Id, and/or Operator-Name. You can do this with rad_eap_test as follows:
rad_eap_test -i "0/0 https://yourmonitoringsystem.example.ac.za/" -O "example.ac.za" -M 22:44:66:AB:CD:EF ...
NB: If you intend to use the credentials from our Test IdP for automated monitoring, please be aware that this is a test service and is not intended to be redundant. This means there is a small chance the Test IdP service may report an error even when everything on your side is working correctly. Please don't report such failures to us; our own monitoring will alert us to the problem.
If you're using another institution's credentials, make sure the person who gave you test credentials is aware that you intend doing automated monitoring with them.
eduroam globally is investigating better ways to monitor eduroam service providers. Ideas that are currently in trial include using the RIPE Atlas Network and developing custom probes. We've a limited number of Atlas probes that we can make available for people who want to join the trials.