Why Authorization before Authentication?

[Edgar Fuß]

A probably simple question I could not find explained in the FAQ or the Concepts section:

Given that Authentication is proving who I am and Authorization is checking what I'm allowed to do, I naively would have expected a RADIUS server to first authenticate me an then check my authorization.
Surely for a reason, what FreeRADIUS does is the other way round: first try all authorization modules and then use one authentication module.
I hope I got this right.
I would like to be pointed to a document explaining the rationale behind this. It's probably obvious to anyone familiar with the matter, but that doesn't include me.

Thanks.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

[Arran Cudbard-Bell]

Post by Edgar Fuß
Given that Authentication is proving who I am and Authorization is checking what I'm allowed to do, I naively would have expected a RADIUS server to first authenticate me an then check my authorization.
Surely for a reason, what FreeRADIUS does is the other way round: first try all authorization modules and then use one authentication module.
I hope I got this right.
I would like to be pointed to a document explaining the rationale behind this. It's probably obvious to anyone familiar with the matter, but that doesn't include me.

It's complicated and imperfect. The users credentials are retrieved in authorize, so it's necessary to run the authorize section before the authentication section, but this could also be done with a pre-authenticate section...

With some EAP modules, you really need to decide what you're going to do before you start authentication. You need to know that you're going to reject the user so you can communicate that to the supplicant in the right way at the right point in the authentication process.

My recommendation to anybody who asks this question (it comes up from time to time), is to think of authorisation being separate from generating the reply.

So you decide whether the user is authorised, you complete authentication, then you formulate the actual response in post-auth ( use section overrides <module>.<section> to run the right logic).

The section names are just names after all, and although yes, there is module logic associated with each section, it's easy to override. If you're unhappy with the way the default configuration works, it's easy to change it...

-Arran

Arran Cudbard-Bell
***@freeradius.org

Betelwiki, Betelwiki, Betelwiki.... http://wiki.freeradius.org/ !


-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

[Edgar Fuß]

Thanks for the explanation.

[This question] comes up from time to time

So it may be nice if someone feeling comfortable enough to answer it could add an explanation to the wiki.

If you're unhappy with the way the default configuration works,

I'm not unhappy with it, it just sounded counter-intuitive to me.

it's easy to change it.

... and mess it up. I'll surely refrain with fiddling around with things I don't fully understand.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

[Edgar Fuß]

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? 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.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

[Fajar A. Nugraha]

Post by Edgar Fuß

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.

Post by Edgar Fuß
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)

[Iliya Peregoudov]

In general there are three steps in processing of Access-Request:

- identify
- authenticate
- authorize

First you need to identify subscriber. In general you should consult
subscriber database (backend). To minimize number of round-trips with
subscriber database it will be better to return whole subscriber profile
to AAA server. AAA server then can consider to proceed with
authentication, grant access without authentication, deny access without
authentication, or just pass the matter to proxy. This is what authorize
section exactly does. Subscriber profile retrieved on this step is
stored ad-hoc, usually in control and reply lists of the request.

To authenticate subscriber you need to check credentials it provides.
This is what authenticate section does. Most of authentication modules
use Cleartext-Password attribute from control list to check credentials
against.

To authorize subscriber you should make a decision based on both
subscriber profile and authentication result. This is what post-auth
section does. Put your authorization policies in this section.

Post by Edgar Fuß
Given that Authentication is proving who I am and Authorization is checking what I'm allowed to do, I naively would have expected a RADIUS server to first authenticate me an then check my authorization.
Surely for a reason, what FreeRADIUS does is the other way round: first try all authorization modules and then use one authentication module.
I hope I got this right.
I would like to be pointed to a document explaining the rationale behind this. It's probably obvious to anyone familiar with the matter, but that doesn't include me.
Thanks.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

[Edgar Fuß]

Post by Iliya Peregoudov
- 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).

Post by Iliya Peregoudov
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?
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

[Fajar A. Nugraha]

Post by Edgar Fuß

Post by Iliya Peregoudov
- 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).

Post by Iliya Peregoudov
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.

[Edgar Fuß]

I was probably too fuzzy about what I actually mean, sorry.

Suppose I'm writing my own module or I'm using rlm_perl.
Then, in authenticate, I gather some information.
Later, in post-auth, I need this information for my authorization policy.
So, as far as I can see, I'll have to put this Information into an attribute.
Am I supposed to use the Tmp-Xxx-N attributes for that?

I think my situation is analogous to rlm_eap storing the issuer certificate in the TLS-Client-Cert-Issuer attribute so you can base policy decisions on that.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

[Alan DeKok]

