"authorize" etc. in v3.1

[Alan DeKok]

On Mar 9, 2015, at 7:04 PM, Matthew Newton <mcn4 at leicester.ac.uk> wrote:
>> 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”.

  Hmm… I was thinking it would help.

Q: What does the server do when it receives an Access-Request packet?

A: process it through a “receive Access-Request” section.

  That seems pretty simple.  Sure, it means people have to know what Access-Requests are, but… if you don’t know that, you won’t get very far with RADIUS.

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

  Sure.  It’s a balance, right.  Simple enough that the beginner can understand it, and complicated enough that the expert can get things done.

  Right now the complexity is a source of frustration and confusion.  The code to implement it is awkward.  It’s hard to reason about what each section does.  The sections aren’t really handled consistently.

> 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

  Yes, that would be the idea.  The templating would allow the *current* configuration to work unchanged.  But would also allow for *updated* configurations to work better.  And it would make the code much simpler.

> This would also mean that a more advanced admin could quite
> happily write
> 
>  send Access-Challenge {
>    ...
>  }

  Exactly.

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

  Hmm… maybe.  I’d prefer to avoid that for a host of reasons.

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

  Exactly.

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

  Sure, that could work.

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

  That I find a bit more confusing.

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

  Me either.  They’re similar, but *named consistently*.  If you get confused as to what’s going on, just look at the name.

  Alan DeKok.