Please add support for authentication via (Open)LDAP

[chlarsen]

With the above in place, I would drp nearly everything and came in running for mox! Thank you!

[mjl-]

hi @chlarsen, thanks for raising this.

i'm trying to understand in more detail how this works. i've never used ldap, but have looked at the high-level explanations a few times.

some questions about ldap and how it would fit:

• how does "ldap authentication" work? is it a matter of authentication as the user, and checking if that succeeds? with https://en.wikipedia.org/wiki/Lightweight_Directory_Access_Protocol#Bind_(authenticate). or does it (also) involve looking up certain fields?
• mox supports various authentication mechanisms. from plain passwords (directly in imap, smtp and http basic), to schemes (with sasl) were the plain text password isn't exchanged (like scram, where a server would only stores information derived from a password), and sometimes with tls channel binding (like scram-*-plus, where authentication uses values derived from the tls connection, meaning authentication will fail if the authentication server doesn't have access to tls connection internals (which may imply that the mox has to be the service handling the auth exchange)). so the question is: are you expecting clients to authentication to mox with plaintext password (over tls), or also with sasl schemes that need password-derived values. mox would have to translate the incoming auth exchange to something that works with the ldap server. some auth mechanisms may not be available for such accounts.
• users would also still be created in mox, and only authentication is done through ldap? or are you expecting to any users created in ldap to get an account in mox (e.g. automatically created on first auth attempt). automated provisioning raises lots of other questions. such as getting notifications about account changes, finding alternative addresses for an account.
• would an ldap server be configured for the entire mox instance, or per domain, or per account? and i suppose accounts with an ldap config should not have any mox-local password.

[chlarsen]

Dear Mechiel,

First of all, apologies for my belated reply, and thank you for your follow-up. Here is my use case that, years ago, made me add OpenLDAP as central authentication framework to my IT architecture: I have a number of applications running, ranging from mail and file sharing to enterprise resource planning stuff and a wiki for knowledge management. All the above applications are used by different user groups, and each user has his/her personal login. In order to avoid the highly repetitive per-application management of users and groups from within the respective application, I have used OpenLDAP to create user accounts with required field, such as name, email, password, etc, and stuck each user into the application group they have access to. Means: a user that is member in the group "wiki" can, with the right username (email) and password access that wiki. If you are not a member of the "wiki" group, you are out of luck. And, yes, application-based accounts are automagically created upon the first user login into the said application. Finally, users can manage their passwords and a restricted number of user fields (not: their primary email that acts as key identifier) and reset lost password via a simple user/password management application.

hi @chlarsen, thanks for raising this.

i'm trying to understand in more detail how this works. i've never used ldap, but have looked at the high-level explanations a few times.

some questions about ldap and how it would fit:

* how does "ldap authentication" work? is it a matter of authentication as the user, and checking if that succeeds? with https://en.wikipedia.org/wiki/Lightweight_Directory_Access_Protocol#Bind_(authenticate). or does it (also) involve looking up certain fields?

Yes, OpenLDAP can either do user lookups anonymously, or you stick a read-only role with password into the application. I tend to use the latter approach.

* mox supports various authentication mechanisms. from plain passwords (directly in imap, smtp and http basic), to schemes (with sasl) were the plain text password isn't exchanged (like scram, where a server would only stores information derived from a password), and sometimes with tls channel binding (like scram-*-plus, where authentication uses values derived from the tls connection, meaning authentication will fail if the authentication server doesn't have access to tls connection internals (which may imply that the mox has to be the service handling the auth exchange)). so the question is: are you expecting clients to authentication to mox with plaintext password (over tls), or also with sasl schemes that need password-derived values. mox would have to translate the incoming auth exchange to something that works with the ldap server. some auth mechanisms may not be available for such accounts.