Post by Edgar Fuß
Suppose I'm writing my own module or I'm using rlm_perl.
Then, in authenticate, I gather some information.
Later, in post-auth, I need this information for my authorization policy.
So, as far as I can see, I'll have to put this Information into an attribute.

Yes.

Post by Edgar Fuß
Am I supposed to use the Tmp-Xxx-N attributes for that?

Define your own. That's why the dictionary files are editable.

Alan DeKok.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

[Edgar Fuß]

EF> Am I supposed to use the Tmp-Xxx-N attributes for that?
ADK> Define your own. That's why the dictionary files are editable.
Ah, you mean raddb/dictionary, I suppose. Thanks, I over-looked that.

Just out of curiosity: What are the pre-defined Tmp-Xxx-N attributes for, then?
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

[Edgar Fuß]

Define your own [attributes]. That's why the dictionary files are editable.

Is there a private name space for that (i.e., X-*) that is guaranteed not to conflict with future official attribute names?
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

[Alan DeKok]

Post by Edgar Fuß

Define your own [attributes]. That's why the dictionary files are editable.

Is there a private name space for that (i.e., X-*) that is guaranteed not to conflict with future official attribute names?

raddb/dictionary

Alan DeKok.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

[Edgar Fuß]

Post by Edgar Fuß
raddb/dictionary

I already deduced from there that I'm supposed to use attribute numbers [3000...4000[, but I'm not sure about the attribute names.
The suggestion seems to be to use a name unused at the present time hoping that it will stay unused in the future.
Or what am I missing?
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

[Alan Buxey]

Hi,

Post by Edgar Fuß

Post by Edgar Fuß
raddb/dictionary

I already deduced from there that I'm supposed to use attribute numbers [3000...4000[, but I'm not sure about the attribute names.
The suggestion seems to be to use a name unused at the present time hoping that it will stay unused in the future.
Or what am I missing?

names? for humans. computers and RADIUS care about attribute numbers
more than anything else in their lives ;-)
obviously, if you want to USE the name for some reference then it should
be unique for your own sanity 8-)

alan
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

[Edgar Fuß]

Post by Edgar Fuß
names?

Yes.

Post by Edgar Fuß
computers and RADIUS care about attribute numbers
more than anything else in their lives

Both in rlm_perl and in unlang I'm supposed to use names, not numbers.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

[Alan DeKok]

Post by Edgar Fuß

Post by Edgar Fuß
raddb/dictionary

I already deduced from there that I'm supposed to use attribute numbers [3000...4000[, but I'm not sure about the attribute names.

Pick a name.

Post by Edgar Fuß
The suggestion seems to be to use a name unused at the present time hoping that it will stay unused in the future.
Or what am I missing?

There is no registry of names. Make sure that the name you choose is
unique. This is usually done by using a unique prefix. e.g.
FreeRADIUS-*, of Cisco-*.

Alan DeKok.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

[Fajar A. Nugraha]

Post by Edgar Fuß

Define your own [attributes].  That's why the dictionary files are editable.

Is there a private name space for that (i.e., X-*) that is guaranteed not to conflict with future official attribute names?

You should be able to define any unused attribute name (e.g.
MyModule-Attr-1), as long as the attribute number does not conflict
with an existing one.
#
# Range: 2200-2999
# Free
#
# Range: 3000-3999
# Site-local attributes (see raddb/dictionary.in)
# Do NOT define attributes in this range!
#
# Range: 4000-65535
# Unused
#
# Range: 65536-
# Invalid. Don't use.
#

[Edgar Fuß]

Seems that I'm slowly getting it.

Post by Iliya Peregoudov
To authorize subscriber you should make a decision based on both
subscriber profile and authentication result. This is what post-auth
section does. Put your authorization policies in this section.

So do I understand this correctly: if I, for example, want to put a client into a VLAN according to the EAP-TLS certificate issuer, the recommended way to to that is to use unlang to check %Client-Cert-Issuer in the post-auth section and use the "update reply" command to set the Tunnel-Private-Group-Id reply attribute?
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

[Phil Mayers]

Post by Edgar Fuß
Seems that I'm slowly getting it.

Post by Iliya Peregoudov
To authorize subscriber you should make a decision based on both
subscriber profile and authentication result. This is what
post-auth section does. Put your authorization policies in this
section.

So do I understand this correctly: if I, for example, want to put a
client into a VLAN according to the EAP-TLS certificate issuer, the
recommended way to to that is to use unlang to check
%Client-Cert-Issuer in the post-auth section and use the "update
reply" command to set the Tunnel-Private-Group-Id reply attribute? -

Yes, exactly so.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

[Alan Buxey]

What are you going to send from authenticate? It should be simple, password correct or password wrong. Everything else should be in post auth, authorize or post proxy even

alan