Changes between Version 1 and Version 2 of doc/developer/WiFiDogRadiusWISPr

Show
Ignore:
Timestamp:
10/30/06 23:21:39 (15 years ago)
Author:
benoitg
Comment:

A few more links, and talk a little about WPA

Legend:

Unmodified
Added
Removed
Modified
  • doc/developer/WiFiDogRadiusWISPr

    v1 v2  
    22Original author: Benoit Grégoire, last modified: [[Timestamp]] 
    33= What is RADIUS and current support in wifidog = 
    4 RADIUS (Remote Authentication Dial In User Service) is the industry standard for sharing user network access control information.  As WiFiDog was not originally designed to manually manage users.  User's were meant to self-subscribe, to be computer validated and for a computere to enforce abuse-control policies.  Most organisations that the core developer's belong to still don't have a need for it. 
     4[http://en.wikipedia.org/wiki/RADIUS RADIUS (Remote Authentication Dial In User Service)] is the industry standard for sharing user network access control information.  As WiFiDog was not originally designed to manually manage users.  User's were meant to self-subscribe, to be computer validated and for a computere to enforce abuse-control policies.  Most organisations that the core developer's belong to still don't have a need for it. 
    55 
    66However several new users of wifidog not only want to human-verify users, but also have existing userbases in RADIUS. 
    77 
    8 Luckly for them, [http://www.idrc.ca/ IDRC (The canadian government's International Development Research Centre)] paid for Technologie Coeus inc to write a RADIUS authenticator as a proof of concept.  It's based on the [http://pear.php.net/package/Auth_RADIUS/ PEAR Auth_RADIUS package].   
     8Luckily, [http://www.idrc.ca/ IDRC (The canadian government's International Development Research Centre)] paid for Technologie Coeus inc to write a RADIUS authenticator as a proof of concept.  It's based on the [http://pear.php.net/package/Auth_RADIUS/ PEAR Auth_RADIUS package].   
    99 
    1010 * The good news is that it supports all the features of Auth_RADIUS. 
    1111 * The bad news is that it only supports the features of Auth_RADIUS. 
    1212 
    13 With these limitations, the RADIUS authenticator should only be used by organizations that either: 
     13With these limitations, the RADIUS authenticator should probably only be used by organizations that either: 
    1414 * Already have a userbase in a RADIUS server 
    1515 * Want to manually subscribe and validate users (this is temporary, as wifidog will get a user manager before 1.0). 
     
    1717In other words, currently, using RADIUS to authenticate has little advantages over the internal authenticator beyond allowing you to use RADIUS. 
    1818 
    19 However, technically RADIUS could be used for several purposes in Wifidog 
     19Technically however RADIUS could be used for several purposes in Wifidog: 
    2020 
    2121== Allowing the auth server to authenticate against an existing RADIUS server == 
     
    3434 
    3535== Using RADIUS as the gateway-auth-server protocol == 
    36 It would actually sense to do this, as RADIUS and it's various standardized extentions allow communicating most of the things we want to communicate with the gateway (and has standard ways to be extended to support what it doesn't have).  Unfortunately, this will have a few very practical problems: 
     36It would actually sense to do this, as RADIUS and it's various standardized extensions allow communicating most of the things we want to communicate with the gateway (and has standard ways to be extended to support what it doesn't have).  Unfortunately, this will have a few very practical problems: 
    3737 * We wouldn't use RADIUS to actually authenticate the user credentials, so this will clash with most's people's common conception of what RADIUS is, possibly negating the advantages of using a standard protocol. 
    3838 * It may lead people to think (or repeatedly demand) for the wifidog gateway to be usable against a standard RADIUS server, which would be a tech support nightmare. 
     
    4545Neither of these solves the quirky problem of running PHP code as long-term listeners. 
    4646 
    47 But the entire problem is only caused by the fact that a RADIUS listener is difficult to implement on a PHP web server.  RADIUS is a request-response protocol like http.  So the problem can be sidestepped by mechanically packaging RADIUS requests as XML documents or directly as text over https and sending responses the same way, skipping the whole complexity, and allowing support for a future "real" radius server (all the code would be compatible). 
     47But the entire problem is only caused by the fact that a RADIUS listener is difficult to implement on a PHP web server.  RADIUS is a stateless, request-response protocol like http.  So the problem can be sidestepped by mechanically packaging RADIUS requests as XML documents or directly as text over https and sending responses the same way, skipping the whole complexity, and allowing support for a future "real" radius server (all the code would be compatible). 
    4848 
    4949= What about WISPr = 
     
    6868This is basically a way for a device to potentially script the login process for portable devices (WiFi SIP Phones, WiFi Digital Cameras, Nintendo DSs, standalone instant messengers, etc).  Should this get widespread industry support, it's one way to solve the [wiki:doc/developer/SupportingDevicesWithNoWebBrowser problem of supporting devices with no web browser].  It's actually quite demanding for manufacturer to implement (hence probably not the best solution), but very easy for WiFiDog to support. 
    6969 
     70= What about supporting WPA? = 
     71There has been some recently renewed interest in supporting WPA with wifidog.  Let's first answer the most basic question, is it worth doing in (or more exactly with) wifidog? 
     72 
     73Yes, to the extent that the users could STILL be splashed the portal page, even when authenticated with WPA.  Remember that the primary goal of the wifidog project is to be a location-aware captive portal, not an authenticator.  Respecting the basic premise of "as little as possible on the gateway side", there are still a few possible approaches (some depend on the way we implement RADIUS above).  I can see two that are most likely: 
     74 
     75 1. Write an OpenRADIUS authorization module to allow it to authenticate against a wifidog auth server.  Then the auth server knows that a client is already authenticated over RADIUS, and skip the login page.   
     76  * Advantages 
     77   * Requires no modification of the gateway 
     78   * Uses standard software whose primary job it is to support WPA and RADIUS well. 
     79  * Drawbacks 
     80   * Requires a separate, completely redundant RADIUS server 
     81   * Requires the client to have a web browser to trigger the standard wifidog auth exchange with the server. 
     82 1. Write a simple RADIUS forwarder as a wifidog gateway plugin.  The forwarder would listen on radius, and re-transmit the messages over http to the auth server.  The gateway can peek at the RADIUS responses to know if the client has already been authenticated. 
     83  * Advantages 
     84   * Does not requires a separate RADIUS server 
     85   * Would work with WPA client with no web browser 
     86  * Drawbacks 
     87   * Requires writing part of the radius transport protocol on the gateway side (re-inventing the wheel) 
     88This only makes sense if we want to reuse the "RADIUS over XML or text" code we may write to allow wifidog auth server to talk to each other. 
     89 
     90 
     91