(Note: The following was written before NoCatAuth existed)
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.
As far as I am aware no OpenSource software has ever been developed to do this and plan to write this software as part of ThePlan.
Status:
- 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.
Assumptions:
Each WirelessCommunity will have a *nix box as a router (and hopefully eventually as a replacement for traditional AccessPoints).
- I reference Linux cause that's what I know, not because it's better/worse than your 1337 OS.
All software will be released under the GNU General Public License.
Usage Flow:
- 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 than roaming registered users, who in turn might get more than 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:
- maybe router with linux firmware can be used instead? such as wrt54g, wl500g or even asus wl-hdd which can be installed with full-blown debian
another one is WifiDog that can be installed into wrt54g
-- DennyHalim
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.
For examples and downloads of various Captive/Forced/Active Portal software please see the PortalSoftware page.
-- AdamShand
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
Btw, I would assume that NoCatAuth is now a valid system for such a captive portal, is it ?... Maybe a question of the time this was written ? -OlivierBerger
Are you planning on using Radius?
NoCatAuth supports Radius -- AndrewWoods
I just found WiCap, a free self-described "captive portal that doesn't suck"
I haven't messed with NoCatAuth, but the authors of WiCap are describing their system as being like NoCat except easier to configure. It supports OpenBSD, and from looking at it quickly, it appears it might be the only OS it supports. That's fine with me. I love OpenBSD.
http://www.geekspeed.net/wicap/ <- i think this is dead link try this: http://www.shmoo.com/~bmc/software/wicap/announce.html
--ax0n
hi i'm trying to set up nocatauth on openbsd pc and i've to say that's a mess to configure ! took a look on wicap but the manual is absolutely non-existent i'm beginning to despair anyone succeed to set up and run the 2 modules of nocat on 3.4 openbsd ? [CategoryDocumentation]
--bruno
bruno, if you check this.. a better place to ask this question would be to the General Mailing list. See http://lists.personaltelco.net/
For those looking for a Captive Portal for OpenBSD ~3.5...I got fed up and wrote one, I am calling it WiCap-PHP because it is like WiCap but is actually supported and documented...Search the list for more information. You can also email me and I will tell you all about it. WiCap-PHP has a page on this WIKI and is where all updates will be posted.
Isn't there something available that just work? NoCat does not work. It's hell to get setup, then you get it all working and when you try to log in, it redirects back to the login screen in an endless loop.
m0n0wall works great! Radius and everything. But it does not work as a wireless access point. It also requires the whole network to be on NAT.
You might want to have a look at NetLogon. It's a captive portal used at several universities in Sweden. GPL and all. See http://ceres.unit.liu.se/netlogon-devel/
Or you can try myWIFIzone captive portal services. Runs on any Win2K and XP machine on your WLAN for a monthly charge. Free while they are in Beta test phase. see http://www.mywifizone.com/news.asp [CategoryDocumentation]
AmazingPorts will give you a simple to install, free Captive Portal solution for home use - just download, burn CD and install. It handleds QoS on a per service/user level - so you can ensure that your guests don't trash your bandwidth. AmazingPorts also implements Service Oriented Provisioning meaning that you can define services on a granular level not only "internet on/off". Good luck Jan E ( AmazingPorts team)
For Windows hotspot software, try FirstSpot
For Windows freeware, including the ability to block bad/inappropriate sites and time of day use restriction, try DNS Redirector