Why Authorization before Authentication?

[Fajar A. Nugraha]

On Wed, Nov 23, 2011 at 11:21 PM, Edgar Fuß <ef at math.uni-bonn.de> wrote:
>> My recommendation to anybody who asks this question [...],
>> is to think of authorisation being separate from generating the reply.
> Do I understand you correctly in that you only recommend to /think/ that way, not that it's actually /done/ that way?

It's done that way.

> As I understand it, crucial parts of the reply are set up in the users file, which is called by the file module in the authorize section.

Arran said "The users credentials are retrieved in authorize".
A more detailed explanation would be that in authorize section, FR
pulls some data from whatever backend it uses (users file, db, ldap,
whatever) which contains:
- user's password (e.g. Cleartext-Password)
- some attributes to match a particular user (e.g. this crededential
will only be used if user A is coming from a PC with MAC address Y)
- some attributes to control FR's behaviour (e.g. Pool-Name, which
will be used to choose a dynamic IP address)
- some attributes to send in the reply message (e.g. Reply-Message,
Framed-IP-Address)

After the authentication phase, then the actual reply will be
generated based on the data retreived earlier. If the authentication
phase succeeds (i.e. the crededentials match), then these data will be
used to construct access-accept. If it doesn't match, most of the data
will be discarded (e.g. you can't have Framed-IP-Address in
access-reject)

-- 
Fajar