Passwords in OpenLDAP are using SASL and/or TLS. IMHO and for my setup, a decent TLS deployment may well be sufficient, plus, of course, decent password encryption on the OpenLDAP server side. You are right, OpenLDAP, being a wild box of 1001 options and features, offers a plentiful of password exchange mechanism, yet I think plain plus TLS should be just fine.

* users would also still be created in mox, and only authentication is done through ldap? or are you expecting to any users created in ldap to get an account in mox (e.g. automatically created on first auth attempt). automated provisioning raises lots of other questions. such as getting notifications about account changes, finding alternative addresses for an account.

User creation would be automatic, as soon as there is a successful login via OpenLDAP. Now, what I have not done and do not intend to do is to manage application-specific groups via OpenLDAP, because this is a level of complication that does not yield any benefits. So, my groups are "mail" for mail users, "wiki" for wiki users (not caring whether their are reviewers or editors, etc), and so forth.

* would an ldap server be configured for the entire mox instance, or per domain, or per account? and i suppose accounts with an ldap config should not have any mox-local password.

This is an interesting one: Cyrus-IMAPd in LDAP mode demands domains to be configured in OpenLDAP, Dovecot does not in my experience. I prefer to keep it simple and just do the account management in OpenLDAP, where I use the official qmail scheme to allow email aliases, forwards, etc to be configured. Has worked like a charm ever since my Qmail-LDAP times... :-)

Hope this helps, please sing out, if you have any questions. Thank you!

[RobSlgm]

With the goal of a potential more versatile integration, I'd like to share some thoughts.

While I completely agree with the necessity of central user management in an enterprise environment, the actual experience is usually no smooth sailing.

User provisioning

User provisioning – create and delete users with a standardized setup – would be critical and IMHO higher priority than authentication.

But let’s take just one use-case of an employee leaving the company. Depending on internal policies I have seen following actions:

• Close and delete the e-mail account (never seen that in a corporate environment as first step)
• Block access (IMAP) and forward mail to the successor’s mailbox for some period of time and then close the old email account
• Block access for the leaving employee and allow successor/HR/legal access to the mailbox for some period
• And any further combination…

So as an application developer your options are limited. The best integration experience was usually a concise REST API to allow user management. Enterprise-level centralized user and rights management allows to define workflows for your policies with exits (calls to external systems, via LDAP/Active Directory or REST API’s).

In the context of mox, I would basically suggest offering the user/account related feature set of the current mox CLI as a REST API.

Authentication

Authentication is a major challenge. Static passwords aren't always used. In many industries (including those I've worked in), smart card/certificate-based identities dominate (Windows and Linux) and you won’t find a (user known) password in the LDAP system. Additionally, policies often require MFA.

For clients which were not able to do trust- or public key-based authentication (often OAUTH2), often one-time passwords were used behind the scenes. Obviously, this requires adapted clients and integration between server and authenticator.

As a way forward an authentication hook in mox I believe is beneficial. In the most basic way, it transmits the offered credentials and expects a accept/reject decision. The integration with LDAP - and to other systems - would be external to mox. I’m not sure about the complexity or feasibility in challenge-response scenarios.

Multiple identities

Furthermore, it would be for these kinds of scenarios useful if mox would support multiple identities for one account and allow rules for the usage.

E.g. for one single account user1@example.com

• Identity “Plain” user1 / somesecretpassword
• Identity “Device Mobile Phone” deviceXYZid / anothersecret
• Identity “Local Lan” user1 / [use authentication hook for local LDAP/AD]

Rules should restrict the usage to certain external factors, most probably IP ranges (i.e. Local LAN, VPN, Public).

[chlarsen]

Dear Robert, Thank you for your insightful input. In fact, OpenLDAP can accommodate your corporate requirements, and user management could be done via sth like Canaille. User certificates can be integrated into OpenLDAP if needed - we use them to create in-app digital signatures. You are right, a flexible API is probably what makes most sense (and this would put MOX ahead of the game!), because user authentication is only going to get more complex :-) ! Thank you again.