"authorize" etc. in v3.1

Alan DeKok aland at deployingradius.com
Mon Mar 9 21:26:09 CET 2015


  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.

  The idea is to get rid of the randomly named “authorize”, “authenticate”, etc. sections.  Instead, we will have a standard set of names.  These names are predictable, which is good.  The new names can be mapped (hand-waving here) to the old methods, so upgrading from 3.0 to 3.1 won’t require major changes to the config.

  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 mapping between the new types and old is as follows:

recv Access-Request == authorize

process Access-Request == authenticate (mostly)

send Access-Accept == post-auth

send Access-Challenge == no matching section

send Access-Reject == Post-Auth-Type Reject

recv Accounting-Request == preacct

process Accounting-Request == accounting

send Accounting-Request == no matching section


  For proxying, we no longer have pre-proxy and post-proxy, instead we have:

send Access-Request == pre-proxy

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)

send Accounting-Request = pre-proxy

recv Accounting-Reply == post-proxy

  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.

  There’s also the Autz-Type section, which exists, but is very weird.  Can it just go away?  Does anyone use it?

  There’s also the “session” section.  It doesn’t match the above naming scheme.  Maybe we need something else?

  And what about fail and timeouts?  e.g. “no reply to proxied request” should probably be:

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?

  These things are hard to explain.

  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?

  Alan DeKok.




More information about the Freeradius-Devel mailing list