Conditionally disabling auth policy

[Mark Moseley]

On Thu, Sep 28, 2017 at 9:34 AM, Aki Tuomi <aki.tuomi at dovecot.fi> wrote:

>
> > On September 28, 2017 at 7:20 PM Mark Moseley <moseleymark at gmail.com>
> wrote:
> >
> >
> > On Wed, Sep 27, 2017 at 10:06 PM, Aki Tuomi <aki.tuomi at dovecot.fi>
> wrote:
> >
> > >
> > >
> > > On 27.09.2017 20:14, Mark Moseley wrote:
> > > > On Wed, Sep 27, 2017 at 10:03 AM, Marcus Rueckert <darix at 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')
> > > >> [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-<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"