[Wifidog] Re: wifidog auth service

[Matthew Asham]

On Mon, 2005-01-10 at 14:01, Benoit Grégoire wrote:
> On Sunday 09 January 2005 23:56, Matthew Asham wrote:
> > On Sun, 2005-01-09 at 19:32, Benoit Grégoire wrote:

> Well, in this case the best way to go would be to add RADIUS support to the 
> auth server.  It's the only reasonnable option if you want to benefit from 
> the instant validation services of the auth server for new users who stumble 
> in the range of one of your nodes, and also keep a single sign-on.
> 
> Allowing the server to authenticate to your radius database in addition to 
> it's own should be a reasonable (and technically almost trivial) first step.  
> However that are more complicated issues to consider.
> 
> -How to handle logging?  Currently the auth server can generate some very cool 
> stats.  However, it depends on it's internal user database being up to date.  
> If we authenticate to a RADIUS server, there has to be a way to keep the user 
> databases in sync (at least partially).  Otherwise an easy way out would be 
> to log all connections authenticated against RADIUS to a single 'RADIUS' 
> user, but obviously we loose a lot of information.
> 
> -If we do keep the database in sync, how do we handle someone changing his 
> username?
> 	-Tell radius to change the username (Is that possible?).
> 	-Maintain a mapping of wifidog/radius user.  Not easy if you have multiple 
> servers, and confusing for the user.
> 	-Disable username change for RADIUS users.

> -What happens if a user is already present in the wifidog database, a RADIUS 
> source is added containing a user account with the same username as an 
> existing user?  (Sign on is reasonably easy, just keep trying authentication 
> sources untill the password matches or you tried them all, but then how do 
> you handle logging?)

Unless you have multiple sources and the same username exists on more
than one of those sources, which may or may not be a problem but if we
were to have the authservice auto-create a user as, say,
%RADIUS_SERVER%_matthewa then we still have the problem of
syncronisation.  

What I mean is if someone were to hit the auth service and create a new
user, 'jdoe' and jdoe doesn't exist in radius but does exist in our
primary database (since users have to explicitly activate a hotspot
profile, beit nocat or radius) what happens to jdoe from bcwireless
wanting to login?  They'd have to create a new user account and that
would be a support headache in itself.

So I think the authentication database has to be kept in one place.  

Which brings up another question, would an authservice want to be able
to query multiple authentication sources?  If we're using radius realms,
the auth service could act as a central portal for multiple entities.  I
could login as matthewa at bcwireless.net (@bcwireless.net indicating the
auth realm to query) while someone else could login as 'foo at vcn.bc.ca'
and query vcn.bc.ca's service.

But that wouldn't work well if the realm wasn't already defined
somewhere and the username was created.  If foo at vcn.bc.ca created a
local wifidog account and later vcn.bc.ca became an auth source, which
would have precedence?

So the question is, does the authservice use only one auth source, or
should it be capable of using additional auth sources and if so, how
does it know what source to ask?  iterating through all possible auth
sources for a possible username/password match isn't a safe way to find
a match unless we're matching against a unique realm (such as @domain).

> 
> The only reasonnable solution I can see is to auto-create a wifidog user 
> everytime someone authenticate against a radius server for the first time.  
> The username in wifidog would be RADIUS_SERVERNAME_username.  This way all 
> the rest of the code can keep working the way it used to, and usernames are 
> unique and do not collide.  It would also the creation of new reports.
> 

I'm leaning towards letting the authservice use an internal authent
database, or an external database through an api.  

So password retrieval, login, signup can be done locally or be sent to a
foreign server.  Authent could be radius, or xmlrpc, or whatever.  I
think the code should be modular so it's not dependent on Radius or any
other technology.

And honestly, I don't want to use radius if I can help it. ;)  


> > We don't have any type of syndication or content up.  We're still
> > learning what the auth server can do and we don't have a clear idea of
> > what we want for content yet.  I do know geographical awareness and
> > syndicating content from nearby networks is highly desirable.
> >
> > Regarding integrating it with our existing system, I think what I'd like
> > to do is xmlrpcify WifiDog so our software can add nodes and users
> > remotely and have the authservice direct users to our existing
> > signup/password retrieval pages.   This way we can keep our style
> > consistent, and also let us develop tools to help deploy hotspots
> > quicker.
> 
> Adding nodes remotely is sensible, and I don't see any big problem doing so.  
> It may even be worth it's own XML file format.
> 
> As for user signup/password retrieval, in theory, there should be no problem 
> doing this, but I think it would make much more sense to do it backwards.  
> Your database should be accessible (probably through RADIUS) so that so that 
> the user managements functionnality in wifidog (lost password, lost username, 
> etc.) still works.  Not doing so would be a support nightmare for you  (Trust 
> us...). 

Speaking of which, I can't retrieve my lost password on
http://www.ilesansfil.org/wiki/ 

Could someone fix/upgrade the Wiki? :)

> 
> But I do recognize that you may have a desire to collect more information 
> about your users than we do (we have a rather drastic know as little as 
> possible policy).  I think the simplest and generic solution would be to 
> allow wifidog to include a form fragment from another server or to redirect 
> to that server.  
> The difference between the two being who has to notify the other that his part 
> of the signup was or wasn't successfull, and then send the rest of the form 
> to the other system.
> 

The instant validation is something we'd have to address.  What I'd
probably do is have WifiDog ask our backend to create a new account with
minimal details.  That account wouldn't necessarily be able to do much
in the BC Wireless site but they would still have network access.  

This still assumes that WifiDog is passing it's user functions off to
our backend.

> > One thing I'd really like to see is a node installer that asks for your
> > BC Wireless/<insert CWN group name here> username and password, and self
> > registers itself in the node database.
> 
> We plan to work on something similar, it would be a shame not to join our 
> efforts.

Any code I develop for such a thing would be stuffed into an appropriate
cvs directory.

Matthew

-- 
Matthew Asham - The B.C. Wireless Network Society
http://www.bcwireless.net/ - pots/enum/fax +1 604 484 5289 x1006



-------------- next part --------------
_______________________________________________
Wifidog mailing list
Wifidog at isf.waglo.com
http://isf.waglo.com/mailman/listinfo/wifidog_isf.waglo.com