External authentication (LDAP Support)

[ciroiriarte]

Hi!, I see there are several requests for external authentation but no solution for any of them.

I would like to know what's the best approach to introduce mailcow to an ecosystem where an authentication platform is already inplace and used for all the application (LDAP/SAML/OAuth).

I usually see AD/OpenLDAP/LemonLDAP/Gluu in the wild as authentication source and would be nice to be able to do it by domain (I'm just thinking out loud).

Any thoughts on this?.

Ref:
#1483
#706
#684

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[rennerdo30]

Any news regarding this topic?
I would like to connect my mailcow to my active directory,

[andryyy]

Not interested. It’s a commercial feature I don’t plan to add to the open source mailcow ever.

[Braintelligence]

@rennerdo30 You can go ahead and fork the project anytime. I'm sure many people would like to help if you'd incorporate Gluu; Mailcow is GPLv3 after all :).

[andryyy]

That’s true. :)

[ghost]

Not interested. It’s a commercial feature I don’t plan to add to the open source mailcow ever.

I wouldn't say it's a commercial only feature. Of course it's standard but people who are using this software are often IT hobbists or something like this. These kind of people are more likely to have an private LDAP or something like this.

And why don't you want to add something just because it's a commercial feature?

[fastfend]

Sounds like sso.tax

[BloodyIron]

Not interested. It’s a commercial feature I don’t plan to add to the open source mailcow ever.

LDAP/central auth is not a commercial feature, and even still, don't you provide paid support for mailcow when a client wants it? I guarantee you this is a barrier to implementation for those considering alternatives to the now-not-open-source Zimbra 9. No central auth? Not even ready for actual account organisation. Oh, and there are many examples of not-commercial LDAP implementations, openLDAP, FreeIPA, etc.

[ghost]

Sounds like sso.tax

Added it :P

LDAP/central auth is not a commercial feature,[...]

I have to agree, it's not. It's a security feature. Of course, the normal person don't use it, what kind of people use mailcow? Mostly IT nerds and maybe a few small companies. I would call myself an IT nerd and I run a local LDAP instance for my local stuff. I would use it in a personal environment.

[LucaDev]

Does someone sell LDAP directories?

Actually yes. Microsoft with Active Directory for example.

Nevertheless, I fully agree with you. I - just like many others here - would also love to see native LDAP connectivity

[BloodyIron]

Does someone sell LDAP directories?

Actually yes. Microsoft with Active Directory for example.

Hehe I have to leave my opinion here regarding this point. I disagree. Active Directory is a commercial directory service yes, its LDAP-compatible (has a framework to allow compat), but is not LDAP. So one can't say Microsoft sells LDAP directories, they sell Active Directory, which is very much different product altogether.

Active Directory provides LDAP as a component that is LDAP DN compliant.

[LucaDev]

@patschi since you reopened this: Is this planned or just considered not as "uninteresting" as before?

[patschi]

Unfortunately there're no concrete plans implementing this as of now.

I don't think it's "uninteresting" (quite the opposite for me personally actually), but there's not been a requirement or funding to get this implemented. Most regular, private users don't need external authentication via LDAP or so, so it's not a priority.

If there's interest from companies, it can be funded if required to prioritize this one.
I've just re-opened this one to have this tracked accordingly.

[BloodyIron]

Honestly this is a chicken and the egg thing. I can appreciate that you have limited resources (time, etc) to contribute to this project. But the harsh reality is a company typically isn't going to bankroll adding a feature if there's no guarantee of it. Companies will pass on this suite because that feature is not already implemented. So if you want to attract companies as prospective clients (paying or otherwise), you need to invest in this and other common features they care about first, otherwise you're just limiting how many will consider even trying your tool.

This is ultimately going to be a you decision to make, but I guarantee you there are already companies that have decided to not consider this suite for their needs based on this one absent feature.

[andryyy]

So you want to provide it? When do you start? :)

We have a bunch of companies using mailcow, I wonder why they don't complain.

[waja]

Can we please stop throwing shit on each other? Maybe this will be implemented or not. You are all free start committing code for feature requests and creating Pull Requests.

Any did I say that you also can fork this project and implement what ever you like for your own (or pay someone else to do it)?

[LucaDev]

Please calm down. Mailcow is a public project. Anyone can contribute to it. I would like to see external authentication as well. But this is no reason to tell @andryyy in any way how to run his business. I agree that some businesses might be more inclined to mailcow if it has support for it (I can even name one or two that are using custom tools like https://github.com/Programmierus/ldap-mailcow to add user synchronisation). Nonetheless, it is @andryyy's decision what to implement and what not to. I'm sure he would merge it right away if someone put up a PR to implement it. His time - just like all of our time - is limited. He has to decide what and when he wants to implement something.

Danm it @waja was faster than me :P Nevertheless: Thank you. I'm glad that I'm not the only one with this opinion

[andryyy]

Thank you. :)

