WebSSO - Webmail with SAML or OIDC
-
Hello,
Our organization has been using MDaemon for many years, and we are very satisfied with it.
We are currently implementing a WebSSO solution and would like to integrate our webmail with it for two main reasons: to meet a functional requirement and to enhance security by using an IDP through OpenID Connect, SAML, or, as a last resort, HTTP headers.
This feature is crucial for us, and we would greatly appreciate it if you could consider adding it in a future release, as many of your competitors already do.
Could you kindly let us know if this is already planned or if it could be included in an upcoming version?
Thank you in advance for your time and consideration.
Best regards,
Arnaud,
-
We are intending to look into SAML for a future version but we do not have a date for when something might be available.
In case it helps, we have published information on how you can integrate a webmail into an intranet page, https://github.com/mdaemon-technologies/intranet-integration. This includes information on potential options for authenticating with webmail.
-
Hello Arron,
Thank you for your response. I'm happy to hear that you’re planning a SAML implementation, though a bit less so to learn that there is no estimated timeline.
Is there any way to prioritize the implementation of this feature? I imagine many users are waiting for web SSO. Do you have a customer voting system for this type of request?
Thank you.
Have a great day.
-
Hello,
I hope you're doing well.
Apologies for insisting, but we are in the process of integrating all our tools through various SSO mechanisms. Out of the thirty or so tools we use, only three or four do not yet support this type of authentication.
As you can imagine, users quickly grow accustomed to convenience, and in this case, they regularly ask us: "When will this be available for webmail?"
We would really appreciate any update you can provide on this.
Thank you in advance.
-
Hello,
Unforutnately I do not have an update to share. We are still intending to look into SAML for a future version but we do not have a date for when something might be available.
-
@Arron OIDC is simpler to implement than SAML and it works much better with mobile applications, because it uses RESTful API endpoints.
-
Thank you for the information, we will take a look at it.
-
Hi @Arron Caruth,
I hope you're doing well.
I’m reaching out to kindly ask if there have been any updates regarding the planned support for SAML authentication in MDaemon Webmail. In a previous communication, it was mentioned that SAML integration was being considered for a future version, although no timeline had been confirmed at that point.
As an organization, we are very interested in this feature, as it would significantly improve the user experience and integration with our existing identity management system.
If there is any roadmap information, estimated timeline, or beta availability you can share, we would greatly appreciate it.
Thank you in advance for your time and support.
-
We have started looking at OIDC. We do not have any timelines available yet.
-
Hello,
I’m following up on this matter to ask if you’ve been able to make any progress and, if possible, provide us with a release date for this feature that we are eagerly awaiting.
Thank you for your feedback.
Have a great day,
-
Yes, we've made progress, but its not done. We are hoping to have it ready for MDaemon 26.0.0 which is expected to release late first quarter or early second quarter of 2026.
-
Hello @Arron
You previously mentioned targeting availability with MDaemon 26.0.0, expected in late Q1 or early Q2 2026. As 26.0.0x builds are now available (including 26.0.0c) and we are entering the referenced timeframe, could you please confirm whether this item is still actively being worked on and if a production release within that window is still expected?
Thank you in advance for your update.
Best regards,
-
The current beta version does not include support for OIDC. We are still working on it and will make it available to the beta team as soon as its ready.
-
OIDC is available in the current MDaemon beta. If you are interesting in using OIDC and would like to help test it, please join our beta team. You can sign up for the beta program at https://mdaemon.com/pages/beta-program
-
Hi,
First of all, I wanted to say a huge thank you for the OIDC implementation. It’s a great addition, especially considering how quickly you rolled it out.
I have a quick question/suggestion: would it be possible to tag accounts that are authorized to use OIDC? I’m thinking of a dedicated checkbox within the user account management interface.
To make this scalable for a large user base, we would also need to be able to manage this via the API.
What are your thoughts on this?
Best regards,
-
I will add your requests to our wish list to be considered for future versions.
-
Hello,
I will add your requests to our wish list to be considered for future versions.
Thank You ;)
I have a functional question regarding my setup:
My SMTP hostname is set to mail.<Mydomain>.fr, which is dedicated solely to receiving mail from my SMTP relay.
However, my Webmail is accessed via webmail.<Mydomain>.fr. I would like the OIDC redirect URL to be:
https://webmail.<Mydomain>.fr/WorldClient.dll?View=OIDCIs this possible ? Currently, the field appears greyed out and cannot be edited.
Thank you for your help.
Best regards,
Arnaud
-
The redirect URI needs to be configured with your indentity provider. The values provided in the MDaemon user interfaces are examples that are built using the default domain's SMTP host name. You can alter the hostname but whatever value you configure in your indentity provider must connect to webmail and the connections must be allowed by your network infrastructure. And you should not alter the "worldclient.dll?View=OIDC" portion.
So if you use https:/webmail.mydomain.fr/worldclient.dll?View=OIDC, then webmail.mydomain.fr must point to the MDaemon server, connections on port 443 must be allowed, webmail needs to be listening on port 443, and the certificate must be valid for webmail.mydomain.fr, etc...
https://help.mdaemon.com/MDaemon/en/oidc.html
-
Hi Arron,
Thank you for the information. I am making step-by-step progress with the implementation, but I've run into a couple of issues:
Proxy Bypass :
I have configured the proxy so that MDaemon can reach resolver4-mdaemon.ctmail.com and clamav.net. However, the mail server's requests to the IDP for OIDC are also going through the proxy. This is neither necessary nor desirable for our setup. Is there a way to bypass the proxy for these specific internal/IDP requests (a "No Proxy" or "Exceptions" list)?
OIDC Debugging :
Even when I temporarily disable the proxy to test the direct connection, it still doesn't work. I found the following error in the Webmail log file: OIDC - ERROR: Could not generate authorization URL. Error 13 - Issuer mismatch.
I have double-checked my configuration between IDP and MDaemon, and here are the current settings:
MDaemon Side:
Issuer URL : https://connect.<mydomain.fr>
Redirect URL : https://webmail.<mydomain.fr>/WorldClient.dll?View=OIDCIDP Side:
Allowed redirection addresses: https://webmail.<mydomain.fr>/WorldClient.dll?View=OIDC
Is there something I missed ? Is it possible to have more granular details logs on Mdaemon side ?
Thank you,
-
Is there a way to bypass the proxy for these specific internal/IDP requests (a "No Proxy" or "Exceptions" list)?
No. If a proxy is configured in MDaemon, all HTTP traffic is routed through it.
OIDC - ERROR: Could not generate authorization URL. Error 13 - Issuer mismatch.
What IDP provider are you using?This is from google:An OpenID Connect (OIDC) Issuer Mismatch occurs when the issuer identifier (issclaim) found in an ID Token or within a provider's discovery document does not exactly match the value expected by the client application (Relying Party).Per the OpenID Connect Discovery 1.0 specification, theissuervalue returned in the discovery metadata must be identical to theissclaim in the ID Token. If these do not match, the OIDC library will fail the authentication for security reasons.Common Causes of Mismatch- Trailing Slashes: Many libraries perform strict string comparison. A configuration using
https://example.com(with a slash) will not match a token containinghttps://example.com(without a slash). This is a frequent issue in Go OIDC implementations. - Multi-tenant Endpoints (Azure AD/Entra ID): Azure AD often uses a "common" endpoint for discovery, but the resulting token contains a specific tenant UUID. If the library expects the generic "common" string, it will fail when it receives a tenant-specific ID.
- Environment-Specific Hosts: In development environments using Docker or reverse proxies, the application might access the provider via an internal URL (e.g.,
http://auth:8080), while the provider issues tokens using its public URL (e.g.,https://example.com). - Provider Side Changes: Major providers sometimes update their issuer URLs. For instance, Apple Sign-In recently caused issues by moving from
appleid.apple.comtoaccount.apple.com. - Case Sensitivity: Issuer URLs are case-sensitive. Even minor differences in capitalization between the client configuration and the provider's metadata will trigger this error.
Verify Discovery Metadata: Access your provider's discovery endpoint (typically at
[Issuer_URL]/.well-known/openid-configuration) and check the value of the"issuer"key. This is the exact string your client configuration must use.
- Trailing Slashes: Many libraries perform strict string comparison. A configuration using
- 1 / 2
- 2


