Alan, I really appreciate the effort you're putting into FreeRadius and in responding to all the problems posted to the list - this is no easy feat and I commend you for that.
That being said, you *are* redefining terms and behaviours, and that raises barriers for others to adopt your product. I see them as I am migrating to freeradius, so all I can do is point them out, you are free to disagree of course and keep it the same way.
As a developer, I can certainly #define APPLE ORANGE in my head and then work with it if that's what it takes. However I believe it's important to reduce the amount of new/different concepts when there is already an established way of interpreting them. This helps not only with making it easier for others to use freeradius, but won't cripple them when working with other products which use the terms in a more usual way.
Alan DeKok wrote:
"L.C. (Laurentiu C. Badea)" <[EMAIL PROTECTED]> wrote:
I am having some difficulty understanding why the authorize section has that name. It does not authorize anything per se, and in fact that word does not appear in the phrase if you try to describe what it actually does (which seems to be: define the processing pipeline for a given request).
It authorizes users to use a particular authentication protocol, among other things.
<grin> This is a bit of forced use of a word that generally relates to giving permission or empowering. Fine, but by your definition above, accounting should also have such a section, to authorize users to use a particular accounting procedure. Or for that matter, anything else fits under this broad definition.
On the other hand, it is well-known that generally an authorization stage immediately follows authentication, which is the one referred to in the "AAA" acronym.
All I am saying is that between these possibilities, a more obscure interpretation has been chosen to the detriment of the generally accepted one. It's not sufficient to make yours wrong, but it does make it less right.
This is the way I kind of expected it to be:
"Authentication" answers the question: "are these credentials valid for this user ?". If not, then we reject the user and do not go any further.
"Authorization" answers the question: "is this user allowed to access the resource at this time ?"
i.e. authentication protocol.
Also, if the user isn't allowed to log in at *all* right now, then there's no need to authenticate them. They aren't authorized to do anything.
and it usually assumes a preauthenticated user.
Your assumption is wrong.
Wrong as it may be, apparently RFC 2904 (AAA Authorization framework) seems to agree with this point: "In general, it is assumed that the parties who are participating in the authorization process have already gone through an authentication phase."
According to the above, only the last two items in that section actually belong there (daily and checkval). Lumping everything else together in that section makes the config file difficult to "parse" due to known concepts being given different meanings.
The server has no problem parsing the configuration file. The semantics of that section are well-defined.
Sorry I should have been more clear, by me quoting it like that I meant "parse" by the human reading it. The server definitely seems to have no problems with it :)
-- L.C. (Laurentiu C. Badea)
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
