This repo is now deprecated: it has been superseded by govwifi.
This is the documentation for the user.wifi backend infrastructure. If you’ve found this from a search online for user.wifi, and would like to use the service [read this] () If you’d like to implement user.wifi at a site where you offer guest wifi [read this] (https://governmenttechnology.blog.gov.uk/2016/06/17/wi-fi-security-and-government-wide-roaming-solutions/).
Note there are multiple copies of this repo, the one under AlistairHCowan in github is the master at the time of writing.
A secure guest wi-fi service for UK government buildings.
User.wifi :
- Onboarding process
- new guest wi-fi users can sign up by SMS, user.wifi creating and issuing a unique and unchanging user + password and storing these in a database
- has a similar process for sponsored sign up by email
- accepts RADIUS requests from users attempting to join the user.wifi SSID in government buildings, and checks against the database
- additionally checks if the site has a 'snowflake' rule requiring additional log in requirements to be met, and notifys the user of these requirements by SMS
- Sites wishing to roll out user.wifi need to connect their APs or AP controllers to user.wifi Q: how? IPSEC tunnel? is this always the case? what does it terminate on? what automation exists
To accomplish the above we have the following components:
- A database to store details of sites, users and passwords
- An API (RESTful) tier that talks to the database, making changes as required
- A RADIUS tier that APs use to connect to that talks to the API tier
There are two databases, one for dev, which supports the user.wifi.dev SSID, and one for prod, which supports user.wifi.
This is a cluster of docker containers running apache + php. The bulk of this repository is the php and other data that builds and runs these docker containers.
This is a cluster of docker containers running a copy of freeradius, with an experimental API backend extension compiled in. These apply some basic ACLs to incoming requests, then handle reformating them as API calls and handing the to the API tier. There is also a healthcheck HTTP service running, which checks the health of freeradius and it’s connection to the API, and will return an error code if a fault is detected -- this is required for healthchecking.
Sadly, because Cisco suck, we use fixed IP addresses for connectivity to the RADIUS tier. These are elastic IPs, which should NEVER be returned to the AWS pool as this would require the field-reconfiguration of every government site using user.wifi.
Q: where does the kiosk docker instance fit into this?
[AWS account] (https://344618620317.signin.aws.amazon.com/console)
SSH dev/test/management host
If your source IP isn’t in the Security Group, you’ll be denied.
Following would be nice
- Logs to cloudwatch
- Alerts from cloudwatch
- hotspot map of users joining user.wifi
Following items need doing
- automate dev box backups
- install Jenkins on dev box
- make the dev box rebuildable with code on demand
- sort out the multiple repos and move everything to one place
- more documentation
- docker configuration to be moved to version control, perhaps with more use of environment variables with secrets elsewhere?
- port the whole thing to GCE
- replace systemd with init and friends
To be documented:
- Site onboarding
- Site decommissioning
- Site IP address change
- User phone number change
- User password reset
Available on request from Alistair Cowan [mailto:[email protected]]
docker-wifi-backend, docker-radius-rest, docker-wifi-kiosk dev box actually runs dev prod runs under terraform , dev runs under dev box rds for dev seperate for prod config in containers, not to be made public enrolment.cfg, along with apache in /etc all messages in /messages it will retry sms providers as required radius west will self destruct nightly and rebuild it’s grabs a file from wifi-backend with wget ... destroy all in the event of a new site
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent