"authorize" etc. in v3.1

[Stefan Paetow]

>  The mapping between the new types and old is as follows:
> 
> recv Access-Request == authorize
> process Access-Request == authenticate (mostly)
> send Access-Accept == post-auth

Fair enough, if you call the section that (i.e. 'recv Access-Request'). That should be fairly straight-forward to understand (especially when liberally commented).

> send Access-Challenge == no matching section

This might be useful (especially when you've got the weirdnesses where you've got a challenge being sent after the 'send Access-Accept' for some reason).

> send Access-Reject == Post-Auth-Type Reject
> recv Accounting-Request == preacct
> process Accounting-Request == accounting
> send Accounting-Request == no matching section

Straight-forward.

>  For proxying, we no longer have pre-proxy and post-proxy, instead we have:
> 
> send Access-Request == pre-proxy

how about 'proxy-send Access-Request' (which under the covers just means 'send')?

> recv Access-Reject == post-proxy (oops, that’s probably not a good idea)

The above resolves this one?

> recv Access-Challenge == post-proxy (oops again)

Ditto?

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

Never seen that really... Autz-Type = Authorization-Type? 

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

Makes sense?

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

Yes. Something being self-explanatory always makes life easier. 

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

As someone who did not have any FR experience in 2012 before starting on Moonshot, starting on something like this as a fresh-faced newbie would probably be easier to understand. 

HOWEVER, I can see why this would/could be a nightmare for those migrating from 2.x or 3.0.x configurations, or those FR newbies who find *loads* of references to authorize, authenticate, session, post-auth, pre- and post-proxy etc on t'Internet. When this happens, the wiki needs to be overhauled as part of this, possibly with two specific sites, i.e. 3.0.x and earlier, and 3.1 and later.

Will try to help with the documentation where possible... Anything to ease the pain of transition for people.

Stefan Paetow
Moonshot Industry & Research Liaison Coordinator

t: +44 (0)1235 822 125
gpg: 0x3FCE5142
xmpp: stefanp at jabber.dev.ja.net
skype: stefan.paetow.janet
Lumen House, Library Avenue, Harwell Oxford, Didcot, OX11 0SG

jisc.ac.uk
 
Jisc is a registered charity (number 1149740) and a company limited by guarantee which is registered in England under Company No. 5747339, VAT No. GB 197 0632 86. Jisc’s registered office is: One Castlepark, Tower Hill, Bristol, BS2 0JA. T 0203 697 5800.
Jisc Collections and Janet Ltd. is a wholly owned Jisc subsidiary and a company limited by guarantee which is registered in England under Company No. number 2881024, VAT No. GB 197 0632 86. The registered office is: Lumen House, Library Avenue, Harwell, Didcot, Oxfordshire, OX11 0SG. T 01235 822200.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.freeradius.org/pipermail/freeradius-devel/attachments/20150311/351669b4/attachment.sig>