[isf-wifidog] radius-http proxy

[wlanmac]

Hello,

As an update, I wanted to share with you some new features soon to be
added to CoovaChilli, which may be of interest to your community. Work
has been commissioned to offer a web-only based option to chilli -
allowing it to work, not only with it's standard RADIUS-centric methods,
but to have an optional "HTTP AAA protocol". Of course, that sounds a
lot like WiFiDog, so we've decided to try and be as compatible as
possible. 

What we've done is created a little  server that becomes a RADIUS server
on the localhost running chilli. This server (using libcurl "multi"
interface and a single process) translates the RADIUS requests into HTTP
requests, waiting for the responses. The chilli_proxy is already in our
subversion and the protocol is being documented here:

	http://www.coova.org/CoovaChilli/Proxy

With chilli becoming more firmly embedded in projects like
open-mesh.com, I hope this solution will give your community more
options in terms of hardware and meshing through such vendors. 

Best regards,
David


On Tue, 2009-05-26 at 12:36 -0400, Marc Blanchet wrote:
> wlanmac a écrit :
> > The question becomes, where should it be optional? 
> > 
> > Optional in the way it is now where it is used by the portal to be
> > compatible on the roaming side,
> > 
> > AP/WiFiDog ---> <wifidog protocol> ---> WiFiDog Portal ---> RADIUS
> > 
> > or optional for access provisioning to the router, for device / access
> > controller compatibility? 
> > 
> > AP/NAS ---> <RADIUS> ---> <something?> ---> WiFiDog Portal
> > 
> > (Note: "NAS" for Network Access Server is a more generic term for access
> > controller in RADIUS documentation). 
> > 
> > A concept I have been thinking of would be something along the lines of
> > what Marc suggested. A proxy to map the AAA features of a NAS with the
> > WiFiDog HTTP protocol. 
> > 
> > Such that you might have:
> > 
> > AP/NAS/Proxy ---> <wifidog> ---> WiFiDog Portal (to support old-school
> > sites)
> > 
> > AP/NAS ---> <RADIUS> ---> Proxy/WiFiDog Portal (to support standard
> > access controllers)
> > 
> > AP/NAS ---> <RADIUS> ---> <FreeRADIUS/SuperProxy> ---> Multiple WiFiDog
> > Portals based on Realm (the future)
> > 
> > It's just an idea... but, could be a way of achieving the best of all
> > worlds, RADIUS-wise.
> 
> you were just 5 minutes faster than me to write almost exact same
> drawings... a few minor edits below:
> 
> this is my view of v2:
> 
> "v1" AP -> wifidog-http -> v2 wifidog portal -> radius backend
> "v2" AP ->              radius               -> radius backend
> 
> roaming user:
> - radius servers of the projects that want to enable roaming between
> themselves are configured in a federation mode with a central proxy or a
> server mesh (if the group is small).
> 
> Marc.
> 
> > 
> > David
> > 
> > 
> > On Tue, 2009-05-26 at 11:49 -0400, Sylvain Carle wrote:
> >>> je ne suis même pas sûr qu'on ait besoin d'un BD dans wifidog. En tout
> >>> cas, pas besoin pour le côté opérationel: i.e. authentification,
> >>> service, usagers, etc...  tout devrait être géré par RADIUS.
> >> I would say "all could be managed by Radius" but it should remain an 
> >> option, not the only way. Radius is great but it might be too much to 
> >> ask to some of the communities listed on 
> >> http://dev.wifidog.org/wiki/Community - we should not forget that some 
> >> organizations have less ressources, we shall not create a situation 
> >> where they can't use wifidog anymore.
> >>
> >> --
> >> Sylvain Carle
> >> www.afroginthevalley.com
> >> _______________________________________________
> >> WiFiDog mailing list
> >> WiFiDog at listes.ilesansfil.org
> >> http://listes.ilesansfil.org/cgi-bin/mailman/listinfo/wifidog
> > 
> > _______________________________________________
> > WiFiDog mailing list
> > WiFiDog at listes.ilesansfil.org
> > http://listes.ilesansfil.org/cgi-bin/mailman/listinfo/wifidog
> 
>