"authorize" etc. in v3.1

[Matthew Newton]

On Wed, Mar 11, 2015 at 01:14:07PM -0400, Alan DeKok wrote:
> On Mar 11, 2015, at 12:06 PM, Phil Mayers <p.mayers at imperial.ac.uk> wrote:
> > 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.

Yes. It's just a shame that people still do.

I guess it stems from the where RADIUS fits in. Many people likely
have no interest in running a RADIUS server. Their job is, for
example, to "get the wireless network working". A part of this is
having to install this software they don't understand to link
between the access points and whatever backend they have
credentials in. The bit in the middle is just "magic".

Trying to understand something you have no interest in is not
easy. Especially when you're under pressure to provide the
network. Admin is under-resourced? Probably, yes. Fact of life for
us? Yes as well, unfortunately.


> > 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.

I'm not sure it's even got to be that complex or deep. I sort of
like the idea, though it may be adding complexity beyond what is
needed. Not that hidden complexity is a bad thing to make the
server flexible, but hopefully not at the expense of performance.

The thing I usually think about with FreeRADIUS (and have never
managed to actually fully document, though I nearly got there
once) is that there is essentially a hard-coded script running
behind the scenes. It goes something like

when a packet is received:
 - go through authorize
 - check module return codes
 - if Proxy-To-Realm is set:
   - go through pre-proxy
   - proxy the packet
   - end
 - if Simultaneous-Use is set:
   - go through session
 - if Auth-Type is not set:
   - reject
 - if Auth-Type section does not exist:
   - reject
 - go through authenticate section based on Auth-Type
 - check module return codes
 - if success:
   - go through post-auth
 - else
   - go through post-auth/Fail
 - send response packet
 - end

... and the post-proxy bit, etc.

There is definitely a coded flow through the server that isn't
possible to change, but with hidden if()s coded in behind the
scenes (such as checking Proxy-To-Realm).

Maybe, then, rather than re-jigging the config file, abstract it
slightly. Define what happens when packets come in/got out (this
is then the "advanced adminstrator" bit:

  receive Access-Request {
    authorize
    if (Proxy-To-Realm) {
      pre-proxy
      proxy
    } else {
      authenticate(Auth-Type)
    }
  }

  send Access-Accept {
    post-auth
  }

  send Access-Reject {
    post-auth(Post-Auth-Fail)
  }

the above (in unlang) doesn't call modules, but config sections.
Basically, move the hidden server flow out into an unlang
configuration.

This then allows the config to be tidied, but still allow the
existing configurations to work. Code like above matching the exact
current flow is distributed with the server, but you could also
completely change how the sections are called, e.g. the following
would call a section "receive-access-request" and wouldn't ever be
able to proxy anything:

  receive Access-Request {
    receive-access-request
  }

If this lower-level could also call modules, you could easily hide
some things in it, such as preprocess, that the vast majority of
people never need to concern themselves with.


> > 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.

No, they won't. But the idea would be that 99% of admins won't
need to.


> > It might look something like this:
> 
>   I’d find that confusing.  A mish-mash of lua and calls out to
>   FreeRADIUS modules...

It sort of looks nice - the lua (or whatever, maybe just unlang as
above) defines which sections are called in what order. The
defined sections _are_ the same as current config, so do call out
to the current modules.

A solution to this all might be as simple as renaming the config
sections as originally suggested, and adding a "gosub" in unlang
to call other config sections.

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

The current default config, while very flexible for nearly any
setup, is particularly long and complex.

I remember looking at it the first time, and it was daunting. No
idea where things hung together and where to start. There are so
many comments it's hard to read through it. The comments are
really good, don't get me wrong, but are a lot to wade through
when you want to find something when you don't know where to look.

One way to do it might be to break the default config up into
simpler "examples". I keep meaning to try and start putting some
sort of cookbook together, and this is really how it's likely to
look. So instead of "default" and "inner-tunnel" you might have

"wireless-802.1x-active-directory"
"wireless-802.1x-ldap"
"wireless-802.1x-local-auth"
"adsl-chap-sql"
...
etc

"wireless-802.1x-active-directory" might look something like the
following, with very few comments.

modules {
  mschap {
    ...
  }
  eap {
    ...
  }
}
server default {
  listen {
    ...
  }
  authorize {
    filter_username
    preprocess
    eap
    files
  }
  authenticate {
    eap
  }
  post-auth {
    detail
  }
}
server inner-tunnel {
  authorize {
    mschap
    eap
    files
  }
  authenticate {
    eap
  }
}

The idea being that it's a full server config in one file, but as
simple as possible. Then the existing config files are there as
full reference guides with all the configs. Then the new admin
edits wireless-802.1x-active-directory, drops it in sites-enabled,
and hopefully is about the way to a working setup. No need to
worry about configuring the right modules, etc - it's all in the
one file.

To me, that would have been much easier to begin with, as I
wouldn't have been wading through many options that were totally
irrelevant to what I was trying to do, and actually confused me a
lot.

It's trying to get a fine balance between easy for developers,
easy for newcomers but customisable enough for advanced admins.
That's hard.

Matthew


-- 
Matthew Newton, Ph.D. <mcn4 at 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 at le.ac.uk>