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