Why Authorization before Authentication?
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.
On 23 Nov 2011, at 13:34, Edgar Fuß wrote:
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.
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 a.cudbardb@freeradius.org Betelwiki, Betelwiki, Betelwiki.... http://wiki.freeradius.org/ !
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.
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.
On Wed, Nov 23, 2011 at 11:21 PM, Edgar Fuß <ef@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
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. Edgar Fuß wrote:
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
- 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?
On Thu, Nov 24, 2011 at 11:49 PM, Edgar Fuß <ef@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
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.
Edgar Fuß wrote:
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.
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.
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?
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?
Edgar Fuß wrote:
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.
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?
Hi,
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
Edgar Fuß wrote:
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.
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.
On Sun, Nov 27, 2011 at 7:47 PM, Edgar Fuß <ef@math.uni-bonn.de> wrote:
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.
From dictionary.freeradius.internal:
# # 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. # -- Fajar
Seems that I'm slowly getting it.
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?
On 25/11/11 13:59, Edgar Fuß wrote:
Seems that I'm slowly getting it.
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.
participants (7)
-
Alan Buxey -
Alan DeKok -
Arran Cudbard-Bell -
Edgar Fuß -
Fajar A. Nugraha -
Iliya Peregoudov -
Phil Mayers