Conditionally disabling auth policy

[Aki Tuomi]

On 28.09.2017 22:32, Mark Moseley wrote:
> On Thu, Sep 28, 2017 at 9:34 AM, Aki Tuomi <aki.tuomi at dovecot.fi
> <mailto:aki.tuomi at dovecot.fi>> wrote:
>
>
>     > On September 28, 2017 at 7:20 PM Mark Moseley
>     <moseleymark at gmail.com <mailto:moseleymark at gmail.com>> wrote:
>     >
>     >
>     > On Wed, Sep 27, 2017 at 10:06 PM, Aki Tuomi
>     <aki.tuomi at dovecot.fi <mailto:aki.tuomi at dovecot.fi>> wrote:
>     >
>     > >
>     > >
>     > > On 27.09.2017 20 <tel:27.09.2017%2020>:14, Mark Moseley wrote:
>     > > > On Wed, Sep 27, 2017 at 10:03 AM, Marcus Rueckert
>     <darix at opensu.se <mailto: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 <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-<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