"authorize" etc. in v3.1

[Phil Mayers]

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