[theoneandonly-vector]

As LDAP is quite easy to add using the API (there are already working projects on github doing exactly this), I really would love someone to implement OAUTH or SAML instead as this is much harder to do.. but would really add value at least when you like 2FA on your apps.

[pkejval]

@DerLinkman

I'm just hoping for it not being Blizzard Soon™ https://wowwiki-archive.fandom.com/wiki/Soon
or in Valve time https://developer.valvesoftware.com/wiki/Valve_Time

🤣

[FreddleSpl0it]

the feature is in the nightly build now. https://mailcow.email/posts/2023/mailcow-idp/
If someone wants to include keycloak into the mailcow stack:

create docker-compose.override.yml

version: '2.1'
services:

  keycloak-mailcow:
    image: quay.io/keycloak/keycloak:latest
    dns:
      - ${IPV4_NETWORK:-172.22.1}.244
    command:
      - start
      - --import-realm
      - --proxy edge
      - --hostname=${MAILCOW_HOSTNAME}
      - --http-enabled=true
      - --http-relative-path=/auth
      - --hostname-strict-https=false
      - --db=mariadb
      - --db-url=jdbc:mariadb://mysql/mailcow
      - --db-username=${DBUSER}
      - --db-password=${DBPASS}
      - --spi-x509cert-lookup-provider=nginx
    environment:
      - MAILCOW_HOSTNAME=${MAILCOW_HOSTNAME}
      # only initial
      - KEYCLOAK_ADMIN=admin
      - KEYCLOAK_ADMIN_PASSWORD=moohoo
      - KEYCLOAK_LOGLEVEL=TRACE
    restart: always
    tty: true
    networks:
      mailcow-network:
        ipv4_address: ${IPV4_NETWORK:-172.22.1}.247
        aliases:
          - keycloak

create data/conf/nginx/site.keycloak.custom

  location /auth/ {
    proxy_hide_header X-Frame-Options;
    proxy_pass "http://keycloak:8080/auth/";
    proxy_set_header   Host $host;
    proxy_set_header   X-Real-IP $remote_addr;
    proxy_set_header   X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header   X-Forwarded-Proto $scheme;   
    proxy_buffer_size 128k;
    proxy_buffers 64 512k;
    proxy_busy_buffers_size 512k;
    proxy_send_timeout 3600;
    proxy_read_timeout 3600;
    client_body_buffer_size 128k; 
  }
  location /auth/admin {
    proxy_hide_header X-Frame-Options;
    proxy_pass "http://keycloak:8080/auth/admin";
    proxy_set_header   Host $host;
    proxy_set_header   X-Real-IP $remote_addr;
    proxy_set_header   X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header   X-Forwarded-Proto $scheme;   
    proxy_buffer_size 128k;
    proxy_buffers 64 512k;
    proxy_busy_buffers_size 512k;
    proxy_send_timeout 3600;
    proxy_read_timeout 3600;
    client_body_buffer_size 128k; 
  }

[NexZhu]

@FreddleSpl0it Is the LDAP support limited to Keycloak? I'm running an OpenLDAP instance and want to use it as the authentication source.

[pkejval]

@NexZhu Mailcow should connect to Keycloak and your Keycloak to any user DB. It was announced there: https://mailcow.email/posts/2023/ldap-announcement/

[FreddleSpl0it]

@NexZhu It's limited to OIDC Identity Providers and Keycloak is the most supported one with more features like automatic user provisioning. The hardest Part was to change the way authentication works especially the Dovecot authentication. But this is now so universal designed, that we could basically add a direct LDAP support in the future.

But for now, it's only OIDC and especially Keycloak. Keycloak has so many features, such as LDAP or Kerberos Providers, and even the ability to log in with social platforms like GitLab, Twitter, and so on. We didn't want to reinvent the wheel, so we chose this path.

How to connect Keycloak to LDAP: https://mailcow.email/posts/2023/mailcow-idp/#ldap

[mstilkerich]

Hello, does this also allow oauth authentication at the SoGo CardDAV and CalDAV interfaces?

[FreddleSpl0it]

@mstilkerich No, it only permits users to utilize the external IdP to log in to the mailcow UI. Within the mailcow UI, users can proceed to the SOGo Webmail or generate App Passwords for use with other applications.

