On Mon, Mar 09, 2015 at 04:26:09PM -0400, Alan DeKok wrote:
The “authorize”, etc. sections are increasingly mis-named. After some discussion with Arran, we’ve come up with what seems like a better approach. I’d like to get other peoples feedback on the suggested design.
Totally agreed on the sections being mis-named. In the AAA sense, "authorize" should really be called "pre-auth" as it's preparing for authentication, then there's "authenticate" (OK), then post-auth should be "authorize". But changing to this scheme would be incredibly confusing.
The idea is to use the following naming scheme:
recv foo — run this section when receiving a packet “foo”. process foo - run this section to process a packet “foo” send foo - run this section before sending a packet “foo”
The coder part of me says "yes". The sysadmin part says "when I was learning RADIUS, it was hard enough to work out what was happening, let alone know what each packet did on the network, so no". The idea is great, but I'm not sure that the naming will be any more helpful for those not well versed in RADIUS (and it's obvious from the list that there are many people in this situation; that's just a fact of life, many probable only run the RADIUS server as a part time thing). However, it _might_ be very powerful and work with some sort of templating or aliasing feature. This is completely off the top of my head, but maybe something like radius.conf: aliases { "select-auth-type" = "receive Access-Request" "authenticate-user" = "process Access-Request" "authorize-user" = "send Access-Accept" "process-failure" = "send Acecss-Reject" ... } select-auth-type { ... eap files ... } etc This would also mean that a more advanced admin could quite happily write send Access-Challenge { ... } which doesn't appear at all in the default configuration, but could be useful in some circumstances. You could also have for example: sent Access-Accept { } which gets called only after the packet has actually been sent, for final logging. Again, probably not in the default config (or aliased as "log-successful-authentication" maybe).
process Access-Request == authenticate (mostly)
I'm not sure that the current config is helpful. It's quite confusing to work out which sections have sub-sections called automatically, or at least it was when still on the learning curve. So authenticate { Auth-Type PAP { ... } Auth-Type eap { ... } } always seems odd. However post-auth { ... Post-Auth-Type REJECT { ... } } seems even weirder, inconsistent even. Two ideas come to mind. The first is adding a parameter to the section name, such as (in current config terminology): authenticate PAP { pap } authenticate eap { eap } mutiple levels, but much clearer IMO. The other, slightly less clear way is pull the hidden switch out into the open: authenticat { switch (Auth-Type) { PAP { pap } eap { eap } ... } } At least that would be clearer, but goes more towards the programming side which I don't think is great for newcomers. Personally I think I'd prefer the first - just a separate authenticate (or process Access-Request) section for each Auth-Type. process Access-Request PAP { ... } etc. [possibly even "process Auth-Type PAP" ??? doesn't fit the model, but reads easier for the admin :-S ]
recv Access-Accept == post-proxy
recv Access-Reject == post-proxy (oops, that’s probably not a good idea)
recv Access-Challenge == post-proxy (oops again)
post-proxy (Post-Proxy-Type Fail) and post-auth (Post-Auth-Type Fail) are already messy IMO, so this might help sort them out.
This suggestion isn’t entirely perfect. The “authenticate” section is really a wrapper for each Auth-Type section. We need to find a way to address that.
Yeah.
There’s also the Autz-Type section, which exists, but is very weird. Can it just go away? Does anyone use it?
I'd suggest scrapping it, but then provide a module that can just call another virtual server. Then it can be rebuilt as current if needed. Or extended further. Got the beginnings of a module that does that already somewhere in my git repo, but can't remember how far I got with it. Isn't a hard module to write.
There’s also the “session” section. It doesn’t match the above naming scheme. Maybe we need something else?
Session is another one of those sections that seems odd to me. Why not just do the simultaneous checks in the authorize/post-auth sections? Though I may not understand it entirely as I don't use it. These days I'm sure it can be replicated easily in unlang; just lookup the unique key (username etc) in a database and send reject if they're already there. accounting{} should keep the database up-to-date.
And what about fail and timeouts? e.g. “no reply to proxied request” should probably be:
timeout Access-Request ???
Fits into the scheme, but seems an oddball. Maybe an alias defined as "proxy-timed-out" = "timeout Access-Request".
Or “no live home server” could be:
fail Access-Request?
I’m leaning towards that method, instead of the existing Post-Proxy-Type Fail, etc. That method is confusing for end users, and hard to code. e.g. Why is “fail” inside of post-proxy? Is Post-Proxy-Type Fail run for normal proxying, because it’s inside of the post-proxy section? It not, why not?
Totally agreed. Current is hard.
If, instead, we had consistent names, it becomes trivial to know what to do. It becomes trivial to know what the names are, and what each section does.
I *believe* we can set up aliases, etc. which will map the new method to the old one. So no one has to butcher their configuration for 3.1. BUT the benefit of using the new naming scheme is legion. The code becomes MUCH simpler, as does the configuration.
Comments? Stones?
No stones :). Just don't think exposing RADIUS packets directly to end users at first sight is the most helpful thing. Yes, they'll hopefully learn them in time, so giving the tools to do this is good, but terms such as "pre-authentication" or "authenticate-user" are easier to begin with. I think some of the above could also be a bit confusing to the advanced admin, such as: send Access-Accept recv Access-Accept are two _totally_ different things on opposide sides of the server (one as a server, the other as a client), yet look surprisingly similar. I'm not sure what else to suggest though. Matthew -- Matthew Newton, Ph.D. <mcn4@le.ac.uk> Systems Specialist, Infrastructure Services, I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom For IT help contact helpdesk extn. 2253, <ithelp@le.ac.uk>