hi
> well, the reason is that I want to base the decision to grant or deny access based >on the outcome of some database queries, which I believe is a costly operation. To do >this, I can hook somewhere into the process and to my queries for every >access-request which I receive, or in other words I need to do it approximately 4-5 >times for one single TLS attempt. If I'd know for example in exec-program-wait script >I could call or in a corresponding perl-function, that the next packet which will be >sent from the RADIUS server to the client is an access-challenge, then I'd not need >to do the db-queries, but could wait until I see that the next packet would be an >ACCESS-ACCEPT. This is a reason from the efficiency perspective since I'd be able to >avoid many lookups. in this case, hook in in the very beginning of the process, on the arrival of the first request. what you need, is the user-name attribute. > Let's now further assume, that I don't have radius accounting and would like to >perform some actions in case of an successful authentication (e.g. count credits >etc.) , then I'd need to hook into the authentication packet exchange as well and at >the same point in time, right before the access-accept is sent to my work. here i would do it after the last message, the accept. e.g. in post-auth. anyway, the both tasks are contradictory: in the first you want to influence the auth process and in the second you want to act upon its result, so you will need at least two queries anyway: one read query saying if the user can or can not authenticate and the other write query in the case of success. you would do the first at the beginning as i said before and the second e.g. only if you see an accept message pass by. so sorry but i still don't see why you want to be "just before the end". > > i kind of think, that what you want to do is completely avoidable: > > - if you want to send a reject if some conditions are not fulfilled, why > > don't you check the database BEFORE processing TLS? tls is pretty costly > > in terms of CPU power etc., it might be even better to deny immediately > > if whatever condition is not ok. > > - if you tend to send the message as it is, as a result of the TLS > > exchange, i.e. indepedently of you database queries, than i don't get > > why you can't do it afterwards or what it would change anyway. > > I hope I was able to describe my intention well enough above. perhaps you should think in a more flexible way about what you want to achieve. you seem to have one possible solution figured out in your mind and you try to pursue this solution at any cost. what if another possibility achieves exactly the same, why is it no good? :-) > > and finally, just as a first idea, you can easily achieve what you want > > (why ever you want it) by separating the EAP-TLS authenticator and the > > database-query-process, e.g. using proxying. when you receive an accept > > from the FR-instance to which you proxied the last request to, you can > > react using the post-proxying e.g.... > > hmm, I did not look into this option yet. Sounds worth for me to investigate... it will work. that's what we do here (however, for a different reason) > Sure, the state must be there, but to be honest: I did not manage to find the >location in the code and where I'd need to hook into. Hopefully someone can give me a >pointer. yes, you need a developper to answer this question to you. (i'm not :-)) ciao artur -- Artur Hecker artur[at]hecker.info - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
