feature request: Extended OAuth2 + LDAP configuration options

[nwrkbiz]

Context

We did set up a rather complex podman + DMS + openldap + OAuth2 (keycloak) + roundcube stack and found some configurations that would be benifitial to expose via environment variables. Namely:

• /etc/dovecot/dovecot-ldap.conf.ext -> tls_require_cert (allows using self signed certificates ond/or setting the verification mode)
• /etc/dovecot/conf.d/10-auth.conf -> auth_username_format (keycloak is configured to just provide the username and not a full e-mail address, we configured this to %n)
• /etc/dovecot/dovecot-oauth2.conf.ext -> username_attribute (keycloak is configured to just provide the username and not a full e-mail address, we configured this to preferred_username)

Description

Allow setting the configs described above using following env variables:

OAUTH2_USERNAME_ATTRIBUTE
LDAP_TLS_REQUIRE_CERT
DOVECOT_AUTH_USERNAME_FORMAT

Alternatives

We now did hack some echo/sed magic into the docker-compose command attribute, thats applies the settings described above right before starting DMS.

Applicable Users

DMS-Administrator

Are you going to implement it?

Yes, because I know the probability of someone else doing it is low and I can learn from it.

What are you going to contribute?

Not sure how fast I can provide these changes, if somebody hints me to the files I need to touch I would be glad.

[georglauterbach]

I assigned the maintainer that has the most experience with OAUTH2. I will unsubscribe from this issue, though (too many balls in the air); ping me if you need me again.

[polarathene]

• /etc/dovecot/dovecot-ldap.conf.ext -> tls_require_cert (allows using self signed certificates and/or setting the verification mode)

This is possible once I get this PR merged (pending on docs, which requires me to not be spending time elsewhere in DMS), although it's not likely to make it for v14 and as it's a breaking change will be deferred to v15.

• /etc/dovecot/conf.d/10-auth.conf -> auth_username_format (keycloak is configured to just provide the username and not a full e-mail address, we configured this to %n)

Are you sure that one is required? I don't recall it being required for LDAP which is what this context is really related to IIRC.

Just looked up this setting and %n drops the domain only when it's given. If you're still getting the domain despite omitting it, that's due to something else which I'm aware of as an issue with LDAP and is on my TODO. As such I don't consider this a required fix as it's not the source of the issue.

• /etc/dovecot/dovecot-oauth2.conf.ext -> username_attribute (keycloak is configured to just provide the username and not a full e-mail address, we configured this to preferred_username)

The OAuth2 feature got merged early to avoid being stale, I wasn't a fan of the final config approach but stalling the merge may have been problematic. Plans are to adopt the same config templates feature instead.

I am reluctant towards ENV configs as they're unnecessary, you can provide these configs via volume mount files or compose configs.content feature if you must inline it within the same compose.yml, it's only a little bit more verbose (especially when multiple ENV would otherwise be required).

The config templates feature will simplify that by allowing more flexibility (while still supporting ENV override implicitly).

---

We now did hack some echo/sed magic into the docker-compose command attribute, thats applies the settings described above right before starting DMS.

You should be handling this via user-patches.sh. It'll apply the changes after setup scripts have run and configured everything else, but just before services are actually started.

You'll need to wait on the above concerns being addressed in a future release before you can drop the user-patches.sh workaround.

These are ENV requests that I'm personally against adding into DMS (an ENV that serves the single purpose of updating one setting in a config file, with no real logic beyond applying the value).

[nwrkbiz]

This is possible once I get this PR merged (pending on docs, which requires me to not be spending time elsewhere in DMS), although it's not likely to make it for v14 and as it's a breaking change will be deferred to v15.

O.k., nice!

Are you sure that one is required? I don't recall it being required for LDAP which is what this context is really related to IIRC.

Might be that we do not need this anymore since we changed the username attribute to cn using (I would need to verify this tho):
DOVECOT_USER_ATTRS=cn=user,homeDirectory=home,=uid=5000,=gid=5000

But before we applied this change, the imap login failed without %n.

[polarathene]

But before we applied this change, the imap login failed without %n.

Presently the LDAP tests have this configuration and notes:

docker-mailserver/test/tests/serial/mail_with_ldap.bats

Lines 85 to 90 in 47f8d50

	# Dovecot is configured to lookup a user account by their login name (`userID` in this case, but it could be any attribute like `mail`).
	# Dovecot syntax token `%n` is the local-part of the full email address supplied as the login name. There must be a unique match on `userID` (which there will be as each account is configured via LDIF to use it in their DN)
	# NOTE: We already have a constraint on the LDAP tree to search (`LDAP_SEARCH_BASE`), if all objects in that subtree use `PostfixBookMailAccount` class then there is no benefit in the extra constraint.
	# TODO: For tests, that additional constraint is meaningless. We can detail it in our docs instead and just use `userID=%n`.
	local DOVECOT_QUERY_PASS='(&(userID=%n)(objectClass=PostfixBookMailAccount))'
	local DOVECOT_QUERY_USER='(&(userID=%n)(objectClass=PostfixBookMailAccount))'