Could you tell me which application you use that can utilize OAuth for logging in to CardDAV and CalDAV?
Perhaps I can implement this.

[mstilkerich]

My interest is on Roundcube. I tried to setup a SSO mailcow setup with Roundcube using the builtin oauth2 provider in mailcow a while ago. I got it working with dovecot and postfix (configuration changes for both needed) if I recall correctly but failed with SoGo's carddav interface.

But I am just interested in this for educational purposes / having a test env for roundcube carddav plugin with oauth authentication, for my small family server I have no need for a central authentication solution.

Btw I did have a working OIDC SSO setup with roundcube, keycloak, dovecot, postfix and nextcloud (for contacts/carddav), so I know from the roundcube side this would be supported.

[MichaelSasser]

First off, Great work. Thank you very much for implementing this feature!

I have a few questions about how this would look in the future.

1. Will we be able to authenticate using multiple realms against the same instance of mailcow?

   In other projects, this is done by allowing to configure multiple identity providers of the same kind/type and giving them a display name, which is shown on the login page. Some of them even allow HTML display names, which enable administrators to display an <img> in front, so users find their provider faster.

   The scenario is that I have two realms on my keycloak instance. One personal, for me and my family, and one for our moderators of our public community project. The realms are differently configured in keycloak have a different set of services they access. Both realms are served on a different domain (still, the same instance of keycloak) and all users (in both realms) use only their realm-specific domain in their email address with their preferred_username as local part. The same happens on the mailcow side. For example:

   • Family Realm
     • user foo ⟷ [email protected]; keycloak: login.family.com; mailcow: mail.family.com
     • user bar ⟷ [email protected]; keycloak: login.family.com; mailcow: mail.family.com
   • Community Realm:
     • user foo ⟷ [email protected]; keycloak: login.community.com; mailcow: mail.community.com
     • user baz ⟷ [email protected]; keycloak: login.community.com; mailcow: mail.community.com

2. Is mailcow using x509 client certificate lookup (as shown in @FreddleSpl0it example above)? The reason for the question is that keycloak's support for this feature is limited to some reverse proxies I'm not using.

3. Will we be able to disable all other kinds of authentication (besides app-passwords, of course) or block the endpoints in the reverse proxy, so users can only authenticate through OIDC?

4. Will we be able to configure this using a config file (or environment variables)?

5. How will we be able to migrate existing mailcow users (with their data and their app-passwords to the OIDC flow)?

[MohammedNoureldin]

Will this OIDC feature be usable with Desktop / Mobile clients? Or is it exclusive for Webmails?

In case it can be used in Desktop clients, how will the client prompt / redirect to the IdP login page? Or let us say, which clients are supported?

[FreddleSpl0it]

@MichaelSasser

1. That's a good point. At the moment only one Realm for Keycloak is supported. If you have configured a IdP, there will be a SSO dropdown button that redirects users to the Realm Login. I don't know yet how we could redirect users to the right Realm login if multiples could be configured. The only way we could do that, as you say, is to allow multiple IdP's and then display each IdP as a separate login button (maybe as an app button)
2. I should say that the example i posted, was the setup i used in our tests. This will include Keycloak into the mailcow Stack behind the nginx container. I wouldn't run it in production. Preferably, you already have a running Keycloak instance or you set one up yourself separately. mailcow will not use x509 client certificate lookups.
   Also in production you should limit the access to the /admin endpoint somehow. But keep in mind that mailcow needs to access this endpoint, if you use the Mailpassword Flow, Periodic Full Sync or Import users feature.
3. For each user there is a authsource, that defines how this user should be authenticated. If the users authsource is keycloak or generic-oidc than there is no other way for this user to authenticate besides app passwords. This is also the reason why IdP users need to login to mailcow UI in order to get into the SOGo Webmail.
4. Do you mean the IdP configuration? It is configurable by admins via mailcow UI.
5. This should be easy. See https://mailcow.email/posts/2023/mailcow-idp/#change-idp-for-existing-mailbox-users

[FreddleSpl0it]

Will this OIDC feature be usable with Desktop / Mobile clients? Or is it exclusive for Webmails?

@MohammedNoureldin Currently it is not supported and I don't know yet of any Client that allows the configuration of a custom oAuth provider. The client would need to be able to open a Browser and redirect the user to the IdP login. On success, it would receive a oAuth token and uses this for further authentication via IMAP or EAS

[mkuron]

I don't know yet of any Client that allows the configuration of a custom oAuth provider

