Captive portals allow you to leverage a common browser as a secure authentication device. They also have the potential to allow you to do everything securely via SSL and IPSec and setup per user quality of service rules, and still maintain an open network. If you are curious about why you might want to install a captive portal please see WhyCaptivePortal. You can also see the beginning of our software requirements process at CaptivePortalDefinition.
Captive portals are becoming a popular way for SMS/BSN vendors to provide user authentication and IP flow management (basically traffic shaping and bandwidth control) without a required client application. They work by forcing un-authenticated users to a web page, once you have "captured them" this way by allowing the web page to interact with the router/firewall you can completely control their access.
- I'm in the preliminary stages of writing code and seeing how I want it to work. Currently I'm using perl and though I'd love to use this an an excuse to learn python, it would slow me way down right now.
- I reference Linux cause that's what I know, not because it's better/worse then your 1337 OS.
All software will be released under the [http://www.fsf.org/copyleft/gpl.html GNU General Public License].
- A new user gets physical connectivity to the wireless network (eg. they plug in their wireless card within range of one of our antennas).
- They issue a DHCP request and are assigned an IP address (all un-authenticated IP's are firewalled so they can only talk on the local segment).
As soon as they open their browser they will be forced a local web page (the CaptivePortal). Here they will be given the chance to log in as a community user, sign up for a new account or request guest access.
- The portal authenticates them against some form of user database (ldap, radius etc).
- Based on a successful authentication the portal then does the following things:
- Updates the user database saying that they have authenticated and are good for X amount of time.
- Grants their IP access through the firewall.
- Sets QoS routing rules so that they get provisioned a certain amount of bandwidth (eg. local users might get more then roaming registered users, who in turn might get more then unknown guest users).
- Now once every X hours/days the portal goes through it's list of all the ip's allowed through the firewall (ie. authenticated users) and checks to make sure that they are still allowed access:
- If they are, great carry on.
- If they aren't, remove their access. The next time that user wants access they will hit the portal again and have to log in.
Comments and Thoughts:
I think that this is all relatively straight forward to implement. It'll basically just be a matter of setting up the user database, and some web scripting to interact with the server to change system settings. The reason for a central user database (instead of sticking with the autonomous system model we use elsewhere) is that it makes authenticated roaming possible and also moves the user database (really the only important data that the portals will store) to a more reliable distributed model. We'll see if it's really as easy as all that ...
Why bother with this? Because I want to avoid the tragedy of the commons. If we just open up our networks sooner or later people will start to abuse it because they didn't work to set it up and they don't know the people that did. I want this to be an open network by choice rather then because we don't have the ability to control it. The time will come when we're going to be forced to control it or the network will die from abuse.
Why do something like this instead of PPPOE, IPSec or Authenticated DHCP?
- All of those require a client app, which means it's harder for inexperienced users to get started and thus will require more support from the community. All the portal requires is a web browser.
- All of those but IPSec require clear text logins. The portal can do everything over SSL/TLS. IPSec is a good solution, and has the additional benefit of encrypting traffic after authentication. However I'm not sure how it will scale and there is a shortage of good clients for Windows and Mac. Also it is my belief that general transport security should be the clients responsibility not the servers. The servers responsibility is to allow you to authenticate and get on with your business in a convenient and secure manner.
Information from Other Projects:
- Mobility between Public and Private Networks by Allen Miu
The guys at NoCat have drafted an RFC on how a CaptivePortal might work.
For examples and downloads of various Captive/Forced/Active Portal software please see the PortalSoftware page.
Additional note on potential hardware: FreeGeek has lots of old 486 boxes I bet they would be happy to give by the dozens to act as routers or hubs. (Would need to be router-on-a-floppy or other tiny linux, I suppose, as most large, working hard drives they have, they use.) -JonGracie