"authorize" etc. in v3.1

[Alan DeKok]

On Mar 11, 2015, at 12:06 PM, Phil Mayers <p.mayers at imperial.ac.uk> wrote:
> Things like DHCP and DNS have similar issues, and similar levels of lazy/clue are evident on the dhcp-users and bind-users mailing lists, their better docs notwithstanding.

  Not only better docs, but simpler configurations.

> However, I share some of the concerns in this thread. My gut feeling aligns with Matthew/Sam - this will confuse the (sadly very common) inexperienced and lazy first-time user. This is just a gut feeling, and I'd love to be proven wrong.

  I’m almost OK with that.  If you don’t have the time to understand *anything* about the software you’re using, you probably shouldn’t be using it.

> At the same time, I do see the problem in making a maintainable codebase at the same time as new features, absent a generous corporate sponsor.

  Yeah.  While I’m doing FreeRADIUS full-time now, as is Arran… we spend much of our time paying the bills rather than improving the server.

> Maybe the server core *should* be a set of very low-level "receive" / "transmit" hooks, that call into a high-level processing language - a full-featured, complete, language, with robust threading, flow control and modern features, let's say an embedded JavaScript or Lua interpreter, for a straw man.

  Arran and I have discussed that.  It’s not a bad idea.

  The problem is the protocol-specific mangling.  i.e. EAP, SQL, etc.  There’s a *reason* that complexity is hidden in modules.  That’s hard to duplicate in lua.

> Anyone wanting to go beyond the default processing rules can locally fork the processing script and customise to hearts content.

  You’re presuming they’ll read it.  I’m not so optimistic.

> It might look something like this:

  I’d find that confusing.  A mish-mash of lua and calls out to FreeRADIUS modules...

> In particular I think it would be very helpful for the high-level script to provide a kind of "session" abstraction that corresponds to the points in an EAP exchange that, intuitively, people care about - at the "demand" time for inner EAP credentials, and immediately before making the decision to send an inner accept.

  Sure, that could help.

  But people often want to use EAP and non-EAP from the same clients.  Getting all that to work simply and easily is hard.

  The current “default” server could be simplified I think.  BUT at the expense of making it not work for some people.

> Alternatively, maybe in addition to the low-level events, synthetic "high-level" events, strategically picked, could fulfil 90% of use-cases. Maybe most people will never need to expand beyond this:

  That’s useful.  It could be done today with the default virtual server and some new policies.

> It's a tricky one, and I suspect it'll be hard to know if any decision you take is right until a couple of years down the line :o(

  Exactly.

  Alan DeKok.