Deleting reply items before post-proxy
Could someone please explain to me if there is any specific reasoning behind the following lines right in the beginning of proxy_receive() in proxy.c? (version 1.1.7, similar code in event.c in 2.0) /* * Delete any reply we had accumulated until now. */ pairfree(&request->reply->vps); I was trying to get rid of my 'post-proxy-authorize' dependency and found that any attributes added during the authorize stage are removed when the proxy reply is received. Surely this is not intended behaviour as further down in proxy_receive() we have the following lines: /* * Add the attributes left in the proxy reply to * the reply list. */ pairadd(&request->reply->vps, request->proxy_reply->vps); Removing the initial pairfree() gives me the behaviour I expected, i.e. add some stuff during authorize, proxy, then combine reply and proxy_reply items before responding. Am I missing something? Eddie
Eddie Stassen wrote:
I was trying to get rid of my 'post-proxy-authorize' dependency and found that any attributes added during the authorize stage are removed when the proxy reply is received. Surely this is not intended behaviour
Yes. The problem is that the "authorize" stage is usually done wrong, for reasons that go back to the original implementation. The authorize section often updates the *reply*, which is just plain backwards. Instead, the authorize section should set the stage for the authentication stage, i.e. known passwords, group checking, etc. Once the user is authenticated, the post-authenticate section should set the reply.
Removing the initial pairfree() gives me the behaviour I expected, i.e. add some stuff during authorize, proxy, then combine reply and proxy_reply items before responding. Am I missing something?
I think your policy can be re-written to add most reply items in the post-authentication stage. Alan DeKok.
Alan DeKok wrote:
Eddie Stassen wrote:
I was trying to get rid of my 'post-proxy-authorize' dependency and found that any attributes added during the authorize stage are removed when the proxy reply is received. Surely this is not intended behaviour
Yes. The problem is that the "authorize" stage is usually done wrong, for reasons that go back to the original implementation.
The authorize section often updates the *reply*, which is just plain backwards. Instead, the authorize section should set the stage for the authentication stage, i.e. known passwords, group checking, etc. Once the user is authenticated, the post-authenticate section should set the reply.
But currently it doesn't... as discussed before on the list, the post-auth methods in most of the modules lean towards logging and not reply attribute generation. You cannot currently generate reply attributes from SQL easily in the post-authenticate section. I can see being able to pass reply attributes through from the authorise section as a very useful thing; Being able to store rules in an SQL database and grouping reply attributes by realm, then applying them in the authorise section. Instead of relying on the weird legacy behaviour of passing the proxied request through the authorise section twice ... Even if it's not default behaviour, count it be introduced as configurable behaviour?
Removing the initial pairfree() gives me the behaviour I expected, i.e. add some stuff during authorize, proxy, then combine reply and proxy_reply items before responding. Am I missing something?
I think your policy can be re-written to add most reply items in the post-authentication stage.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
-- 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:
But currently it doesn't... as discussed before on the list, the post-auth methods in most of the modules lean towards logging and not reply attribute generation. You cannot currently generate reply attributes from SQL easily in the post-authenticate section.
Yes. That should probably be fixed before a final 2.0.
Even if it's not default behaviour, count it be introduced as configurable behaviour?
Likely, yes. As the server grows in capability (i.e. VMPS), the old way of modules of fixed methods with fixed functionality is looking awkward. We need a more generic way of mapping module functionality to processing stage. But I'm not yet sure what that is. Alan DeKok.
Alan DeKok wrote:
I think your policy can be re-written to add most reply items in the post-authentication stage.
Ideally this is where I would like to do it, but since I use rlm_sql to add the attributes, I am left with three less than perfect options: a. Stay with post proxy authorize b. Run a slightly hacked server c. Hack rlm_sql to add replicate the authorize behaviour in post-auth (perhaps this would be the proper solution?) Eddie
Eddie Stassen wrote:
c. Hack rlm_sql to add replicate the authorize behaviour in post-auth (perhaps this would be the proper solution?)
Yes. If you're not using the existing SQL post-auth functionality, a one-line change to map post-auth to authorize would be easy to do. Alan DeKok.
Alan DeKok said:
Eddie Stassen wrote:
I was trying to get rid of my 'post-proxy-authorize' dependency and found that any attributes added during the authorize stage are removed when the proxy reply is received. Surely this is not intended behaviour
Yes. The problem is that the "authorize" stage is usually done wrong, for reasons that go back to the original implementation.
The authorize section often updates the *reply*, which is just plain backwards. Instead, the authorize section should set the stage for the authentication stage, i.e. known passwords, group checking, etc. Once the user is authenticated, the post-authenticate section should set the reply.
Which is great in theory, but as Arran pointed out, not so easy in practice, especially if you are trying to do everything from SQL. I second the request for a "yes_I_(think)_I_know_what_I_am_doing" switch we can use to turn that behavior off, until such time as rlm_sql allows us to do things "the right way" without jumping through too many hoops?
Alan DeKok.
-- hugh
Hugh Messenger wrote:
I second the request for a "yes_I_(think)_I_know_what_I_am_doing" switch we can use to turn that behavior off, until such time as rlm_sql allows us to do things "the right way" without jumping through too many hoops?
The post-proxy-authorize flag is gone. The code is gone. It's time to do it correctly. Argh. I think the real solution is to turn "unlang" into even more of a language, much as I hate that idea... Alan DeKok.
Alan DeKok said:
The post-proxy-authorize flag is gone. The code is gone. It's time to do it correctly.
Okie Dokie.
Argh. I think the real solution is to turn "unlang" into even more of a language,
Ah, so it becomes "notunlang". Which of course optimizes to 'lang'.
much as I hate that idea...
Doing things correctly always seems to carry a cost. :)
Alan DeKok.
-- hugh
Alan DeKok wrote:
Argh. I think the real solution is to turn "unlang" into even more of a language, much as I hate that idea...
How about using an existing embeddable language then (lua comes to mind, but actually, I have no experience using it)? IIRC, this has been on the list some time ago ... Enrik
How about using an existing embeddable language then (lua comes to mind, but actually, I have no experience using it)?
I've looked into lua. It's simple, small, and it's syntax is atrocious. It's easy to plug a language in as a module. The Perl and Python modules show that. But to make a language control the internal behavior of the server requires that the server be *written* in the language. Alan DeKok.
Hi,
It's easy to plug a language in as a module. The Perl and Python modules show that. But to make a language control the internal behavior of the server requires that the server be *written* in the language.
ah...a port to PERL eh? <ducks!> ;-) REBOL or Rexx spring to mind too :-) alan
Alan DeKok wrote:
Eddie Stassen wrote:
I was trying to get rid of my 'post-proxy-authorize' dependency and found that any attributes added during the authorize stage are removed when the proxy reply is received. Surely this is not intended behaviour
Yes. The problem is that the "authorize" stage is usually done wrong, for reasons that go back to the original implementation.
The authorize section often updates the *reply*, which is just plain backwards. Instead, the authorize section should set the stage for the authentication stage, i.e. known passwords, group checking, etc. Once the user is authenticated, the post-authenticate section should set the reply.
So how do I properly ensure that entries I have attached to DEFAULTS for proxied realms in my users file actually get sent? Currently I have the offending code patched out.
Joe Maimon wrote:
So how do I properly ensure that entries I have attached to DEFAULTS for proxied realms in my users file actually get sent? Currently I have the offending code patched out.
What offending code? I recently had another thought about 2.x: assign virtual servers to realms, too. Those virtual servers would contain only pre-proxy and post-proxy sections. Doing that will mean that each realm will have its own policies, independent of anything else. It won't solve the "post-proxy-authorize" issue, but it will solve other problems. Alan DeKok.
Alan DeKok wrote:
Joe Maimon wrote:
So how do I properly ensure that entries I have attached to DEFAULTS for proxied realms in my users file actually get sent? Currently I have the offending code patched out.
What offending code?
I recently had another thought about 2.x: assign virtual servers to realms, too. Those virtual servers would contain only pre-proxy and post-proxy sections.
Doing that will mean that each realm will have its own policies, independent of anything else.
It won't solve the "post-proxy-authorize" issue, but it will solve other problems.
Well it'll certainly make the solution to other problems neater. I have to confess I had assumed the proxy behaviour was to allow reply attributes set in the authorise section to be sent on successful authentication by the home server, and structured my configuration to take advantage of this (as it seemed the logical way for things to work). So I will have to take out that line, which makes testing really annoying. So repeat plea for configuration option to allow the original reply to be combined with the *heavily filtered* reply from server.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
-- 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:
I have to confess I had assumed the proxy behaviour was to allow reply attributes set in the authorise section to be sent on successful authentication by the home server, and structured my configuration to take advantage of this (as it seemed the logical way for things to work).
That can be done... but it's still a little wrong.
So repeat plea for configuration option to allow the original reply to be combined with the *heavily filtered* reply from server.
That can be done. But the post-proxy-authorize configuration will NOT be re-added. It's indescribably wrong, and breaks things. Alan DeKok.
Alan DeKok wrote:
Arran Cudbard-Bell wrote:
I have to confess I had assumed the proxy behaviour was to allow reply attributes set in the authorise section to be sent on successful authentication by the home server, and structured my configuration to take advantage of this (as it seemed the logical way for things to work).
That can be done... but it's still a little wrong.
Marginally wrong, but then as discussed previously, the order of things in general is currently a little wrong.
So repeat plea for configuration option to allow the original reply to be combined with the *heavily filtered* reply from server.
That can be done. But the post-proxy-authorize configuration will NOT be re-added. It's indescribably wrong, and breaks things.
Are you referring to the option that sends the request back through the main authorize section after proxying? If yes, then I agree. It's also very inefficient .
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
Thanks, Arran
Alan DeKok wrote:
Joe Maimon wrote:
So how do I properly ensure that entries I have attached to DEFAULTS for proxied realms in my users file actually get sent? Currently I have the offending code patched out.
What offending code?
/* * Delete any reply we had accumulated until now. */ pairfree(&request->reply->vps);
Joe Maimon wrote:
What offending code?
/* * Delete any reply we had accumulated until now. */ pairfree(&request->reply->vps);
OK. I've been trying to figure out a sane way to add that functionality to "unlang". It's easy, but coming up with reasonable syntax is hard. I've also spent more time (finally) writing for the book, and documenting how to convert old configurations to "unlang". It turns out that a number of tiny modules still do useful things, and it would be awkward to add those features to "unlang". Arg. Alan DeKok.
Alan DeKok wrote:
Joe Maimon wrote:
What offending code?
/* * Delete any reply we had accumulated until now. */ pairfree(&request->reply->vps);
OK. I've been trying to figure out a sane way to add that functionality to "unlang". It's easy, but coming up with reasonable syntax is hard.
I've also spent more time (finally) writing for the book, and documenting how to convert old configurations to "unlang". It turns out that a number of tiny modules still do useful things, and it would be awkward to add those features to "unlang".
Arg.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
Would this just not be another config variable that you set ? Something like update config { Ignore-Pre-Proxy-Reply := 'true' } -- 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:
OK. I've been trying to figure out a sane way to add that functionality to "unlang". It's easy, but coming up with reasonable syntax is hard ... Would this just not be another config variable that you set ?
Yuck.
Something like
update config { Ignore-Pre-Proxy-Reply := 'true' }
I don't like config variables controlling the servers behavior. It's more code, and harder to use. As opposed to: update reply { nuke_all_pre_existing_attributes? Foo-Bar += 1 Bar-Foo += 2 ... } Then the people that don't want the attributes to be nuked can just not use that line... i.e. I'm trying to move most of the policies out of the server core into either modules, or "unlang" configurations. Alan DeKok.
participants (7)
-
A.L.M.Buxey＠lboro.ac.uk -
Alan DeKok -
Arran Cudbard-Bell -
Eddie Stassen -
Enrik Berkhan -
Hugh Messenger -
Joe Maimon