[Wifidog] Version 1.0

Philippe April papril777 at yahoo.com
Thu Apr 22 09:48:54 EDT 2004


> On Thu, Apr 22, 2004 at 08:23:51AM -0400, Philippe April wrote:
>>
>>   * this is all done by the authentication server. From now on, the
>>     authentication server will only say "yay" or "nay", and an optional
>>     error message. When the token gets re-validated every 5 minutes by
>>     WiFiDog (asking the auth server), for a "validation_required" status
>>     the auth server will change the status after 15 minutes if no
>>     confirmation has been done.
>
> 	I would rather this be an UserClass that the GATEWAY will expire
> after 15 minutes and the Auth Server will not allow to login twice.
>
> 	It's my belief that the Gateway should take care of deciding when
> a connection ends.

Remember, this is for version 1.0. Eventually, it will be configurable,
just not now.

1.0 should have a default timeout for all users, configurable on the
hotspot. Later, it will be configurable per user class or per user, on the
authentication server.

The rules (timeout, acls, bandwidth, etc.) will be pushed by the hotspot
when the user gets authenticated. We might need the userclass+rights then,
just not now.

This is why I'll be keeping a diff before removing it, we might still need
it.

>> So in general, it's the authentication server that makes the decisions
>> of yes or no. Eventually, he will push the entire profile of the user
>> (ACLs, traffic shaping rules, etc.)
>
> 	I think Gateway makes decisions on Existing connections. The Auth
> Server does not decide when a connection ends.

We have talked about that and thought it'd be better that the
authentication server decides when the connection ends for pretty much
everything (for now it won't timeout the user BUT if the user was granted
"temp" access for 15 minutes, after 15 minutes if it was not confirmed it
will just disable the account). We'll have to discuss that.

In 1.0, the auth server will return 0 or 1 for authentication. If auth is
succesful, it returns 1. If account is disabled or locked, disabled,
whatever, it returns 0.

In later versions, if the hotspot owners see abuse on his hotspot from a
user, he should log in to the auth server and modify the ACLs for that
user on his hotspot. Then, when the token will be revalidated (everytime
the counters are checked), the auth server will return 0, therefore
disabling the connection.

>> I think the entire code for userclasses is not needed anymore and I will
>> remove it from CVS, but keep a diff of it in case I was wrong and we
>> need
>> it, but as talked with Daniel Drouet and Benoit, I believe the goal is
>> to
>> have hotspot owners customize what they want on the AUTH server and not
>> on
>> the router, so no custom configuration on the router.
>
> 	That will also break the UserRights stuff which is in userclasses.c.
>
> 	Not a major thing if you're rewriting the whole connection validation
> block, but it will require changes to t_node.

Yes, I will take off the Rights too and add what's needed to t_node..

>
> 	As an asside, I disagree with the wholesale turning over of all the
> validation tasks to the Auth Server. The Gateway should take care of
> expiring things in my mind. The AuthServer might well tell it how, but I
> don't think it should do it.
>
> 	Sorry for missing the meeting, I've had unplanned stuff come up
> with my new job.

I just hope you understood the whole thing we're trying to achieve while
by doing these changes.

The gateway will still decide some things, but I think we're now aiming to
produce some kind of blackbox that you can just hook somewhere and you're
ready to go without any config. If it breaks, you replace it with another
one and you only have to configure minor things like the interfaces, IP
address of the internal interface and the hotspot id.

Voice up your concerns regarding the things you don't like and we'll see!

And Pascal, Benoit or Daniel, if you think I did not explain the things
the right way, please reply to this email!

Philippe

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



More information about the Wifidog mailing list