There is RFC 7628: A Set of Simple Authentication and Security Layer (SASL) Mechanisms for OAuth, which allows the client to retrieve the provider information from the server. It is supported by the Dovecot server. There are several clients (Thunderbird, Apple Mail, Evolution, emClient, Outlook) that support OAuth with Google, Microsoft and/or Yahoo, but as of 2021 these were using static lists of OAuth providers. At least for Thunderbolt and Evolution, that still seems to be the case.

[MohammedNoureldin]

Thank you for the info, @mkuron and @FreddleSpl0it,

There is RFC 7628: A Set of Simple Authentication and Security Layer (SASL) Mechanisms for OAuth, which allows the client to retrieve the provider information from the server. It is supported by the Dovecot server. There are several clients (Thunderbird, Apple Mail, Evolution, emClient, Outlook) that support OAuth with Google, Microsoft and/or Yahoo, but as of 2021 these were using static lists of OAuth providers. At least for Thunderbolt and Evolution, that still seems to be the case.

So for the these clients it should be technically a matter of giving the end-user the ability to configure his IdP on the client? Is there anything we can do, except extending the code of these software, to allow the mail clients to login using our custom IdP? In other words, to allow the end-user to configure SASL in the client?

[mkuron]

You could check their bugtrackers for whether any work on that is planned, and file feature requests for RFC 7628 support if it isn't already planned. Also, given the lack of client support, I don't know whether Dovecot's Oauth support is well-tested and stable, so you could do some online research about whether anyone has successfully deployed it.

Thunderbird has several feature requests related to various aspects of this:

• https://bugzilla.mozilla.org/show_bug.cgi?id=1591782
• https://bugzilla.mozilla.org/show_bug.cgi?id=1602166

[havi05]

Thank you for the great feature!
I also have a few questions about it.

1. Did I understand it correctly that (currently?) only email users (not administrators and domain administrators) can use openid connect? If no, is it planned to add this?

2. Is currently only one alias (mailcow_template) possible at keycloak, or is there a list with all possibilities?
   (For example mailcow_quota to change the limit for one user,
   mailcow_role to change the permissions of one user or
   mailcow_email_alias_enabled to allow the use of email aliases by the user)

3. Is it possible to change for example the quota of a user which uses mailcow_template or will it be changed back when updating via keycloak?

[privnote42]

@FreddleSpl0it
Maybe it's interesting for you, or for others.
Here is a docker-compose.yml created to be able to log in to sogo via SSO with the help of keycloak.
https://github.com/fsphys/sogo-keycloak-docker-example

Unfortunately, the repo is no longer maintained and it no longer works with the current sogo.
When I try to log in, I get a 501 error.
(The URL for the sogo repo is no longer up to date in the Dockerfile, just as a hint)

Perhaps this approach can also be integrated directly into the mailcow stack so that the current workaround with the php script can be dispensed with?

[dorianim]

Some time ago, I built a hacky syncer for the linuxmuster project, which enables automatic user and mailing list provisioning and authentication from LDAP in mailcow.
I'd love to get rid of it in the favor of this new implementation. However, there is one thing, that does not seem possible yet:
Mailing-Lists. In Linuxmuster, users can create projects and add users to them. The syncer then creates a mailbox for each project and adds a sieve filter to forward incoming mail to all members. Is there any plan to implement something similar for oidc?

[MohammedNoureldin]

In this case, if I want to use any centralized user management (e.g., federated users in KeyCloak) you will only be able to use web interface, but not any native client for desktop or mobile, to login to your email. Right?

[davidus05]

As mentioned in that issue #5445 it seems that OIDC is not fully generic/not fully working. Only the KeyCloak integration seems to be working currently.

[palukku]

Maybe you should do a third option or change the default oidc option for the identity provider.
At the moment you require to set the urls for auth/token etc. myself. But instead you could get all these informations from a link which keycloak and authentik etc. are providing:
keycloak.tld/realms/REALMNAME/.well-known/openid-configuration
authentik.tld/application/o/PROVIDERNAME/.well-known/openid-configuration

If you would get the informations for the endpoints from this file, it would be much easier to configure for example Authentik or other openid connect services.

Maybe you could use this also to implement a custom link for getting all the users like it is there for keycloak, so it would be much easier to do a full sync with other providers than keycloak.

[Fly7113]

Are there any news about the status of this feature?
Has it reached an only testing stage or are there plans to expand it before it makes its way to production (relative to its actual state in the nightly build)?

[InfAmoUsaeble]

I am also curious about this integration... Would it be possible to run a separate script or something, to enable this functionality without having to run nightly? =)

Thanks for all your work!