Also this if using ENABLE_SASLAUTHD=1 (which you don't actually need, but I mention it because many have it enabled):

docker-mailserver/test/tests/serial/mail_with_ldap.bats

Lines 74 to 83 in 47f8d50

	# When using SASLAuthd for login auth (only valid to Postfix in DMS),
	# Postfix will pass on the login username and SASLAuthd will use it's backend to do a lookup.
	# The current default is `uniqueIdentifier=%u`, but `%u` is inaccurate currently with LDAP backend
	# as SASLAuthd will ignore the domain-part received (if any) and forward only the local-part as the query.
	# TODO: Fix this by having supervisor start the service with `-r` option like it does `rimap` backend.
	# NOTE: `%u` (full login with realm/domain-part) is presently equivalent to `%U` (local-part) only,
	# As the `userID` is not a mail address, we ensure any domain-part is ignored, as a login name is not
	# required to match the mail accounts actual `mail` attribute (nor the local-part), they are distinct.
	# TODO: Docs should better cover this difference, as it does confuse some users of DMS (and past contributors to our tests..).
	local SASLAUTHD_QUERY='(&(userID=%U)(mailEnabled=TRUE))'

---

docker-mailserver/test/tests/serial/mail_with_ldap.bats

Lines 104 to 113 in 47f8d50

	# Postfix SASL auth provider (SASLAuthd instead of default Dovecot provider):
	--env ENABLE_SASLAUTHD=1
	--env SASLAUTHD_MECHANISMS=ldap
	--env SASLAUTHD_LDAP_FILTER="${SASLAUTHD_QUERY}"
	# ENV to configure LDAP configs for Dovecot + Postfix:
	# Dovecot:
	--env DOVECOT_PASS_FILTER="${DOVECOT_QUERY_PASS}"
	--env DOVECOT_USER_FILTER="${DOVECOT_QUERY_USER}"
	--env DOVECOT_TLS=no

[nwrkbiz]

Offtopic but I think the comment is misleading:

Also this if using ENABLE_SASLAUTHD=1 (which you don't actually need, but I mention it because many have it enabled):

docker-mailserver/test/tests/serial/mail_with_ldap.bats

Lines 74 to 83 in 47f8d50

	# When using SASLAuthd for login auth (only valid to Postfix in DMS),
	# Postfix will pass on the login username and SASLAuthd will use it's backend to do a lookup.
	# The current default is `uniqueIdentifier=%u`, but `%u` is inaccurate currently with LDAP backend
	# as SASLAuthd will ignore the domain-part received (if any) and forward only the local-part as the query.
	# TODO: Fix this by having supervisor start the service with `-r` option like it does `rimap` backend.
	# NOTE: `%u` (full login with realm/domain-part) is presently equivalent to `%U` (local-part) only,
	# As the `userID` is not a mail address, we ensure any domain-part is ignored, as a login name is not
	# required to match the mail accounts actual `mail` attribute (nor the local-part), they are distinct.
	# TODO: Docs should better cover this difference, as it does confuse some users of DMS (and past contributors to our tests..).
	local SASLAUTHD_QUERY='(&(userID=%U)(mailEnabled=TRUE))'

In postfix the ldap query match is not the attribute passed to the backend. The query is just used to match an entry. The matched entries attribute to be passed is defined by a different setting (result_attribute) which is hardcoded to mail for all postfix ldap settings as far as we have observed.

When using dovecot directly this is not a problem, as we can work this around using %u ("just use the localpart") in the dovecot query.

[polarathene]

The matched entries attribute to be passed is defined by a different setting (result_attribute) which is hardcoded to mail for all postfix ldap settings as far as we have observed.

Yes, it is presently:

docker-mailserver/target/postfix/ldap-users.cf

Line 5 in 47f8d50

result_attribute = mail

Also the default query filter for saslauthd:

docker-mailserver/target/scripts/startup/setup.d/saslauthd.sh

Line 20 in 47f8d50

ldap_filter: ${SASLAUTHD_LDAP_FILTER:=(&(uniqueIdentifier=%u)(mailEnabled=TRUE))}

My docs rewrite for LDAP does touch on that and it'll be easy to configure once the new approach is merged.

---

If SASLAUTHD is enabled:

• The domain-part is stripped away (which is inconvenient if you have multiple domains/realms), so [email protected] and [email protected] both send a user query to LDAP for john.doe (regardless of providing %u instead of %U, since ldap is not configured with -r like rimap mechanism is for SASLAUTHD).
• The value returned by result_attribute would then be compared to the login username that Postfix has AFAIK (typically user@domain), which at this point appends @$myorigin when no domain-part was given in the login username.

That caveat isn't an issue when using Dovecot as the default SASL provider, so better to not use the saslauthd feature when it's not serving you any value (it was contributed for when Dovecot was not used).

result_attribute = mail is relevant to Postfix not for login IIRC, but for other lookups such as what users exist.

---

When using dovecot directly this is not a problem, as we can work this around using %u ("just use the localpart") in the dovecot query.

You should have a similar experience with Postfix if you disable SASLAUTHD, authentication then becomes Postfix => Dovecot => LDAP, instead of Postfix => SASLAUTHD => LDAP.

[NhProGamer]

so, what is the correct solution for making that working correctly ?

[polarathene]

correct solution for making that working correctly

Be more specific? What in the above discussion are you referring to?

The OAuth feature was merged and released earlier than desired, the improved config support will depend upon the LDAP improvements PR to be merged first (will not arrive in v14, must wait until v15 release of DMS).

You can manually manage your config changes with user-patches.sh in the meantime.