Hi, I was looking into the new Authentication Policy feature: https://wiki2.dovecot.org/Authentication/Policy I had kinda hoped that I would be able to enfore this in a proxy running in front of several backends. This proxy does not authenticate. It use "nopassword". But I realize that the "succes" reported in the final authpolicy req. (command=report) is not what is actaully happening on the IMAP protocol level, but rather the result of the passdb chain in the proxy. (I should probably have predicted this, it's kinda reasonable). However... since the proxy use "nopassword", ALL passdb lookups result in "success", so the proxy will never report an authentication failure to the authpolicy server. This, of course, forces me to do the authpolicy check on the backend with a shared state, but It would still have been nice to have the proxy being able to do the first "command=allow" req. and reject attemps already there even though the backend does "command=report". /Peter
> On 14 Dec 2017, at 8.30, Peter Mogensen <apm at one.com> wrote: > However... since the proxy use "nopassword", ALL passdb lookups result > in "success", so the proxy will never report an authentication failure > to the authpolicy server.Why not authenticate the sessions at the proxy level already? Is there any reason not to do that? Sami
On 2017-12-14 10:31, Sami Ketola wrote:> >> On 14 Dec 2017, at 8.30, Peter Mogensen <apm at one.com> wrote: >> However... since the proxy use "nopassword", ALL passdb lookups result >> in "success", so the proxy will never report an authentication failure >> to the authpolicy server. > > > Why not authenticate the sessions at the proxy level already? Is there any > reason not to do that?Yes. Several. This is not a new setup. It's an already well established setup and it's unlikely that authentication can be moved to the proxy. /Peter
Hi ... After the below thread, I wrote a patch to select on a node-by-node basis which auth-policy request should be done from that node. To my surprise the exact same functionality then turned up in 2.2.34 with just slightly different option names:* * *auth_policy_check_before_auth*: Whether to do policy lookup before authentication is started *auth_policy_check_after_auth*: Whether to do policy lookup after authentication is completed *auth_policy_report_after_auth*: Whether to report authentication result? This is great. However... in the setup where you have a proxy in front of a backend and the backend does all authentication, it would be nice with an option to only do report requests in case of authentication failure. Point being that, if the proxy authentication "fails", it does not proxy and the backend will never see the req. and do any actual authentication or reporting. However, you would probably still want to know that there has been a failed auth-attempt. Enabling "report_after_auth" on the proxy would however, send a lot of meaningless traffic about "successful" proxy auth events which would tell you basically nothing the backed wouldn't later also report. And the ration between success' and failures in the proxy is probably very high. regards, Peter Mogensen On 12/14/2017 08:30 AM, Peter Mogensen wrote:> Hi, > > I was looking into the new Authentication Policy feature: > https://wiki2.dovecot.org/Authentication/Policy > > I had kinda hoped that I would be able to enfore this in a proxy running > in front of several backends. This proxy does not authenticate. It use > "nopassword". > > > But I realize that the "succes" reported in the final authpolicy req. > (command=report) is not what is actaully happening on the IMAP protocol > level, but rather the result of the passdb chain in the proxy. > (I should probably have predicted this, it's kinda reasonable). > > However... since the proxy use "nopassword", ALL passdb lookups result > in "success", so the proxy will never report an authentication failure > to the authpolicy server. > > This, of course, forces me to do the authpolicy check on the backend > with a shared state, but It would still have been nice to have the proxy > being able to do the first "command=allow" req. and reject attemps > already there even though the backend does "command=report". > > /Peter
Point of sending the success ones is to maintain whitelist as well as blacklist so you know which ones you should not tarpit anymore. We know it does scale as we have very large deployments using the whole three request per login model. ---Aki TuomiDovecot oy -------- Original message --------From: Peter Mogensen <apm at one.com> Date: 15/09/2018 11:25 (GMT+02:00) To: Dovecot Mailing List <dovecot at dovecot.org> Subject: Re: auth_policy in a non-authenticating proxy chain Hi ... After the below thread, I wrote a patch to select on a node-by-node basis which auth-policy request should be done from that node. To my surprise the exact same functionality then turned up in 2.2.34 with just slightly different option names:* * *auth_policy_check_before_auth*: Whether to do policy lookup before authentication is started *auth_policy_check_after_auth*: Whether to do policy lookup after authentication is completed *auth_policy_report_after_auth*: Whether to report authentication result? This is great. However... in the setup where you have a proxy in front of a backend and the backend does all authentication, it would be nice with an option to only do report requests in case of authentication failure. Point being that, if the proxy authentication "fails", it does not proxy and the backend will never see the req. and do any actual authentication or reporting. However, you would probably still want to know that there has been a failed auth-attempt. Enabling "report_after_auth" on the proxy would however, send a lot of meaningless traffic about "successful" proxy auth events which would tell you basically nothing the backed wouldn't later also report. And the ration between success' and failures in the proxy is probably very high. regards, Peter Mogensen On 12/14/2017 08:30 AM, Peter Mogensen wrote:> Hi, > > I was looking into the new Authentication Policy feature: > https://wiki2.dovecot.org/Authentication/Policy > > I had kinda hoped that I would be able to enfore this in a proxy running > in front of several backends. This proxy does not authenticate. It use > "nopassword". > > > But I realize that the "succes" reported in the final authpolicy req. > (command=report) is not what is actaully happening on the IMAP protocol > level, but rather the result of the passdb chain in the proxy. > (I should probably have predicted this, it's kinda reasonable). > > However... since the proxy use "nopassword", ALL passdb lookups result > in "success", so the proxy will never report an authentication failure > to the authpolicy server. > > This, of course, forces me to do the authpolicy check on the backend > with a shared state, but It would still have been nice to have the proxy > being able to do the first "command=allow" req. and reject attemps > already there even though the backend does "command=report". > > /Peter-------------- next part -------------- An HTML attachment was scrubbed... URL: <https://dovecot.org/pipermail/dovecot/attachments/20180915/56c3c5ce/attachment.html>