From: Omar Polo <op@omarpolo.com>
Subject: Re: smtpd: table auth offloading
To: gilles@poolp.org
Cc: tech@openbsd.org
Date: Fri, 24 May 2024 09:42:43 +0200

On 2024/05/23 21:55:50 +0000, gilles@poolp.org wrote:
> Hello,
> 
> Just a mail to propose an idea that I discussed with op@ in private.
> 
> In smtpd, there are two codepaths for authentication:
> 
> 1- if no table was provided, smtpd relies on bsd_auth(3)
> 
> 2- if a table is provided, it performs a K_CREDENTIALS lookup which,
>    given a username as a key, looks up the crypt(3)-ed password that
>    is then compared to the one that the user provided.
> 
> When you provide a table to the auth keyword, ie:
> 
>    listen on all [...] auth <foobar>
> 
> Regardless of the backend used by <foobar> you take the second path,
> which is great because any backend that supports key-value lookup is
> usable as an authentication backend in smtpd: inline, file, db, ...
> 
> Problem is that some backends do not expect to be queried this way.
> 
> For example, OpenLDAP and OpenBSD's ldapd have an existing attribute
> userPassword which is mandatory but which we can't use because it is
> not in the format we expect and not meant to be fed to crypt(3) like
> we do for all other table backends. In such cases, we'd rather let a
> table backend do the validation and tell us if it succeeded.
> 
> This diff introduces a new lookup service K_AUTH which is only meant
> to be used by table backends that need custom auth validation. If we
> authenticate against a table that supports K_AUTH, then instead of a
> K_CREDENTIALS lookup we forward the username:password so the backend
> can tell us if authentication succeeded or not.
> 
> ok ?

after sleeping on this I think that maybe we should document this under
smtpd-tables.7 rather than table.5 because this is not about the format
of the data, but rather a special mechanism only for proc tables.

but in any case, it reads fine and I've been surprised by how simple it
is!

ok op@


nit below

> [...]
> --- table.5	2 May 2024 18:14:33 -0000	1.14
> +++ table.5	23 May 2024 21:07:15 -0000
> @@ -113,6 +113,19 @@ Here, the user is allowed to send mail f
>  .Bd -unfilled -offset indent
>  .Ic listen on Ar interface Cm auth Oo Ar ... Oc Cm senders Pf < Ar table Ns >
>  .Ed
> +.Ss Authentication tables
> +In most cases,
> +authentication is best served by a credentials table which provide information that

nit: this is longer than 80 chars :p

(and IIRC the mantra is "new sentence, new line", so no need to break the
line after a comma.)

> +.Nm smtpd 8
> +can use to validate itself using
> +.Nm bsd_auth 3
> +or
> +.Nm crypt 3 .
> +.Pp
> +In some cases,
> +this is not desireable and the validation needs to be offloaded.
> +The authentication tables support doing a check on a username and password,
> +returning success or failure based on custom logic.
>  .Ss Domain tables
>  Domain tables are simple lists of domains or hosts.
>  .Bd -unfilled -offset indent