I am currently working alone on this project, and I chose Keycloak as I believe it’s a solid project and I already have experience with it.
Initially, I wanted to implement pure OIDC authentication, but I encountered some issues with SMTP and IMAP authentication.
I modified the Dovecot Lua script for authentication, changing it from SQL to making HTTP requests to a PHP script.
The PHP script performs a lookup to check if the user exists in Keycloak, and if so, it uses the OIDC Resource Owner Password Credentials flow for authentication, as it’s the only possible way since there is no browser involved.
However, I read that the Resource Owner Password Credentials grant is omitted from the OAuth 2.1 specification, and therefore, this flow will be deprecated in OAuth 2.1. https://oauth.net/2.1/
To support this in a different way, I decided to use a Keycloak user attribute to store a password hash, which can be mapped from LDAP and verified against it.
Although this flow is not a pure OIDC solution, as it uses Keycloak’s admin REST API to lookup user attributes, it was the only viable option.
In the future, it may be possible to implement this flow for other IAM services if they provide similar capabilities.
But there is a way to support generic OIDC providers.
Users would have to use Single Sign-On (SSO) to log in to the mailcow UI and set up an app password to be used for mail clients.
I forgot to mention that it’s also necessary to include additional user information in the access token. I’m not sure if Authentik supports this.
In Keycloak, you can add user attributes directly to the access token. In mailcow, you can then map these attributes to a template, which mailcow uses to determine the mailbox type for each user. When a user logs in for the first time via SMTP, IMAP, or the web UI, mailcow creates the mailbox according to the mapped template.
Also, there’s a background script that syncs these attributes to update the mailbox if the template in Keycloak or LDAP has changed.