"authorize" etc. in v3.1

[Matthew Newton]

On Mon, Mar 09, 2015 at 04:26:09PM -0400, Alan DeKok wrote:
>   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.

Totally agreed on the sections being mis-named. In the AAA sense,
"authorize" should really be called  "pre-auth" as it's preparing
for authentication, then there's "authenticate" (OK), then
post-auth should be "authorize". But changing to this scheme would
be incredibly confusing.

>   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 coder part of me says "yes".

The sysadmin part says "when I was learning RADIUS, it was hard
enough to work out what was happening, let alone know what each
packet did on the network, so no".

The idea is great, but I'm not sure that the naming will be any
more helpful for those not well versed in RADIUS (and it's obvious
from the list that there are many people in this situation; that's
just a fact of life, many probable only run the RADIUS server as a
part time thing).

However, it _might_ be very powerful and work with some sort of
templating or aliasing feature. This is completely off the top of
my head, but maybe something like

radius.conf:

  aliases {
    "select-auth-type" = "receive Access-Request"
    "authenticate-user" = "process Access-Request"
    "authorize-user" = "send Access-Accept"
    "process-failure" = "send Acecss-Reject"
    ...
  }

  select-auth-type {
    ...
    eap
    files
    ...
  }

etc

This would also mean that a more advanced admin could quite
happily write

  send Access-Challenge {
    ...
  }

which doesn't appear at all in the default configuration, but
could be useful in some circumstances.

You could also have for example:

  sent Access-Accept {
  }

which gets called only after the packet has actually been sent,
for final logging. Again, probably not in the default config (or
aliased as "log-successful-authentication" maybe).

> process Access-Request == authenticate (mostly)

I'm not sure that the current config is helpful. It's quite
confusing to work out which sections have sub-sections called
automatically, or at least it was when still on the learning
curve. So

  authenticate {
    Auth-Type PAP {
      ...
    }
    Auth-Type eap {
      ...
    }
  }

always seems odd. However

  post-auth {
    ...
    Post-Auth-Type REJECT {
      ...
    }
  }

seems even weirder, inconsistent even.

Two ideas come to mind. The first is adding a parameter to the
section name, such as (in current config terminology):

  authenticate PAP {
    pap
  }

  authenticate eap {
    eap
  }

mutiple levels, but much clearer IMO.

The other, slightly less clear way is pull the hidden switch out
into the open:

  authenticat {
    switch (Auth-Type) {
      PAP {
        pap
      }
      eap {
        eap
      }
      ...
    }
  }

At least that would be clearer, but goes more towards the
programming side which I don't think is great for newcomers.

Personally I think I'd prefer the first - just a separate
authenticate (or process Access-Request) section for each
Auth-Type.

  process Access-Request PAP {
    ...
  }
  etc.

[possibly even "process Auth-Type PAP" ??? doesn't fit the
model, but reads easier for the admin :-S ]

  

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

post-proxy (Post-Proxy-Type Fail) and post-auth (Post-Auth-Type
Fail) are already messy IMO, so this might help sort them out.

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

Yeah.

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

I'd suggest scrapping it, but then provide a module that can just
call another virtual server. Then it can be rebuilt as current if
needed. Or extended further.

Got the beginnings of a module that does that already somewhere in
my git repo, but can't remember how far I got with it. Isn't a
hard module to write.

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

Session is another one of those sections that seems odd to me. Why
not just do the simultaneous checks in the authorize/post-auth
sections? Though I may not understand it entirely as I don't use
it.

These days I'm sure it can be replicated easily in unlang; just
lookup the unique key (username etc) in a database and send reject
if they're already there. accounting{} should keep the database
up-to-date.


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

Fits into the scheme, but seems an oddball. Maybe an alias defined
as "proxy-timed-out" = "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?

Totally agreed. Current is hard.

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

No stones :). Just don't think exposing RADIUS packets directly to
end users at first sight is the most helpful thing. Yes, they'll
hopefully learn them in time, so giving the tools to do this is
good, but terms such as "pre-authentication" or
"authenticate-user" are easier to begin with.

I think some of the above could also be a bit confusing to the
advanced admin, such as:

  send Access-Accept
  recv Access-Accept

are two _totally_ different things on opposide sides of the server
(one as a server, the other as a client), yet look surprisingly
similar. I'm not sure what else to suggest though.

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>