Why Authorization before Authentication?

[Fajar A. Nugraha]

On Thu, Nov 24, 2011 at 11:49 PM, Edgar Fuß <ef at math.uni-bonn.de> wrote:
>> - identify
>> - authenticate
>> - authorize
> Ah, thanks! I understand the process much better now, replacing the section names (authorize, authenticate, post-auth) with what you gave (identify, authenticate, authorize).
>
>> Put your authorization policies in [the post-auth] section.
> OK, now it all makes sense.
> But then I need to communicate things from authenticate to there. Where can I learn which Items I'm allowed/supposed to use for that?

One way to learn is to look at the example in sites-available/default.
Some common use for post-auth:
- logging (sql, sql_log, reply_log)
- allocate ip address (sqlippool)

Another thing you can do on post-auth is perform various checking and
attribute modification using unlang (see "man unlang"). Unlang can
work on some types of variables, including:
- check attributes (e.g. from radcheck table, users file, whatever)
populated during authorization phase.
- request attributes (i.e. the attributes sent by NAS)
- reply attributes (i.e. attributes that FR will send to the NAS as
the result of previous authorization and authentication phase. Can
contain data from radreply table, users file, etc)

So to answer your question, to "communicate things from authenticate
to there" you simply use those variables. e.g.:
- %{request:User-Password} -> the password sent by user if it uses PAP
- %{control:Pool-Name} -> pool-name set (for sqlippool) in radcheck

You can even get additional data directly from your backend. For
example, you want to include a custom Reply-Message attribute using
data from an SQL table. You can use this in post-auth:
    update reply {
                Reply-Message += "%{SQL: SELECT comment FROM
comment_table WHERE username='%{User-Name}' } "
    }

Again, see "man unlang" for more details.

-- 
Fajar