...
Some vendors only make Hotspot 2.0 features available on request. One example is Meraki, where you must contact support through the Meraki online management portal to request that Hotspot 2.0 is enabled.
RADIUS Server
Your own RADIUS server can be anything, but if you have a RADIUS server that can speak Radsec, you'll be well on your way there. Radsecproxy is arguably the most well-known open-source Radsec server (and you can put it in front of other non-Radsec servers like Microsoft's NPS) and it is actively supported by the eduroam community; FreeRADIUS 3.2.x has vastly improved Radsec support over earlier versions (you're strongly encouraged to move to the v3.2 branch). Radiator, Cisco ISE and Aruba ClearPass are paid-for solutions that support Radsec, with Radiator very well-suited to do dynamic routing. If you know of other software that supports Radsec, let us know!
Beacon Settings
In order to signal that eduroam users are welcome, a set of these RCOIs can be used. Below are two common choices. Note that the SSID for the network is then arbitrary but SHOULD NOT be "eduroam" as there are known side-effects on supplicants when the network configuration matches both by SSID and by RCOI.
If you are a WBA member, populate the Operator-Name RADIUS attribute with your WBA ID in this format: 4<WBA ID>
, e.g. 4EDUROAM
, or 4JISC:GB
If you are not a WBA member, you will not have a WBA Identifier, so you should probably use 4EDUROAM
to indicate you are an eduroam member. Alternatively, if your NRO is a WBA member (the UK NRO Jisc is), they will likely assign a WBA sub-id to you.
You are required to pop a Chargeable-User-Identity request into your Access-Requests. If you are unable to do this, your uplink can potentially do this. The UK OpenRoaming proxy does this by default.
Beacon Settings
In order to signal that eduroam users are welcome, a set of these RCOIs can be used. Below are two common choices. Note that the SSID for the network is then arbitrary but SHOULD NOT be "eduroam" as there are known side-effects on supplicants when the network configuration matches both by SSID and by RCOI.
- Baseline Participation: OpenRoaming for All Identities, settlement-free, no personal data requested, baseline QoS - includes, but is not limited to users in education and research
- Baseline Participation: OpenRoaming for All Identities, settlement-free, no personal data requested, baseline QoS - includes, but is not limited to users in education and research
5A-03-BA-00-00 - usage of the hotspot is governed by the OpenRoaming End-User Terms and Conditions - Education-Only Participation: OpenRoaming Visited Network Providers who want to signal that they specifically welcome educational and research (i.e. eduroam) visitors settlement-free, should add the following RCOI instead:
5A-03-BA-0800-00 - usage of the hotspot is governed by the OpenRoaming End-User Terms and Conditions(this option makes sense if the hotspot is also welcoming other identities but on different terms, e.g. with-settlement) - Education-Only Participation: OpenRoaming Visited Network Providers who want to signal that they specifically welcome educational and research (i.e. eduroam) visitors settlement-free, should add the following RCOI instead:
5A-03-BA-08-00 - usage of the hotspot is governed by the OpenRoaming End-User Terms and Conditions
(this option makes sense if the hotspot is also welcoming other identities but on different terms, e.g. with-settlement) - The OpenRoaming framework allows announcing better QoS levels ("The OpenRoaming framework allows announcing better QoS levels ("Silver" and "Gold") which come with their own RCOIs, differing from the above in one hexit. Since there is no benefit for an ANP in giving higher guarantees, it is suggested not to announce those RCOIs.
- Note, as of 8 Feb 2021: some onboarding tools and IdPs still use exclusively the pre-standard RCOI from Cisco times. This includes most notably: Cisco "OpenRoaming" app; the Samsung OneUI onboarding workflow. If you want to support users with IdPs served by these tools, be sure to include the RCOI 00-40-96 in the beacon.
- You can calculate other RCOIs supported by OpenRoaming here: https://wireless-broadband-alliance.github.io/OR-rcoi-config/
...
In order to be able to communicate with OpenRoaming, you have to either set yourself up as an OpenRoaming service provider (called an ANP in OpenRoaming land) by applying for a certificate from the Wireless Broadband Alliance (WBA), or you have to connect your server to an uplink (a proxy that gets you access to the Openroaming OpenRoaming network).
- Third-party hotspots which are onboarded in the OpenRoaming ecosystem by a third party need to take no further action. An OpenRoaming ANP uses the normal NAPTR discovery for users from an eduroam realm. This means that eduroam IdPs will need to publish a NAPTR record (see further down) and have it point to an eduroam ↔ OpenRoaming ANP proxy. (eduroam OT provides one such proxy for all eduroam participants; eduroam NROs may provide their own for their own institutional user base).
- Existing eduroam hotspots wishing to make use of eduroam infrastructure as their OpenRoaming uplink provider currently need to connect the Wi-Fi network that has these RCOIs to a proxy run by the eduroam Ops Team - contact points for this are Paul Dekkers and Stefan Winter. Alternatively, contact the UK NRO Jisc, who also operate an eduroam ↔ OpenRoaming ANP proxy.
- If If you intend to be an ANP, depending on your network access provision conditions, you may need to arrange for additional network provision that allows you to route network traffic that does not comply with your existing provision conditions. For example, organisations receiving network access through the UK JANET network must ensure that non-research/educational users are not routed over the existing network connection, but via separate network access (such as a broadband connection from a commercial provider).
- Also, if you intend to be an ANP, you must forward accounting requests to your uplink, and they are required to send those on to the identity provider.
...
- The contact information concerning the Identity Provider in the eduroam Operations Database MUST be complete and accurate, including at least email address, postal address and telephone number
- The Identity Provider MUST generate Chargeable-User-Identity attributes in authentication responses
The DNS zone for the Identity Provider's realm name MUST include a NAPTR record for their realm pointing to an eduroam OpenRoaming interchange proxy. The example below targets the general-purpose proxy operated by eduroam OT; the target host may be different for eduroam NROs who operate their own proxy:
realm.name. 43200 IN NAPTR 100 10 "s" "aaa+auth:radius.tls.tcp" "" _radsec._tcp.openroaming.eduroam.org.
- End user devices need to be provisioned with the pertinent settings to recognise OpenRoaming hotspots - see section "End-User Device Settings" below
- The end users themselves need to be made aware that they are bound by the OpenRoaming End-User Terms and Conditions whenever they connect to OpenRoaming hotspots.
When your user is actually roaming with OpenRoaming, this is visible is in the RADIUS datagrams due to the RADIUS Attribute
...
where the string
is the WBA Identifier of the organisation that operates the hotspot. If you are not a WBA member, you may not have a WBA Identifier. We're establishing how such identifiers can be made available.
End-User Device Settings
Starting with version 2.1, the eduroam onboarding toolset (eduroam CAT and eduroam Managed IdP) integrates Passpoint network definitions in general, and OpenRoaming settings in particular, in its standard workflow. This version is currently available for testing on https://cat-test.eduroam.org with a stale copy of production data.
...
For eduroam Managed IdP, eduroam Passpoint-based profiles are always installed alongside the SSID-based ones. This is expected to work throughout the product palette of Apple, and with no additional user interaction. OpenRoaming is not currently enabled on Managed IdP.
eduroam CAT Mobileconfig files will install OpenRoaming Passpoint profiles when enabled (all EAP types); it will however only install the eduroam Passpoint profile if the IdP's chosen EAP type is "EAP-TLS". This is because of known user nuisances regarding multiple username/password prompts for multiple SSID and Passpoint profiles which CAT minimises by omitting that extra prompt for eduroam Passpoint.
Android
Geteduroam will install an OpenRoaming profile if the configuration exists.
Android
eduroam Passpoint profiles eduroam Passpoint profiles and the optional OpenRoaming Passpoint profiles can be installed only with the new geteduroam app (i.e. not with the predecessor "eduroamCAT"). geteduroam has varying support for Passpoint profiles depending on the Android version and whether the IdP chose "Ask" vs. "Always" - the "Always" variant currently has better support across all supported Android versions; "Ask" support needs special IdP workarounds.
Intrinsic support for OpenRoaming exists on later (read, newer) devices and versions of Android. For example, recent Google Pixel devices (Pixel 5 and later) show "OpenRoaming" as a network when a HS2.0 hotspot is detected. You then have the choice to enable roaming to this network by choosing to use your Google account associated with your Android phone. Apps like 'Cisco Openroaming' also enable an account on the same network. CAT profiles installed with geteduroam will show "<realm name> via Passpoint" instead but do not associate with the "OpenRoaming" SSID. On some Samsung devices, you may see "OpenRoaming available using Samsung Account" instead, which will function in a similar fashion as the Google Pixel.
Linux
TBD.
ChromeOS
SSID. On some Samsung devices, you may see "OpenRoaming available using Samsung Account" instead, which will function in a similar fashion as the Google Pixel.
Geteduroam will install an OpenRoaming profile if the configuration exists. It will show as 'your realm via Passpoint' in your Wi-FI network list.
Linux
Any recent version of wpa_supplicant supports Passpoint, provided it has been built with the CONFIG_INTERWORKING=y
and CONFIG_HS20=y
flags. Check your Linux distribution's build source configurations for confirmation. Instead of using a network {}
block (as you would with a standard 802.1x network), you use the credential {}
block.
To enable Passpoint roaming, set interworking=1
and hs20=1
in your wpa_supplicant.conf, and provide the credential block to use.
More information is available at https://github.com/xradvanyip/hostapd-openwrt/blob/master/wpa_supplicant/README-HS20
ChromeOS
Recent versions of ChromeOS should also support Passpoint. Google is active in the Passpoint community. You should be able to use the geteduroam app for Android on ChromeOS to configure your ChromeOS device for Passpoint. TBD.
Infrastructure
OpenRoaming
...