Re: Conditionally disabling auth policy

29 Sep 2017

      On 28.09.2017 22:32, Mark Moseley wrote:
...
On Thu, Sep 28, 2017 at 9:34 AM, Aki Tuomi <aki.tuomi@dovecot.fi
<mailto:aki.tuomi@dovecot.fi>> wrote:
> On September 28, 2017 at 7:20 PM Mark Moseley
&lt;moseleymark@gmail.com &lt;mailto:moseleymark@gmail.com>> wrote:
>
>
> On Wed, Sep 27, 2017 at 10:06 PM, Aki Tuomi
&lt;aki.tuomi@dovecot.fi &lt;mailto:aki.tuomi@dovecot.fi>> wrote:
>
> >
> >
> > On 27.09.2017 20 &lt;tel:27.09.2017%2020>:14, Mark Moseley wrote:
> > > On Wed, Sep 27, 2017 at 10:03 AM, Marcus Rueckert
&lt;darix@opensu.se &lt;mailto:darix@opensu.se>>
> > wrote:
> > >
> > >> On 2017-09-27 16:57:44 +0000, Mark Moseley wrote:
> > >>> I've been digging into the auth policy stuff with
weakforced lately.
> > >> There
> > >>> are cases (IP ranges, so could be wrapped up in remote {}
blocks) where
> > >>> it'd be nice to skip the auth policy (internal hosts that
I can trust,
> > >> but
> > >>> that are hitting the same servers as the outside world).
> > >>>
> > >>> Is there any way to disable auth policy, possibly inside a
remote{}?
> > >>>
> > >>> auth_policy_server_url complains that it can't be used
inside a remote
> > >>> block, so no dice there. Anything I'm missing?
> > >> From my config:
> > >> ```
> > >>   allowed_subnets=newNetmaskGroup()
> > >>   allowed_subnets:addMask('fe80::/64')
> > >>   allowed_subnets:addMask('127.0.0.0/8 &lt;http://127.0.0.0/8>')
> > >> [snip]
> > >>   if (not(allowed_subnets.match(lt.remote)))
> > >>   -- do GeoIP check
> > >>   end
> > >> ```
> > >>
> > >> of course could just skip all checks in that case if really
wanted. but
> > >> you probably want to be careful not to skip too many checks
otherwise
> > >> the attack moves from your imap port e.g. to your webmailer.
> > >>
> > >>
> > >>
> > > Hi. Yup, I've got my own whitelisting going on, on the
wforce side of
> > > things. I'm just looking to forgo the 3 HTTP reqs completely
to wforce,
> > > from the dovecot side, if possible. I've got some internal
services that
> > > can generate a significant amount of dovecot logins, but
it's kind of
> > silly
> > > to keep doing auth policy lookups for those internal servers.
> > >
> > > To continue the Lua thread, I was thinking I could also drop
a local
> > > openresty to do some conditional lookups. I.e. if remote IP
is known
> > good,
> > > a localhost nginx just sends back the response; if not a
known good IP,
> > > then proxy the req over to the wforce cluster. That might be
a bit
> > overkill
> > > though :)
> > Hi!
> >
> > Currently it's not possible to disable auth_policy conditionally,
> > although it does sound like a good idea.
> >
> > You should probably see also if your webmail supports passing the
> > original IP to dovecot using
> >
> > a01 ID ("X-Original-IP" "1.2.3.4")
> >
> > before login, which would let you use weakforced in more
meaningful way.
> > There are few other fields too that can be used
> >
> > Aki
> >
>
> Yup, I've got that set up. I've got no problems with
short-circuiting the
> request on the weakforce side quickly, in case of known good
ips. Just
> hoping to avoid some unnecessary auth policy lookups.
>
> Out of curiosity (and I've googled this before), what other
fields can be
> used there?

* x-originating-ip - client IP
* x-originating-port - client port
* x-connected-ip - server IP (like, on proxy)
* x-connected-port - server port
* x-proxy-ttl - non-negative integer, decremented on each hop,
used for loop detection.
* x-session-id - session ID, if you want to provide one
* x-session-ext-id - session prefix
* x-forward-&lt;any_field_name> - field to import into passdb during
authentication, comes prefixed with forward_. e.g if you set
x-forward-username, it comes as forward_username, and can be used like

username=%{forward_username}
The 'forward' stuff is gold. I found that I had to access it like
this: %{passwd:forward_<name>}
Is that the right way to use it?
Also (unrelated), I noticed this in the wiki but it's not in the
release notes for 2.2.32 (and it sounds super useful): 
"Since v2.2.32 it's possible to use conditionals in variable expansion"
Depends where you use it. In passdb expansion, you can use
%{forward_name}. You should use userdb_something=%{forward_something} to
move it properly into userdb, you can drop the forward, too. We use this
to forward stuff from proxy=>backend.
Conditionals were probably forgotten from release notes.
Aki