On 11/03/15 13:49, Alan DeKok wrote:
So… how do I make the software better? BY making it simpler for *me* to continue developing it.
I consider a big problem with RADIUS to be that people want to set it up and forget about it, but the problem space doesn't lend itself to that, because the "state of the art" for authentication is really pretty poor, and always moving forward. 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. 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. 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. Given that, I wonder if it's worth considering something substantially more... radical. 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. Maybe the server config should come with a default supplied "processing script" that builds a high-level construct on top of that, and fulfils 90% of common needs - which these days, really means EAP, PAP, DHCP (VMPS and mac-auth being special cases of PAP). Anyone wanting to go beyond the default processing rules can locally fork the processing script and customise to hearts content. It might look something like this: server name { listen { ... } script = ${raddb}/processing.{js,lua} local-config { module-call { eap pap } eap-user-lookup { module = sqlmod query = "select attr,op,val from ... where ..." } eap-user-check { action = permit match = SQL-Group == 'foobar' } pap-user-lookup { ... } } } The script would actually be the thing processing the entire "local-config" block - the server wouldn't do much other than provide the script an API to call modules and modify the packet. 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. It could build that on top of the EAP state machine and the radius "State" variable. This is only a semi-serious proposal - there's probably a lot wrong with it. But if we're considering exposing users of FreeRADIUS to the inner details, it might be worth considering other ways to capitalise on that, and moving those details out of the compiled-in code entirely, into a language with a lower maintenance burden (if you buy that argument, that is...). 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: process eap-tunnel-ready { # SQL/LDAP lookups go here } process eap-tunnel-success { # VLAN assignment/logging goes here } process eap-tunnel-failure { # logging goes here } 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( And someone will always disagree with whatever you decide; bikeshedding is super-hard to avoid. Cheers, Phil