Hi Everyone i have a question regarding freeradius. I am trying to write a plugin and i was wondering what the postauth section is for. I want to be able to alter the authentication decision of freeradius, once it is made but before the ok response is sent. I will use a policy engine to do that and i want to overwrite the final decision if the user is not authorized based on my policy. Is postauth the right place to do this? regards George
George Beitis wrote:
... I will use a policy engine to do that and i want to overwrite the final decision if the user is not authorized based on my policy.
Is postauth the right place to do this?
Yes. But you can't turn a reject into an accept. You can only turn an accept into a reject. Alan DeKok.
That sounds just like what i want to do. Thanks for the reply! Has anyone tried anything similar in the past? I 'm trying to use jradius to code the plugin in java. I feel a bit lost and wondered if anyone could give me a few guidelines thanks George Alan DeKok wrote:
George Beitis wrote:
... I will use a policy engine to do that and i want to overwrite the final decision if the user is not authorized based on my policy.
Is postauth the right place to do this?
Yes.
But you can't turn a reject into an accept. You can only turn an accept into a reject.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
George Beitis wrote:
That sounds just like what i want to do. Thanks for the reply! Has anyone tried anything similar in the past?
? FreeRADIUS is used in 100k sites totalling over 100M users. Yes, people have tried it in th epast.
I 'm trying to use jradius to code the plugin in java. I feel a bit lost and wondered if anyone could give me a few guidelines
In 2.x, you can code it in the configuration language. Much easier for most things. Alan DeKok.
Alan I 'm afraid Java is a requirement of my project, long story why. this is why i went with freeradius and jradius George Alan DeKok wrote:
George Beitis wrote:
That sounds just like what i want to do. Thanks for the reply! Has anyone tried anything similar in the past?
? FreeRADIUS is used in 100k sites totalling over 100M users.
Yes, people have tried it in th epast.
I 'm trying to use jradius to code the plugin in java. I feel a bit lost and wondered if anyone could give me a few guidelines
In 2.x, you can code it in the configuration language. Much easier for most things.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Hi Alan! On 7/5/07, Alan DeKok <aland@deployingradius.com> wrote:
George Beitis wrote:
... I will use a policy engine to do that and i want to overwrite the final decision if the user is not authorized based on my policy.
Is postauth the right place to do this?
Yes.
But you can't turn a reject into an accept. You can only turn an accept into a reject.
Isn't "authorize" better place for that? Even name suggests authorization should be done there... ;) Just wondering whether there's a good reason for not doing it in authorize and postpone it until post-auth. Besides using more common order of authentication and authorization steps. th.
Tomas you actually made a very good point :) I didn't realize there was an authorize part in the work flow of freeradius. That would be before postauth, are there any other steps after "authorize" and before post auth? kind regards George Tomas Hoger wrote:
Hi Alan!
On 7/5/07, Alan DeKok <aland@deployingradius.com> wrote:
George Beitis wrote:
... I will use a policy engine to do that and i want to overwrite the final decision if the user is not authorized based on my policy.
Is postauth the right place to do this?
Yes.
But you can't turn a reject into an accept. You can only turn an accept into a reject.
Isn't "authorize" better place for that? Even name suggests authorization should be done there... ;)
Just wondering whether there's a good reason for not doing it in authorize and postpone it until post-auth. Besides using more common order of authentication and authorization steps.
th. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On 7/6/07, George Beitis <gb85@kent.ac.uk> wrote:
you actually made a very good point :) I didn't realize there was an authorize part in the work flow of freeradius. That would be before postauth, are there any other steps after "authorize" and before post auth?
For (non-proxied) authentication requests, steps should be: authorize authenticate post-auth See relevant sections of radiusd.conf or radiusd debug output. th.
for proxied ones would the last 2 remain the same? regards George Tomas Hoger wrote:
On 7/6/07, George Beitis <gb85@kent.ac.uk> wrote:
you actually made a very good point :) I didn't realize there was an authorize part in the work flow of freeradius. That would be before postauth, are there any other steps after "authorize" and before post auth?
For (non-proxied) authentication requests, steps should be:
authorize authenticate post-auth
See relevant sections of radiusd.conf or radiusd debug output.
th. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Tomas Hoger wrote:
Isn't "authorize" better place for that? Even name suggests authorization should be done there... ;)
No. "authorize" is run before authentication for historical reasons. Policies should really be applied *after* a user authenticates, which means post-auth.
Just wondering whether there's a good reason for not doing it in authorize and postpone it until post-auth. Besides using more common order of authentication and authorization steps.
The common order is authentication, then authorization. FreeRADIUS mixes up the names for historical reasons. Alan DeKok.
The common order is authentication, then authorization. FreeRADIUS mixes up the names for historical reasons.
It's a long shot, but: wouldn't it make sense to clear the wording for 2.0? I know, it would break all existing configs out there, but manually working through the config is needed anyways... I know that this wording startled me quite a bit when I was new here... Stefan -- Stefan WINTER Stiftung RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche Ingenieur Forschung & Entwicklung 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg E-Mail: stefan.winter@restena.lu Tel.: +352 424409-1 http://www.restena.lu Fax: +352 422473
Stefan Winter wrote:
It's a long shot, but: wouldn't it make sense to clear the wording for 2.0? I know, it would break all existing configs out there, but manually working through the config is needed anyways... I know that this wording startled me quite a bit when I was new here...
It's worth doing. The problem is we can't call the post-authentication step "authorize", because that will confuse everyone upgrading from 1.x. I think the default configuration should be "pre-auth", "auth", and "post-auth". We can still accept "authorize" as a synonym for "pre-auth" in the short term. Alan DeKok.
On Fri, 2007-07-06 at 11:49 +0200, Alan DeKok wrote:
Stefan Winter wrote:
It's a long shot, but: wouldn't it make sense to clear the wording for 2.0? I know, it would break all existing configs out there, but manually working through the config is needed anyways... I know that this wording startled me quite a bit when I was new here...
It's worth doing.
The problem is we can't call the post-authentication step "authorize", because that will confuse everyone upgrading from 1.x.
I think the default configuration should be "pre-auth", "auth", and "post-auth". We can still accept "authorize" as a synonym for "pre-auth" in the short term.
+1 - excellent idea
Phil Mayers wrote:
On Fri, 2007-07-06 at 11:49 +0200, Alan DeKok wrote:
Stefan Winter wrote:
It's a long shot, but: wouldn't it make sense to clear the wording for 2.0? I know, it would break all existing configs out there, but manually working through the config is needed anyways... I know that this wording startled me quite a bit when I was new here...
It's worth doing.
The problem is we can't call the post-authentication step "authorize", because that will confuse everyone upgrading from 1.x.
I think the default configuration should be "pre-auth", "auth", and "post-auth". We can still accept "authorize" as a synonym for "pre-auth" in the short term.
+1 - excellent idea
+1 - Makes more sense... So proxying logic is done in pre-auth , authentication in auth , and reply formulation in post-auth... Yeah far better :) No more reply formulation for users who are going to be rejected .... + Remove post auth query from SQL module ... functionality can be replicated in unlang with minimum of fuss. so authorisation method of rlm_sql gets mapped to post-auth as well as pre-auth. Though I feel sorry for migrating users... Though this now follows the standard aaa logic, Authenticate Authorise Account, so might be less confusing for new users. --- Arran
On Sat 07 Jul 2007, Arran Cudbard-Bell wrote:
Phil Mayers wrote:
On Fri, 2007-07-06 at 11:49 +0200, Alan DeKok wrote:
Stefan Winter wrote:
It's a long shot, but: wouldn't it make sense to clear the wording for 2.0? I know, it would break all existing configs out there, but manually working through the config is needed anyways... I know that this wording startled me quite a bit when I was new here...
It's worth doing.
The problem is we can't call the post-authentication step "authorize", because that will confuse everyone upgrading from 1.x.
I think the default configuration should be "pre-auth", "auth", and "post-auth". We can still accept "authorize" as a synonym for "pre-auth" in the short term.
+1 - excellent idea
+1 - Makes more sense...
So proxying logic is done in pre-auth , authentication in auth , and reply formulation in post-auth...
Yeah far better :) No more reply formulation for users who are going to be rejected ....
+ Remove post auth query from SQL module ... functionality can be replicated in unlang with minimum of fuss.
Why do this? The ability to log things to sql post-auth is very usefull and I believe fairly widely used. What is the advantage of removing it? -- Peter Nixon http://www.peternixon.net/ PGP Key: http://www.peternixon.net/public.asc
Peter Nixon wrote:
On Sat 07 Jul 2007, Arran Cudbard-Bell wrote:
Phil Mayers wrote:
On Fri, 2007-07-06 at 11:49 +0200, Alan DeKok wrote:
Stefan Winter wrote:
It's a long shot, but: wouldn't it make sense to clear the wording for 2.0? I know, it would break all existing configs out there, but manually working through the config is needed anyways... I know that this wording startled me quite a bit when I was new here...
It's worth doing.
The problem is we can't call the post-authentication step "authorize", because that will confuse everyone upgrading from 1.x.
I think the default configuration should be "pre-auth", "auth", and "post-auth". We can still accept "authorize" as a synonym for "pre-auth" in the short term.
+1 - excellent idea
+1 - Makes more sense...
So proxying logic is done in pre-auth , authentication in auth , and reply formulation in post-auth...
Yeah far better :) No more reply formulation for users who are going to be rejected ....
+ Remove post auth query from SQL module ... functionality can be replicated in unlang with minimum of fuss.
Why do this? The ability to log things to sql post-auth is very usefull and I believe fairly widely used. What is the advantage of removing it?
Right, so you wanting to authorize people in post-auth using .... then theres a conflict. You can't select whether you want to use the logging function of rlm_sql or the authorisation function.
Why do this? The ability to log things to sql post-auth is very usefull and I believe fairly widely used. What is the advantage of removing it?
Right, so you wanting to authorize people in post-auth using .... then theres a conflict. You can't select whether you want to use the logging function of rlm_sql or the authorisation function.
Of course you can: post-auth { sql # does the logging if (%{control:Foo-Bar}=="baz") { update reply { # does the "authorization" Baz-Attr = %{sql:select bazattr from ...} } } } In *fact* since sql_xlat function only support SELECT, there's no way of executing an SQL modify (insert, update, delete) using %{sql:} syntax - so you *have* to retain the sql post-auth logging function. The unlang is nice, but lets not all lose sight of the proven, working and tested mechanisms in the server. And while we're on the subject - lets not get caught up in some comp. sci. disagreement of what is authz versus authn. I agree that the 1.1.x terminology is very slightly confusing, and a slightly less ambiguous rename is good, but breaking working functionality at the same time is just plain wrong.
Phil Mayers wrote:
In *fact* since sql_xlat function only support SELECT, there's no way of executing an SQL modify (insert, update, delete) using %{sql:} syntax - so you *have* to retain the sql post-auth logging function.
int sql_xlat(...) { if (strncasecmp(string, "SELECT", 6) == 0) { do select... } else if (strncasecmp(string, "UPDATE", 6) == 0) { do update... } } That would work, wouldn't it?
The unlang is nice, but lets not all lose sight of the proven, working and tested mechanisms in the server.
The modules are there to solve common problems with simple solutions. I'd prefer to keep modules than to ship the server with 3k lines of unlang policy.
And while we're on the subject - lets not get caught up in some comp. sci. disagreement of what is authz versus authn. I agree that the 1.1.x terminology is very slightly confusing, and a slightly less ambiguous rename is good, but breaking working functionality at the same time is just plain wrong.
Almost all of the changes in 2.0 have some kind of backwards compatibility with 1.x. That will continue. Alan DeKok.
On Sun, 2007-07-08 at 09:54 +0200, Alan DeKok wrote:
Phil Mayers wrote:
In *fact* since sql_xlat function only support SELECT, there's no way of executing an SQL modify (insert, update, delete) using %{sql:} syntax - so you *have* to retain the sql post-auth logging function.
int sql_xlat(...) { if (strncasecmp(string, "SELECT", 6) == 0) { do select... } else if (strncasecmp(string, "UPDATE", 6) == 0) { do update... } }
That would work, wouldn't it?
Sure. Presumably you'd have to use some kind of dummy assign: update control { Tmp-String-0 = %{sql:insert into ...} } ...not exactly intuitive. Don't know if you'd want to allow a bare expansion though. Some kind of generalised "call" construct? if (!%{sql:update thing set ...}) { %{sql:insert into thing ...} }
The unlang is nice, but lets not all lose sight of the proven, working and tested mechanisms in the server.
The modules are there to solve common problems with simple solutions. I'd prefer to keep modules than to ship the server with 3k lines of unlang policy.
We are in vigorous agreement.
And while we're on the subject - lets not get caught up in some comp. sci. disagreement of what is authz versus authn. I agree that the 1.1.x terminology is very slightly confusing, and a slightly less ambiguous rename is good, but breaking working functionality at the same time is just plain wrong.
Almost all of the changes in 2.0 have some kind of backwards compatibility with 1.x. That will continue.
Good to hear (and I did not expect otherwise). I was just agreeing with (I think) the comment from Peter that removing the post-auth method from the "sql" module seemed pointless.
Phil Mayers wrote: ...
That would work, wouldn't it?
Sure. Presumably you'd have to use some kind of dummy assign:
update control { Tmp-String-0 = %{sql:insert into ...}
No, "if (!x)" is the way to do.
...not exactly intuitive. Don't know if you'd want to allow a bare expansion though. Some kind of generalised "call" construct?
if (!%{sql:update thing set ...}) {
if (!"{%sql: update ...}") { # code to handle policy when update fails } Alan DeKok.
Phil Mayers wrote:
Why do this? The ability to log things to sql post-auth is very usefull and I believe fairly widely used. What is the advantage of removing it?
Right, so you wanting to authorize people in post-auth using .... then theres a conflict. You can't select whether you want to use the logging function of rlm_sql or the authorisation function.
Of course you can:
post-auth { sql # does the logging
if (%{control:Foo-Bar}=="baz") { update reply { # does the "authorization" Baz-Attr = %{sql:select bazattr from ...} } } }
That doesn't replicate the authorisation capabilities of the SQL module at all ?! SQL XLAT only allows you to write one column and one row to one attribute, it would take hundreds of queries and a few pages of logic to replicate SQL authorisation in unlang..
In *fact* since sql_xlat function only support SELECT, there's no way of executing an SQL modify (insert, update, delete) using %{sql:} syntax - so you *have* to retain the sql post-auth logging function.
Ah didn't know that. But I see Alan has some suggestions... Replacing the current post-auth query with unlang is by far the lesser of two evils, in that it would take oh... all of three lines, and could be written easily into the 2.0 default config. Theres also the fact that most people using the post-auth query have modified it in some way, and putting it in an easy to find and edit place can only be a good thing.
The unlang is nice, but lets not all lose sight of the proven, working and tested mechanisms in the server.
And while we're on the subject - lets not get caught up in some comp. sci. disagreement of what is authz versus authn. I agree that the 1.1.x terminology is very slightly confusing, and a slightly less ambiguous rename is good, but breaking working functionality at the same time is just plain wrong.
Ok I was just pointing out a huge great big glaring issue with moving all authorisation stuff to post-auth... We would need a post-post-auth section , or a post-auth-logging section ... Or even the ability to pass arguments to modules...
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Sun, 2007-07-08 at 10:09 +0100, Arran Cudbard-Bell wrote:
Phil Mayers wrote:
Why do this? The ability to log things to sql post-auth is very usefull and I believe fairly widely used. What is the advantage of removing it?
Right, so you wanting to authorize people in post-auth using .... then theres a conflict. You can't select whether you want to use the logging function of rlm_sql or the authorisation function.
Of course you can:
post-auth { sql # does the logging
if (%{control:Foo-Bar}=="baz") { update reply { # does the "authorization" Baz-Attr = %{sql:select bazattr from ...} } } }
That doesn't replicate the authorisation capabilities of the SQL module at all ?!
Ok, now I get you. You are wanting to use the post-auth section to run the radcheck and radreply queries only once, and only on Access-Accept. Obviously if the sql module runs them in the "pre-auth" section (nee "authorize"), you can't do that. If it runs them in the "post-auth", it'll conflict (or need to be merged) with the logging function. I can see where you're coming from, but bear this in mind: though you don't store password hashes in SQL (nor do we) many people do, and *those* queries will *have* to run in pre-auth. It's not reasonable to expect that all those users change from: authorize { sql } to use unlang: pre-auth { update control { Cleartext-Password = %{sql:select ...} } } How about the sql module acquire a config item: sql { run_queries_in = [pre-auth | post-auth] }
SQL XLAT only allows you to write one column and one row to one attribute, it would take hundreds of queries and a few pages of logic to replicate SQL authorisation in unlang..
Indeed.
Post auth seems like the best place to place authorization decisions, given that post auth stands for post authentication. It should take place after proxying is done and should allow the option for setting 2 different possibilities, one for non proxied cases and one for proxied. Then again this might not be necessary as these 2 cases can be dealt by the authorization engine given that the right information is passed to it. logging should be possible right before authorization and after. This is how i see things configured, what do u think? Arran Cudbard-Bell wrote:
Peter Nixon wrote:
On Sat 07 Jul 2007, Arran Cudbard-Bell wrote:
Phil Mayers wrote:
On Fri, 2007-07-06 at 11:49 +0200, Alan DeKok wrote:
Stefan Winter wrote:
It's a long shot, but: wouldn't it make sense to clear the wording for 2.0? I know, it would break all existing configs out there, but manually working through the config is needed anyways... I know that this wording startled me quite a bit when I was new here...
It's worth doing.
The problem is we can't call the post-authentication step "authorize", because that will confuse everyone upgrading from 1.x.
I think the default configuration should be "pre-auth", "auth", and "post-auth". We can still accept "authorize" as a synonym for "pre-auth" in the short term.
+1 - excellent idea
+1 - Makes more sense...
So proxying logic is done in pre-auth , authentication in auth , and reply formulation in post-auth...
Yeah far better :) No more reply formulation for users who are going to be rejected ....
+ Remove post auth query from SQL module ... functionality can be replicated in unlang with minimum of fuss.
Why do this? The ability to log things to sql post-auth is very usefull and I believe fairly widely used. What is the advantage of removing it?
Right, so you wanting to authorize people in post-auth using .... then theres a conflict. You can't select whether you want to use the logging function of rlm_sql or the authorisation function. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
I think its worth making sure that the wordings used correspond to the proper meaning of the words. For someone coming from from a background where authentication means making sure the person says who they say the are, and authorization making sure that that person is authorized to do what they want to do, seeing authorization used in a different makes them confused. I think it is worth seeing this problem and correcting the vocabulary used. People who are using freeradius and have a proper background should find the adjustment easy i think. regards George Alan DeKok wrote:
Stefan Winter wrote:
It's a long shot, but: wouldn't it make sense to clear the wording for 2.0? I know, it would break all existing configs out there, but manually working through the config is needed anyways... I know that this wording startled me quite a bit when I was new here...
It's worth doing.
The problem is we can't call the post-authentication step "authorize", because that will confuse everyone upgrading from 1.x.
I think the default configuration should be "pre-auth", "auth", and "post-auth". We can still accept "authorize" as a synonym for "pre-auth" in the short term.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Fri 06 Jul 2007, Alan DeKok wrote:
Stefan Winter wrote:
It's a long shot, but: wouldn't it make sense to clear the wording for 2.0? I know, it would break all existing configs out there, but manually working through the config is needed anyways... I know that this wording startled me quite a bit when I was new here...
It's worth doing.
The problem is we can't call the post-authentication step "authorize", because that will confuse everyone upgrading from 1.x.
I think the default configuration should be "pre-auth", "auth", and "post-auth". We can still accept "authorize" as a synonym for "pre-auth" in the short term.
Sounds good to me also. We have definitely made enough changes in 2.0 that one more small change like this will not add significantly more confusion and definitely seems worth it in the long run. -- Peter Nixon http://www.peternixon.net/ PGP Key: http://www.peternixon.net/public.asc
Alan DeKok wrote:
Tomas Hoger wrote:
Isn't "authorize" better place for that? Even name suggests authorization should be done there... ;)
No. "authorize" is run before authentication for historical reasons.
Policies should really be applied *after* a user authenticates, which means post-auth.
But thats not how modules are currently configured to work. So policies have to be applied in *authorize* if SQL or LDAP is used for authorisation. "Authorisation" has to be done before authentication when proxying, as the server will only proxy at the of the authorise section .... Btw Server appears to be leaking scary amounts of memory, i'm going to try and track it down to something in the config... After 50,000 pap authentications (running in parallel sets of 15) it had leaked about 20mb , and was still increasing .... I set the threads to die after 100 authentications, but didn't seem to make any difference. Will try with standard config/32bit build and get back to you. Haven't found any new bugs recently ... well only ones created by my own stupidity ;) Be interested to see how return codes are when they work properly . Keep up the good work :) -- Arran Cudbard-Bell (A.Cudbard-Bell@sussex.ac.uk) Authentication, Authorisation and Accounting Officer Infrastructure Services | ENG1 E1-1-08 University Of Sussex, Brighton EXT:01273 873900 | INT: 3900
Arran Cudbard-Bell wrote:
Btw Server appears to be leaking scary amounts of memory, i'm going to try and track it down to something in the config...
That's not good.
After 50,000 pap authentications (running in parallel sets of 15) it had leaked about 20mb , and was still increasing .... I set the threads to die after 100 authentications, but didn't seem to make any difference.
Will try with standard config/32bit build and get back to you.
Valgrind on a 32-bit Intel system? Alan DeKok.
Hi Alan! On 7/6/07, Alan DeKok <aland@deployingradius.com> wrote:
Isn't "authorize" better place for that? Even name suggests authorization should be done there... ;)
No. "authorize" is run before authentication for historical reasons.
Yes I do understand authorize is run before authenticate and I do understand why modules are called in authorize even if they don't do anything related to authorization. And as Arran pointed out, there are situations when applying policies in feasible and is done in practice.
Policies should really be applied *after* a user authenticates, which means post-auth.
Yes, authenticate, authorize is the order most commonly used. But I think it may still be acceptable to apply policies before authenticating user, e.g. if authentication if more "expensive" (either in terms of time or CPU usage). Few examples: - authentication is done by remote radius - no need to proxy request if we know / can tell in advance that request will be rejected anyway - application of policy take less time then lookup of user in external DB (SQL, LDAP) - however, proper ordering of modules in authorize must be taken into account Thanks for your feedback! th.
Tomas Hoger wrote:
Yes, authenticate, authorize is the order most commonly used. But I think it may still be acceptable to apply policies before authenticating user, e.g. if authentication if more "expensive" (either in terms of time or CPU usage). Few examples:
Yes. I've had that discussion before (off-list) with people who are surprised that FreeRADIUS permits policies to be run before users are authenticated. e.g. Users on NAS X aren't supposed to do EAP. So if they try, reject them immediately. This also mitigates certain kinds of DoS attacks. Alan DeKok.
participants (8)
-
Alan DeKok -
Arran Cudbard-Bell -
George Beitis -
George Beitis -
Peter Nixon -
Phil Mayers -
Stefan Winter -
Tomas Hoger